Техническое задание экономит обеим сторонам недели работы: исполнитель понимает объём и может назвать честную цену, заказчик заранее знает, что именно получит. Задание в формулировке «нужен современный сайт, как у конкурентов, только лучше» гарантирует спор на приёмке, потому что проверить его нельзя. Ниже — структура, которой мы пользуемся сами, и разбор мест, где чаще всего возникают разногласия.
Зачем задание нужно обеим сторонам
Заказчику задание даёт возможность сравнивать предложения: пока объём не описан, сметы разных студий отличаются в разы, и не потому что кто-то дороже, а потому что каждый посчитал свой набор работ. Исполнителю задание даёт границу ответственности: понятно, что входит в цену, а что оформляется отдельно.
Есть и третья функция, о которой вспоминают позже. Задание — это документ приёмки. Когда работа сдана, спор «мы имели в виду другое» решается не голосом, а сверкой с текстом. Поэтому каждый пункт стоит писать так, чтобы по нему можно было ответить «сделано» или «не сделано» без обсуждения вкусов.
Что обязательно должно быть в задании
Минимальный набор разделов выглядит так. Если какой-то из них отсутствует, вопрос всё равно всплывёт — но уже в середине проекта, когда его решение стоит дороже.
| Раздел | Что описать |
|---|---|
| Задача бизнеса | Что должно измениться: заявки, заказы, снижение нагрузки на менеджеров |
| Аудитория и сценарии | Кто придёт на сайт, какое решение принимает, с какого устройства |
| Структура | Список страниц и назначение каждой, включая служебные |
| Функции | Формы, расчёты, фильтры, личный кабинет, интеграции |
| Содержимое | Кто готовит тексты, фотографии, документы и в какие сроки |
| Приёмка | По каким проверяемым критериям работа считается выполненной |
Раздел о содержимом пропускают чаще остальных, а он останавливает проекты надёжнее технических сложностей: разработка закончена, а страницы пустые, потому что тексты никто не писал. Поэтому мы просим указывать не только ответственного, но и формат передачи материалов.
Как описывать функции
Формулировка «сделать удобную форму заявки» непроверяема. Рабочее описание разбирает функцию по шагам: какие поля, какие из них обязательны, как проверяется телефон и почта, что происходит после отправки, куда приходит заявка, что видит человек при ошибке отправки, что происходит при повторной отправке той же формы.
С интеграциями то же самое. Недостаточно написать «связать с учётной системой»: нужно указать, что и в какую сторону передаётся, как часто, что считается успешной передачей и что делать, если внешняя система недоступна. Половина непредвиденных работ на проектах возникает именно здесь, потому что на старте никто не проверил, есть ли у смежной системы подходящий интерфейс обмена.
Полезное упражнение — переписать каждый пункт функциональности в форме «пользователь делает то-то и получает то-то». Если фраза не складывается, значит, требование сформулировано абстрактно и его придётся уточнять.
Про дизайн: примеры вместо прилагательных
Вкус словами не описывается. Слова «современный», «дорогой», «строгий» каждый читает по-своему, и на макете это выясняется слишком поздно. Вместо прилагательных приложите три-пять примеров сайтов с пояснением, что именно нравится: структура первого экрана, крупная типографика, спокойная палитра, много воздуха. И столько же примеров того, что не нравится, — отрицательные примеры сужают поиск даже быстрее.
Отдельно стоит указать ограничения фирменного стиля: есть ли брендбук, обязательны ли конкретные цвета и шрифты, можно ли отступать от них в интерфейсных элементах. И договориться о количестве итераций правок по макету, иначе этап дизайна растягивается на неопределённый срок.
Технические требования и приёмка
В этом разделе описываются вещи, которые потом сложно добавить: платформа и права на код, хостинг и домен, требования к скорости загрузки, поддерживаемые браузеры и минимальная ширина экрана, доступность из административной части, резервное копирование, наличие тестового контура.
Приёмку удобно оформить перечнем проверок, а не общими словами. Например: все формы отправляются и письма приходят на указанные адреса, страницы открываются на телефоне без горизонтальной прокрутки, административная часть позволяет добавить страницу и раздел без разработчика, сайт переносится на хостинг заказчика по инструкции. Такие пункты либо выполнены, либо нет.
Стоит заранее договориться о гарантийном периоде и о том, что в него входит. Исправление ошибок в согласованной функциональности — гарантия. Новые пожелания — отдельные работы, и это лучше зафиксировать до старта, а не в момент разногласия.
Чего в задании быть не должно
- Формулировок «и всё остальное, что потребуется по ходу работы». Это не требование, а источник конфликта.
- Требований без критериев: «быстро», «удобно», «красиво», «чтобы нравилось руководству».
- Технологий ради технологий. Если платформа названа, должно быть объяснено, почему именно она.
- Списка страниц без указания, кто их наполняет и чем.
- Ссылок на устные договорённости и переписку без приложения самих договорённостей.
Отдельный случай — задание, написанное копированием чужого. В нём обычно остаются разделы, к проекту не относящиеся, и они либо оплачиваются впустую, либо становятся поводом для спора о том, обязательны ли они.
Если писать задание некому
Нормальная практика — заказать задание отдельным платным этапом у той же студии или у независимого специалиста. На выходе получается прототип и описание, с которыми можно идти к любому исполнителю и сравнивать сметы по одному и тому же объёму работ. Даже если проект в итоге делает другая команда, деньги на этот этап окупаются точностью оценки.
Заодно этап проектирования показывает, как подрядчик работает: какие вопросы задаёт, спорит ли с сомнительными требованиями, как ведёт переписку и фиксирует решения. Это более честная проверка, чем портфолио.
Как фиксировать изменения
Задание не догма: по ходу проекта выясняются вещи, которых не было видно на старте. Важно, чтобы каждое изменение оформлялось письменно — что добавляем или убираем, как это меняет сроки и стоимость, кто согласовал. Формат может быть любым, вплоть до нумерованного списка дополнений в общем документе, лишь бы он был единственным источником правды.
Устные договорённости «по ходу» — главный источник конфликтов при сдаче. Через три месяца стороны помнят разговор по-разному, и восстановить его невозможно. Письменная фиксация занимает несколько минут и снимает вопрос целиком.
Короткий порядок работы над заданием
- Сформулируйте задачу бизнеса и критерий, по которому поймёте, что проект удался.
- Опишите аудиторию и два-три основных сценария.
- Составьте структуру страниц и разделов.
- Разберите каждую функцию по шагам, отдельно опишите интеграции.
- Соберите примеры дизайна, которые нравятся и не нравятся.
- Зафиксируйте технические требования, критерии приёмки и порядок изменений.
Если задание уже написано, но уверенности в нём нет, полезно проверить его на понятность сценариев до начала разработки: мы проведём аудит юзабилити и покажем, какие требования придётся уточнить, пока правки стоят часов, а не месяцев.
