Автор: Платон Днепровский, UIDesign Group
В своей практике мы часто встречаемся с такой ситуацией: новый проект, к которому нас привлекают, уже длится некоторое время, и по нему наработаны те или иные материалы, Как правило, есть уже готовое техническое задание (ТЗ) на разработку.
Какую задачу ставит перед нами заказчик? В подавляющем большинстве случаев это - проектирование интерфейса в рамках существующего ТЗ. Техзадание, как правило, это объемный подробный документ, где, (по RUP, например) зафиксированы все бизнес-роли, сценарии (use-cases), функции системы. В большинстве случаев - информационная структура, часто прописаны форматы тех или иных данных (длина и тип полей, например). Бывает, что в том или ином объеме даже отрисованы экранные формы.
Но позвольте! Какой интерфейс я могу разработать, действуя в этих рамках? Жонглировать кнопками? Заниматься раскраской экранов? Скорее всего, полноценная работа юзабилити-специалиста выйдет за рамки ТЗ: будут предложены изменения в структуре системы, возможно - , функционале, не говоря уж об экранных формах.
Однако ТЗ - совершенно необходимая часть мало-мальски серьезного проекта. Это перевод неявных и плохоструктурированных ожиданий и "хотений" на четкий и однозначный технический язык. Такой перевод необходим для:
- Нормального планирования и контроля работы в ходе проекта;
- Фиксации объемов работ, а значит - сроков и стоимости (во многих проектах составление ТЗ является нулевым этапом и стоит отдельных денег);
- Формирования контрольного списка условий, по которому заказчик принимает работу.
Ведь что хочет заказчик (не ИТ-директор со стороны заказчика, а именно бизнес-заказчик)? Решения таких-то и таких-то проблем на таких-то и таких-то условиях. Вроде: "С помощью Системы мои сотрудники должны быстро и без ошибок фиксировать все данные по договору, проводить его по жизненному циклу, и создавать ежемесячные отчеты для меня".
Это очень общее и неточное описание, и на основе этого нельзя ни спланировать, ни выполнить работу. Поэтому за дело берутся бизнес-аналитики, системные аналитики, менеджер проекта. На свет появляется ТЗ. И там уже написано: "…Система должна базироваться на такой-то архитектуре, БД - содержать столько-то записей, сущность "договор" - такие-то поля такого-то типа…". ТЗ подписывается сторонами.
Проект закончен. Система сдается. И вдруг начинаются проблемы. Заказчик начинает придираться. Причем, на взгляд разработчиков, совершенно безосновательно. Архитектура соответствует ТЗ? Соответствует! Все вот эти поля есть в системе? Есть! Формата такого? Да, именно такого! Все как в ТЗ, которое согласовано и подписано! Так в чем же дело?
А дело в том, что в процессе перевода "хотений" в ТЗ произошла подмена бизнес-задач, которые должна решать система, ее техническими характеристиками.
Налицо типичная ситуация общения на разных языках. Заказчик, думая о системе, часто представляет те бизнес-процессы, которые она будет автоматизировать, и, некие абстрактные картинки. Разработчик представляет ровно то, что сделано - реализованный функционал.
Один не понимает, что это за непонятная система, которая делает что-то отдаленно похожее на его задумки, и начинает раздражаться. Другой злится: все сделано четко по ТЗ, все функции - вот они, так какого ж ему еще надо!? Такие ситуации я наблюдал множество раз.
Игнорировать ТЗ невозможно, и желание внести в него изменения встретит резкое неприятие разработчиков: на этот документ потрачены ресурсы, и, самое главное, он (часто с боем) подписан у заказчика. Кроме того, изменения могут привести к переоценке затрат на проект, чего также никому не хочется: утверждать смету - нелегкая задача.
Как же подружить ТЗ и интерфейс?
Очень просто: разрабатывать интерфейс ДО описания технических параметров проекта в ТЗ.
Необходимо до перевода на язык технических характеристик сделать перевод на язык пользовательского интерфейса. Ведь интерфейс - это отнюдь не только красивые картинки. Это и количественные характеристики, важные и ПОНЯТНЫЕ для заказчика (скорость работы, например), это и описание поведения системы при работе с ней, и, в конце концов - визуализация, овеществление будущей системы. И представить финальный результат, имея перед собой прототип интерфейса, значительно проще, чем по ТЗ.
ТЗ, конечно, необходимо. Но часто бизнес-заказчику оно ни к чему, для него оно - филькина грамота. И теоретически оно вообще может ему не показываться.
Проектировать интерфейс до разработки ТЗ на реализацию, параллельно ему, или как часть его - прекрасный способ коммуникации и согласования ожиданий между заказчиками и разработчиками. Это избавляет от множества проблем.
Но абсолютного счастья нет. Какие минусы у данного подхода? Вот два самых явных:
- Увеличивается начальная стадия проекта - время до окончательной фиксации условий работ;
- Возрастает стоимость "нулевого" этапа - за счет внедрения процесса разработки интерфейса.
Время и деньги - одни из самых критичных параметров проекта, и, не смотря на то, что ОБЩИЕ затраты на проект ПРАКТИЧЕСКИ ВСЕГДА снижаются, необходимость сразу же платить больше и ждать дольше (первых результатов) редко вызывает положительные эмоции у заказчика.
Противопоставить этому можно следующее:
-
Во-первых, взывать к логике заказчика, и расписывать ему все прелести юзабилити вообще и данного подхода в частности. Практика показывает, что это работает отнюдь не всегда: плюсы - оно, конечно, хорошо, но и денег СРАЗУ надо давать, а польза все же не очевидна. Ситуация медленно меняется с ростом общей "юзабилити-грамотности" населения: желание взять денег за интерфейс уже редко считают попыткой "развести". И здесь хорошо работают "success stories", особенно подтвержденные количественными данными.
-
Во-вторых, нужно выпячивать те "вкусности", которые заказчик лично получит в течение проекта. Это - чёткое представление о будущей системе и ее визуализация - в виде прототипа(ов), либо отдельных шаблонов (и/или документации). А это - очень важный момент и для разработчиков в том числе. Этим мы добиваемся согласованности ожиданий от результатов проекта, и практически избавляемся от разговора на разных языках при его сдаче.
Очевидно, что все эти приемы надо применять вместе, да еще и широко улыбаться и вкусно пахнуть при этом.
Приятно, что тенденция к смещению юзабилити-работ в самое начало проекта заметна. В нашей практике есть примеры, когда интерфейс делался еще до определения подрядчика на его реализацию, и являлся ТЗ уже для разработчиков. Два-три года назад я бы даже не поверил, что такие идеальные ситуации возможны.
Резюме: в меру возможностей создавайте интерфейс на нулевых стадиях проекта. Сделайте описание пользовательского интерфейса артефактом, предваряющим техническое задание, или его частью. По крайней мере, попытайтесь доказать, что это окупится.
Помимо времени и денег экономит уйму нервов - проверено.