Библиотека Интернет Индустрии I2R.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи по теме:

• Веб-интерфейсы: Вездесущие приложения-хамелеоны
• О юзабилити для начинающих
• Создание сайта — этапы
• Заказ сделан: что дальше?
• Постановка и задание целей создания сайта
• Элементы разработки веб-сайтов
• Модели проектирования
• Планирование сайта с помощью UML
• Web-сайт. Планирование и реализация
• План работ для web-проекта
• Эвристики информационной архитектуры