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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>> Ссылка на источник <<<

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

Для решения проблем, возникающих при создании ТЗ и проявляющихся при внедрении, придумано множество технологий и методов, но само их количество свидетельствует о том, что ни один не гарантирует полного успеха. Кроме того, многие методы имеют принципиальный недостаток — они увеличивают объем на определенной фазе работы (пусть и ради экономии на другом этапе) и требуют серьезных инвестиций в обучение сотрудников. Характерный пример — UML.

Существует, однако, подход, который не предполагает особой квалификации сотрудников и значительно облегчает внедрение, не увеличивая объем работ по подготовке ТЗ. Он основывается на идее, сущность которой можно сформулировать так: проектирование интерфейса — не часть процесса разработки, а часть процесса создания спецификаций на систему.

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

Преимущества подхода

Предлагаемый подход позволяет обеспечить следующие преимущества.

Во-первых, устраняются различия во взглядах заказчика и исполнителя на постановку задачи. Спецификации на сколько-нибудь сложные системы слишком абстрактны — их с трудом удерживают в голове даже авторы, а до конца не понимает никто, в том числе ключевое лицо, заказчик. Многие даже полагают, что непонятные ТЗ предназначены для того, чтобы произвести на заказчика впечатление и “содрать” побольше денег. Но наивно предполагать, что заказчик, легко подписавший маловразумительное ТЗ, так же легко примет разработанную систему. Прототипы интерфейса — это как раз тот единственный документ, который заказчик может понять и оценить. А поняв и оценив — сознательно подписать.

Во-вторых, облегчается процесс внедрения системы. Весомая часть проблем внедрения в качественно выполненном проекте приходится на интерфейс, созданный формально правильно, но неадекватно представлениям заказчика. Не существует вида ТЗ, кроме собственно прототипа интерфейса, который бы мог интегрировать такого рода требования. Наглядный пример — в любом ТЗ можно прописать, что «в системе есть адресная книга, которая состоит из таких-то данных и таких-то функций». Но невозможно формализовать уже в ТЗ, как эта адресная книга должна реально работать (какие-то функции нужно «вытащить» наверх, какие-то можно «задвинуть»), как, в конце концов, эта адресная книга должна выглядеть. При этом апелляции исполнителя к подписанному техническому заданию (дескать, вот здесь перечислены функции, и вот тут они все налицо), как правило, не срабатывают. При известной изворотливости в контексте пользовательского интерфейса проинтерпретировать ТЗ всегда можно очень по-разному. Только заранее спроектированный интерфейс позволяет застраховаться от такого рода претензий.

В-третьих, сокращается число доработок системы, вызванных несоответствием ее функциональности ожиданиям клиента. Только увидев саму систему, заказчик может реально понять ее возможности, равно как и оценить собственные потребности. Для заказчика программный продукт и его интерфейс в каком-то смысле тождественны. Следовательно, показав заказчику интерфейс на стадии подготовки ТЗ, можно снизить количество и объем переделок. (Нужно, впрочем, отметить, что такие переделки чаще всего не составляют проблемы для разработчиков, которые обычно настаивают на дополнительной оплате этих услуг.)

В-четвертых, снижается риск неудовлетворенности заказчика предложенным интерфейсом и связанной с этим необходимости дорабатывать функциональность системы. При разработке интерфейса нет решительно никакой гарантии того, что он будет принят заказчиком. Описание функций системы бинарно, т. е. функция в ней может быть или не быть. Доказательство ее наличия редко требует аргументации. Интерфейс же может быть либо достаточно хорошим, либо недостаточно хорошим. Когда в дело вступают относительные термины, все усложняется, что может приводить к конфликтным ситуациям. Нечего и говорить, что при переделке недостаточно хорошего интерфейсафункциональность системы, которая уже есть, меняется тоже, причем без оплаты труда разработчика.

Проблемы

Итак, есть объективная целесообразность в том, чтобы рассматривать проектирование интерфейса не как стадию разработки, а как стадию создания ТЗ. Но как это сделать? На первый взгляд, задача трудноразрешима — как организационно, так и технически.

Сначала об организационной стороне. Казалось бы, заказчик считает, что делать что-то «реальное» надо сразу после подписания договора. Однако практика показывает, что промежуточные наглядные результаты работы над системой, а именно прототипы интерфейса, продемонстрированные уже на второй день работы, а не через несколько недель, приводят клиента в благодушное настроение. В отличие от обычного ТЗ, работа над которым заказчику реально не видна («ну что там, пара пунктов добавилась»), прототипы интерфейса легко воспринимаются, и прогресс в работе явно заметен. Вторая организационная проблема связана с необходимостью подписывать два договора: на создание ТЗ (читай — интерфейса) и на разработку функциональности системы. Причем подписание второго договора откладывается на определенный срок, необходимый для разработки интерфейса, что растягивает проект во времени. В принципе, эта проблема неразрешима, но здесь многое зависит от ее восприятия: да, договоров два, но зато формулировки второго договора получаются значительно более точными (уже имея интерфейс, легче оценить трудозатраты).

Техническая проблема связана с трудностями разработки прототипа. В обычном режиме работы интерфейс создается уже с помощью средства разработки, создавать же прототип таким образом нерентабельно. Интерфейс создается через множество итераций, а переделывать уже сделанное становится дорого. Сравнительно недавно появились специальные средства для “прототипирования” интерфейса (например, Norpath Studio), но пока они довольно сырые. Выход — использование неспециализированных редакторов графики и презентаций. Еще несколько лет назад основным таким средством служил пакет Microsoft PowerPoint, сейчас же наиболее удобным следует признать Microsoft Visio. Сложные экранные формы, впрочем, до сих пор удобнее просто рисовать на бумаге.

И, наконец, главная проблема. Удлинение процесса разработки ТЗ часто воспринимается самими разработчиками как безусловное зло — привычка сначала делать, а уж потом думать, традиционно сильна и в российском ИТ-бизнесе. Увы, изменить этот обычай может только «опыт, сын ошибок трудных». Пока, во всяком случае…

Конечно, проектирование интерфейса на этапе разработки спецификаций системы — не панацея. Такой подход не позволяет улучшить качество разработки в принципе: например, он вовсе не уменьшает количество ошибок программирования. Более того, он не всегда применим. Интерфейс сложной системы невозможно с самого начала спроектировать полностью: придется сначала делать работающую бета-версию и окончательно править интерфейс уже на ее основе. К тому же во многих проектах по не зависящим ни от кого причинам не удается растянуть процесс создания ТЗ (заказчик хочет увидеть какие-нибудь результаты “уже завтра”). Однако, учитывая низкие «входные» требования к применению предложенного метода (несравнимые, например, с бюрократической волокитой, обусловленной использованием UML), проектирование интерфейсов на стадии подготовки спецификаций почти всегда оказывается крайне успешным методом решения проблем внедрения.

Владислав Головач, Александр Белышкин — ведущие специалисты компании Usethics
(http://www.usethics.ru).

Ссылка на статью: Проектирование интерфейса как часть разработки ТЗ

Перевод на русский язык

4.6 Прототипирование
Прототипирование часто используется на этапе выработки требований проекта. Существуют многие инструментальные средства, которые позволяют очень быстро и легко создать прототип, проявляющий некоторые характеристики системы. См. также ASTM Е1340-96.

Прототипы удобны по следующим причинам:

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

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

в) SRS, базирующаяся на прототипе, имеет тенденцию подвергаться меньшим изменениям во время разработки, сокращая, таким образом ее длительность.

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

Оригинал (на английском языке)

4.6 Prototyping
Prototyping is used frequently during the requirements portion of a project. Many tools exist that allow a prototype, exhibiting some characteristics of a system, to be created very quickly and easily. See also ASTM E1340-96.

Prototypes are useful for the following reasons:

a) The customer may be more likely to view the prototype and react to it than to read the SRS and react to it. Thus, the prototype provides quick feedback.

b) The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not only answers but also new questions. This helps reach closure on the SRS.

c) An SRS based on a prototype tends to undergo less change during development, thus shortening development time.

A prototype should be used as a way to elicit software requirements. Some characteristics such as screen or report formats can be extracted directly from the prototype. Other requirements can be inferred by running experiments with the prototype.