Техническое задание и дизайн интерфейса

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

Какую задачу ставит перед нами заказчик? В подавляющем большинстве случаев это проектирование интерфейса в рамках существующего ТЗ. Техзадание, как правило, это объемный подробный документ, где, (по RUP, например) зафиксированы все бизнес-роли, сценарии (use-cases), функции системы. В большинстве случаев информационная структура, часто прописаны форматы тех или иных данных (длина и тип полей, например). Бывает, что в том или ином объеме даже отрисованы экранные формы.

Но позвольте! Какой интерфейс я могу разработать, действуя в этих рамках? Жонглировать кнопками? Заниматься раскраской экранов? Скорее всего, полноценная работа юзабилити-специалиста выйдет за рамки ТЗ: будут предложены изменения в структуре системы, возможно - , функционале, не говоря уж об экранных формах.

Однако ТЗ совершенно необходимая часть мало-мальски серьезного проекта. Это перевод неявных и плохоструктурированных ожиданий и хотений на четкий и однозначный технический язык. Такой перевод необходим для:

• Нормального планирования и контроля работы в ходе проекта;
• Фиксации объемов работ, а значит сроков и стоимости (во многих проектах составление ТЗ является нулевым этапом и стоит отдельных денег);
• Формирования контрольного списка условий, по которому заказчик принимает работу.

Ведь что хочет заказчик (не ИТ-директор со стороны заказчика, а именно бизнес-заказчик)? Решения таких-то и таких-то проблем на таких-то и таких-то условиях. Вроде: С помощью Системы мои сотрудники должны быстро и без ошибок фиксировать все данные по договору, проводить его по жизненному циклу, и создавать ежемесячные отчеты для меня.

Это очень общее и неточное описание, и на основе этого нельзя ни спланировать, ни выполнить работу. Поэтому за дело берутся бизнес-аналитики, системные аналитики, менеджер проекта. На свет появляется ТЗ. И там уже написано: Система должна базироваться на такой-то архитектуре, БД содержать столько-то записей, сущность договор - такие-то поля такого-то типа. ТЗ подписывается сторонами.

Проект закончен. Система сдается. И вдруг начинаются проблемы. Заказчик начинает придираться. Причем, на взгляд разработчиков, совершенно безосновательно. Архитектура соответствует ТЗ? Соответствует! Все вот эти поля есть в системе? Есть! Формата такого? Да, именно такого! Все как в ТЗ, которое согласовано и подписано! Так в чем же дело?

А дело в том, что в процессе перевода хотений в ТЗ произошла подмена бизнес-задач, которые должна решать система, ее техническими характеристиками.

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

Один не понимает, что это за непонятная система, которая делает что-то отдаленно похожее на его задумки, и начинает раздражаться. Другой злится: все сделано четко по ТЗ, все функции вот они, так какого ж ему еще надо!? Такие ситуации я наблюдал множество раз.

Игнорировать ТЗ невозможно, и желание внести в него изменения встретит резкое неприятие разработчиков: на этот документ потрачены ресурсы, и, самое главное, он (часто с боем) подписан у заказчика. Кроме того, изменения могут привести к переоценке затрат на проект, чего также никому не хочется: утверждать смету нелегкая задача.

Как же подружить ТЗ и интерфейс?

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

Необходимо до перевода на язык технических характеристик сделать перевод на язык пользовательского интерфейса. Ведь интерфейс это отнюдь не только красивые картинки. Это и количественные характеристики, важные и ПОНЯТНЫЕ для заказчика (скорость работы, например), это и описание поведения системы при работе с ней, и, в конце концов визуализация, овеществление будущей системы. И представить финальный результат, имея перед собой прототип интерфейса, значительно проще, чем по ТЗ.

ТЗ, конечно, необходимо. Но часто бизнес-заказчику оно ни к чему, для него оно филькина грамота. И теоретически оно вообще может ему не показываться.

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

Но абсолютного счастья нет. Какие минусы у данного подхода? Вот два самых явных:

1. Увеличивается начальная стадия проекта время до окончательной фиксации условий работ;
2. Возрастает стоимость нулевого этапа за счет внедрения процесса разработки интерфейса.

Время и деньги одни из самых критичных параметров проекта, и, не смотря на то, что ОБЩИЕ затраты на проект ПРАКТИЧЕСКИ ВСЕГДА снижаются, необходимость сразу же платить больше и ждать дольше (первых результатов) редко вызывает положительные эмоции у заказчика.

Противопоставить этому можно следующее:

• Во-первых, взывать к логике заказчика, и расписывать ему все прелести юзабилити вообще и данного подхода в частности. Практика показывает, что это работает отнюдь не всегда: плюсы оно, конечно, хорошо, но и денег СРАЗУ надо давать, а польза все же не очевидна. Ситуация медленно меняется с ростом общей юзабилити-грамотности населения: желание взять денег за интерфейс уже редко считают попыткой развести. И здесь хорошо работают success stories, особенно подтвержденные количественными данными.

• Во-вторых, нужно выпячивать те вкусности, которые заказчик лично получит в течение проекта. Это чткое представление о будущей системе и ее визуализация в виде прототипа(ов), либо отдельных шаблонов (и/или документации). А это очень важный момент и для разработчиков в том числе. Этим мы добиваемся согласованности ожиданий от результатов проекта, и практически избавляемся от разговора на разных языках при его сдаче.

Очевидно, что все эти приемы надо применять вместе, да еще и широко улыбаться и вкусно пахнуть при этом.

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

Резюме: в меру возможностей создавайте интерфейс на нулевых стадиях проекта. Сделайте описание пользовательского интерфейса артефактом, предваряющим техническое задание, или его частью. По крайней мере, попытайтесь доказать, что это окупится.
Помимо времени и денег экономит уйму нервов проверено.

Автор: Платон Днепровский, UIDesign Group
Источник: http://gui.ru/platon/