Відмінності між версіями «Проектування інтерфейсу як частина розробки ТЗ»
| Рядок 6: | Рядок 6: | ||
Пропонований підхід дозволяє вирішити наступні проблеми: | Пропонований підхід дозволяє вирішити наступні проблеми: | ||
| − | + | *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати. | |
| − | + | *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій. | |
| − | + | *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.) | |
| − | + | *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника. | |
Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін. | Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін. | ||
Версія за 15:29, 13 грудня 2011
Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.
Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.
Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.
Пропонований підхід дозволяє вирішити наступні проблеми:
- Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.
- Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.
- Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)
- Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.
Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.
Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).
Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.
І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...
Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.
