Технічне завдання та дизайн інтерфейсу

Автор: Платон Дніпровський, UIDesign Group


У своїй практиці ми часто зустрічаємося з такою ситуацією: новий проект, до якого нас приваблюють, вже триває деякий час, і по ньому напрацьовані ті чи інші матеріали, Як правило, є вже готове технічне завдання (ТЗ) на розробку.


Яке завдання ставить перед нами замовник? У переважній більшості випадків це – проектування інтерфейсу в рамках існуючого ТЗ. Техзавдання, як правило, це об'ємний докладний документ, де, (за RUP, наприклад) зафіксовані всі бізнес-ролі, сценарії (use-cases), функції системи. У більшості випадків – інформаційна структура, часто прописані формати тих чи інших даних (довжина і тип полів, наприклад). Буває, що в тому чи іншому обсязі навіть відмалювали екранні форми.


Але дозвольте! Який інтерфейс я можу розробити, діючи в цих рамках? Жонглювати кнопками? Займатися розфарбуванням екранів? Швидше за все, повноцінна робота юзабіліті-фахівця вийде за рамки ТЗ: будуть запропоновані зміни в структурі системи, можливо -, функціоналі, не кажучи вже про екранних формах.


Однак ТЗ – абсолютно необхідна частина мало-мальськи серйозного проекту. Це переклад неявних і плохоструктурірованних очікувань і "хотіння" на чітку і однозначну технічну мову. Такий переклад необхідний для:



Адже що хоче замовник (не ІТ-директор з боку замовника, а саме бізнес-замовник)? Рішення таких-то і таких-то проблем на таких-то і таких-то умовах. На зразок: "За допомогою Системи мої співробітники повинні швидко і без помилок фіксувати всі дані за договором, проводити його по життєвому циклу, і створювати щомісячні звіти для мене ".


Це дуже загальне і неточне опис, і на основі цього не можна ні спланувати, ні виконати роботу. Тому за справу беруться бізнес-аналітики, системні аналітики, менеджер проекту. На світ з'являється ТЗ. І там вже написано: "… Система повинна базуватися на такій-то архітектурі, БД – утримувати стільки-то записів, сутність" договір "- такі-то поля такого-то типу …". ТЗ підписується сторонами.


Проект закінчений. Система здається. І раптом починаються проблеми. Замовник починає чіплятися. Причому, на погляд розробників, абсолютно безпідставно. Архітектура відповідає ТЗ? Відповідає! Всі ось ці поля є в системі? Є! Формату такого? Так, саме такого! Все як у ТЗ, який погоджено і підписано! Так у чому ж справа?


А справа в тому, що в процесі перекладу "хотіння" в ТЗ сталася підміна бізнес-завдань, які повинна вирішувати система, її технічними характеристиками.


У наявності типова ситуація спілкування на різних мовах. Замовник, думаючи про систему, часто представляє ті бізнес-процеси, які вона буде автоматизувати, і, якісь абстрактні картинки. Розробник подає рівно те, що зроблено – реалізований функціонал.


Один не розуміє, що це за незрозуміла система, яка робить щось віддалено схоже на його задумки, і починає дратуватися. Інший злиться: все зроблено чітко за ТЗ, всі функції – ось вони, так якого ж йому ще треба!? Такі ситуації я спостерігав безліч разів.


Ігнорувати ТЗ неможливо, і бажання внести до нього зміни зустріне різке неприйняття розробників: на цей документ витрачені ресурси, і, найголовніше, він (часто з боєм) підписаний у замовника. Крім того, зміни можуть призвести до переоцінки витрат на проект, чого також нікому не хочеться: затверджувати кошторис – нелегке завдання.


Як же подружити ТЗ і інтерфейс?


Дуже просто: розробляти інтерфейс ДО опису технічних параметрів проекту в ТЗ.


Необхідно до перекладу на мову технічних характеристик зробити переклад на мову користувальницького інтерфейсу. Адже інтерфейс – це аж ніяк не тільки красиві картинки. Це і кількісні характеристики, важливі і зрозуміло для замовника (швидкість роботи, наприклад), це і опис поведінки системи при роботі з нею, і, врешті-решт – візуалізація, уречевлення майбутньої системи. І уявити фінальний результат, маючи перед собою прототип інтерфейсу, значно простіше, ніж по ТЗ.


ТЗ, звичайно, необхідно. Але часто бізнес-замовнику воно ні до чого, для нього воно – фількіна грамота. І теоретично воно взагалі може йому не показуватися.


Проектувати інтерфейс до розробки ТЗ на реалізацію, паралельно йому, або як частина його – прекрасний спосіб комунікації та узгодження очікувань між замовниками і розробниками. Це рятує від безлічі проблем.


Але абсолютного щастя немає. Які мінуси у даного підходу? Ось два найбільш явних:



  1. Збільшується початкова стадія проекту – час до остаточної фіксації умов робіт;
  2. Зростає вартість "нульового" етапу – за рахунок впровадження процесу розробки інтерфейсу.

Час і гроші – одні з найбільш критичних параметрів проекту, і, не дивлячись на те, що ЗАГАЛЬНІ витрати на проект ПРАКТИЧНО ЗАВЖДИ знижуються, необхідність відразу ж платити більше і чекати довше (перших результатів) рідко викликає позитивні емоції у замовника.


Протиставити цьому можна наступне:



Очевидно, що всі ці прийоми треба застосовувати разом, та ще й широко посміхатися і смачно пахнути при цьому.


Приємно, що тенденція до зміщення юзабіліті-робіт в самий початок проекту помітна. У нашій практиці є приклади, коли інтерфейс робився ще до визначення підрядника на його реалізацію, і був ТЗ вже для розробників. Два-три роки тому я б навіть не повірив, що такі ідеальні ситуації можливі.


Резюме: в міру можливостей створюйте інтерфейс на нульових стадіях проекту. Зробіть опис користувальницького інтерфейсу артефактом, що передують технічне завдання, або його частиною. Принаймні, спробуйте довести, що це окупиться.
Крім часу і грошей економить купу нервів – перевірено.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*