Создание технического задания на сайт

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

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

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

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

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

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

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

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

При составлении ТЗ на интернет-магазин или сайт я преследую несколько целей:

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

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

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

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

Вообще, средств прототипирования довольно много. В крайнем случае можно нарисовать прототип от руки на бумаге или сделать в одном из обычных офисных приложений. Мне приходилось видеть прототипы сделанные и в Word, и в Excell, и в Power Point. Но гораздо удобнее использовать специальное программное обеспечение. При разработке прототипов мы пользуемся Figma.

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

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

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

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

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

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

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

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

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

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

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

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

1. Не забываем указать роли пользователей и доступные для каждого типа пользователей действия

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

2. Структура сайта — расписываем какие разделы и подразделы сайт включает

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

3. Если ваше ТЗ включает раздел про дизайн, не надо туда переписывать бриф

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

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

4. Если используется коробочная CMS, например — Битрикс, не изобретаем велосипед

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