Техническое задание на разработку: как не переплатить
Смета на один и тот же проект у разных студий отличается втрое. Обычно это значит не то, что кто-то жадный, а то, что задача описана расплывчато и каждый посчитал свою версию. Там, где неопределённость, подрядчик закладывает риск — иногда 30–50 процентов сверху. Хорошее ТЗ убирает этот запас, и часто именно оно, а не торг, снижает цену.
ТЗ — это границы, а не мечты
Главная функция документа — зафиксировать, что входит в работу и что не входит. Второе даже важнее первого. Фраза «в первой версии нет мобильного приложения, интеграции с 1С и мультиязычности» стоит дороже десяти страниц описания красивых экранов, потому что именно на границах возникают споры об оплате. Всё, чего в документе нет, по умолчанию считается дополнительной работой — и обе стороны должны понимать это одинаково.
Из чего состоит рабочее ТЗ
- Цель и метрика: зачем система нужна и по какой цифре вы поймёте, что она сработала.
- Роли пользователей и что каждая может делать. Это заодно основа для прав доступа.
- Сценарии: последовательность шагов от начала до результата, обычными словами.
- Данные: какие сущности хранятся, как связаны, откуда берутся и куда выгружаются.
- Интеграции с указанием конкретных систем и наличия у них документированного API.
- Нефункциональные требования: нагрузка, скорость, где хостинг, требования к хранению персональных данных.
- Что явно не входит в объём работ.
Как писать сценарии
Самая полезная часть ТЗ — описание пути пользователя от намерения до результата. Не «система должна поддерживать запись клиентов», а «клиент открывает страницу услуги, выбирает мастера или пропускает шаг, видит свободные слоты на две недели вперёд, вводит телефон, получает код, подтверждает, получает сообщение с адресом». По такому тексту можно посчитать работу и по нему же потом принимать результат. Абстрактные формулировки вроде «удобный интерфейс» и «современный дизайн» в приёмке не помогают ничем, потому что не проверяются.
Кто пишет документ
Есть три варианта. Написать самому — дёшево, но получается описание желаний без учёта технических ограничений, и подрядчик всё равно переписывает. Заказать у того же подрядчика — самый распространённый и разумный путь: 40 000–150 000 рублей и одна-три недели, зато на выходе документ, по которому можно считать. Формальный риск — что документ напишут под удобное подрядчику решение, и он снижается тем, что ТЗ остаётся вашей собственностью и с ним можно идти в другую студию за сравнительной сметой. Третий вариант — независимый аналитик — оправдан на проектах от нескольких миллионов. У нас проектирование идёт отдельным оплачиваемым этапом перед разработкой, и его результат принадлежит клиенту вне зависимости от того, продолжит он работу с нами или нет.
Что стоит добавить, чтобы не переделывать
Опишите требования к доступности и мобильным устройствам явно: если 70 процентов пользователей придут с телефона, это влияет на архитектуру интерфейса, а не только на вёрстку; хорошие ориентиры собраны в руководстве по доступности на web.dev. Зафиксируйте требования по безопасности хотя бы на уровне «система проверяется по OWASP Top 10» — это даёт понятный критерий приёмки вместо расплывчатого «должно быть безопасно», а что именно проверяем мы, описано в разделе безопасности. И укажите, что происходит с данными и доступами по завершении проекта.
Чего в ТЗ быть не должно
Не превращайте документ в двести страниц с описанием каждой кнопки: к моменту, когда вы его допишете, задача изменится, а читать его никто не будет. Оптимальный объём для системы средней сложности — 15–30 страниц. Не фиксируйте технологии, если у вас нет на то причины: требование «сделать на конкретном фреймворке» без обоснования сужает выбор подрядчиков и удорожает работу. И не пишите сроки в ТЗ — им место в договоре, где они привязаны к этапам и ответственности.
Проверка перед отправкой
Дайте документ человеку, который не участвовал в его написании, и попросите пересказать, что должна делать система. Если пересказ совпал с вашим замыслом — ТЗ рабочее. Если возникли вопросы «а что будет, если...» — записывайте их, это и есть будущие спорные места. И последнее: отправляйте одинаковый документ всем подрядчикам. Только тогда сметы можно сравнивать, а не гадать, почему одна из них вдвое меньше. Обсудить структуру документа под конкретную задачу можно до начала работ — это бесплатная часть разговора.