Даже когда 8 лет назад мы делали свои первые сайты, обязательной частью каждого договора на разработку у нас было техническое задание, или попросту ТЗ (может первые пару проектов мы и пробовали сделать без него, но быстро одумались). Тогда этот шедевр мысли включал разделы «Назначение сайта», «Дизайн» и «Содержание сайта».

Наступив на все возможные грабли, мы году этак в 2008 пришли к нудным, подробным многостраничным техническим заданиям, которые писались больше для того, чтобы не сделать ничего лишнего в рамках проекта и доказать клиенту, что «мы это делать не должны». Про них я еще расскажу подробнее, ведь это «обычные» технические задания, которыми и сейчас пользуется большинство разработчиков сайтов.

Потом нам это надоело — при таком подходе проекты очень редко вписывались в первоначальную оценку и сдавались обычно «с нервами». Проблему решили. Теперь у нас «хорошие» ТЗ, точнее не совсем ТЗ.

«Обычное» техническое задание

Зачастую техническое задание (если оно вообще есть) это нудный документ, в котором постранично текстом описано, что должно быть на сайте, с перечислением элементов и блоков через запятую или списком. Если очень повезет — для некоторых страниц нарисованы схемы. Делается оно обычно путем копирования кусков из старых технических заданий. Так например, в этом году я видел несколько ТЗ с требованием верстки под 800×600 и IE 6 (люди, откуда вы это копируете?? срочно сотрите!) Проверяется через строку (длинное, вычитывать лень). Заказчиком вообще читается через абзац — по той же причине.

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

Потом — это все верстается и программируется. Программисты долго пытаются состыковать ТЗ с макетами, и в результате что-то получается.

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

Альтернативное техническое задание

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

Итак, хорошее техническое задание:

• должно полностью описывать результат работ,
• должно быть максимально простым и понятным,
• должно быть наглядным,
• не должно быть излишне длинным,
• должно быть измеримым (в рублях и часах),
• его должно быть в кайф читать, смотреть, тыкать и делать.

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

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

Директор студии E-Time, Григорий Овсепян придумал название таким ТЗ: «декларация о намереньях».

Так вот. Техническое задание — это постановка задачи в таком виде, чтобы СРЕДНИЙ специалист по программированию или дизайну сразу без лишних вопросов смог приступить и выполнить ее. То есть не надо туда писать бизнес-стратегии. Не надо зауми. Не надо ориентации на карманных оракулов.

Цель ТЗ — помочь разработчику сделать проект именно таким, как его хотел бы видеть заказчик.

Еще. ТЗ нифига не защищают разработчика, особенно письменные. Попробуйте более-менее конкретно расписать какой-то сайт. Если клиент захочет, он сможет ЛЮБОЙ пункт интерпретировать по другому, или считать какие-то «допфункционалы» с точки зрения разработчика дефолтными. То есть он сможет при желании оспаривать любой пункт и приводить какие-либо доводы, о том, что «он думал что будет так», или что «так есть у всех» ,или что «так принято в моей отрасли», или что-то еще.

Я думаю, никакого способа побороть это на уровне формализации ТЗ нет. Нужно отстраивать отношения с клиентом, понимать его потребности, говорить с ним ГОЛОСОМ, а процесс работы сделать максимально интерактивным.

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

Люди быстрее понимают картинки и наглядное представление — поэтому рулят прототипы. Однако описать технические аспекты и механику работы web-приложений на прототипах до конца нельзя, поэтому текстовые ТЗ/постановки/диаграммы так же нужны. Это не обязательно должны быть отдельные документы. Иногда достаточно презентации в PowerPoint, иногда — даже просто комментариев к прототипу.

Итерации должны быть короткие, иначе, если результат итерации не зафиксирован — накопленные сведения забываются, и ни команда, ни заказчик через пару месяцев уже не вспомнит, на какой фазе был заброшен проект, и что именно с ним теперь делать. «Перезапустить» такой проект — очень сложно и дорого.

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

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

Еще раз об экономии времени. Разработка прототипа и ТЗ к нему обычно съедает 12% бюджета проекта. На первый взгляд — много. (И это реально много!) Но она не более трудозатратна, чем составление традиционного технического задания. К тому же она прогнозируема по срокам, и позволяет избежать гораздо большего вылезания из сроков и бюджета.

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

Что еще можно оптимизировать при разработке ТЗ:

1. Не забываем указать роли пользователей и доступные для каждого типа пользователей действия. (Эта штука называется Use Case Diagram в UML. У UML-парадигмы есть куча адептов и ненавистников, но в целом — подход рабочий, если не тратить на него много времени).

2. Структура сайта — расписываем какие разделы и подразделы сайт включает. Описываем страницы. Если схему страницы нарисовать проще, чем расписать какой блок где находится — рисуем. Если страница простая — ограничиваемся текстовым описанием. Иногда это удобно сделать с помощью ментальных карт (карт ума, mind map). Мы используем Free Mind для их построения.

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

4. Если используется коробочная CMS, не изобретаем велосипед — указываем редакцию, даем ссылку на ее описание на официальном сайте и перечисляем какие модули из включенных в данную редакцию настраиваем для сайта.

Вообще, средств прототипирования довольно много. В крайнем случае можно нарисовать прототип от руки на бумаге или сделать в одном из обычных офисных приложений. Мне приходилось видеть прототипы сделанные и в Word, и в Excell и в Power Point. Но гораздо удобнее использовать специальное программное обеспечение. При разработке прототипов мы пользуемся Axure Pro (рекомендую, если есть $500) или Evolus Pencil. Также популярны Visio и InDesign. Хороший обзор средств прототипирования можно найти в блоге нашего коллеги (Павел, привет!  ).

Давайте похоливарим в комментах: Я считаю, ТЗ делать надо, а интерактивный прототипы и короткий спек — рулят. Кто против?

Оригинал статьи)