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