Техническое задание, ТЗ, это документ, который все хотят иметь и никто не хочет писать. Клиент считает, что ТЗ должен написать исполнитель, ведь он специалист. Исполнитель считает, что ТЗ должен дать клиент, ведь это его бизнес. В итоге ТЗ пишется наспех, в последний момент, на две страницы общих слов, и проект стартует с фундаментом из песка.
Я видел, как плохое ТЗ убивало проекты, которые могли бы стать прекрасными. И видел, как хорошее ТЗ спасало проекты с посредственной командой. Это не преувеличение: ТЗ это контракт между бизнесом и разработкой. Чем оно чётче, тем меньше конфликтов при приёмке работ, тем точнее оценка и тем меньше денег уходит на переделки.
Чертёж, а не пожелание
Ни один архитектор не начнёт строить дом по фразе «хочу красивый и удобный». Он спросит: сколько этажей, сколько людей будет жить, нужен ли гараж, какой бюджет, какой участок, где солнце встаёт. А потом нарисует чертёж, на котором видно каждую стену и каждое окно. И только после того, как заказчик подпишет этот чертёж, строители возьмутся за работу.
В разработке программ почему-то считается, что можно обойтись без чертежа. «Давайте начнём, а по ходу разберёмся». Это работает ровно до первого спора, который звучит так: «Я же говорил, что мне нужно...», а в ответ: «Нет, не говорили». И оба правы, потому что каждый помнит свою версию разговора. ТЗ нужен именно для того, чтобы версия была одна.
Что обязательно должно быть в ТЗ
Цели и бизнес-логика. Зачем создаётся система, какую проблему она решает, кто ею будет пользоваться. Это первый раздел, и он самый важный. Если разработчик не понимает цели, он будет принимать решения вслепую. Когда цель понятна, команда сама предлагает более простые и дешёвые пути её достижения.
Роли пользователей. Кто работает с системой и что каждому разрешено. Клиент, менеджер, администратор, бухгалтер: у каждого свой набор экранов и действий. Из этого раздела рождается половина архитектуры.
Детальное описание функционала. Не «система должна управлять заказами», а конкретные сценарии: клиент оформляет заказ, выбирает доставку, оплачивает, получает уведомление; менеджер видит заказ в списке, меняет статус, связывается с клиентом. Каждый сценарий с началом, шагами, развилками и результатом.
Структура данных. Какие сущности есть в системе и как они связаны. Клиент, заказ, товар, оплата. Это язык, на котором будут говорить и бизнес, и код. Если названия в ТЗ и в программе не совпадают, через год никто не поймёт, что есть что.
Требования к дизайну. Хотя бы схемы экранов, хотя бы от руки. Один набросок интерфейса снимает десяток вопросов.
Нефункциональные требования. Скорость работы, безопасность, количество пользователей, резервное копирование, поддержка браузеров и устройств. Про них забывают чаще всего, и именно они потом становятся самыми дорогими сюрпризами. Я писал о них отдельную статью, и очень рекомендую к ней вернуться.
Критерии приёмки. Как мы поймём, что система готова. Конкретные проверяемые условия, а не «всё работает хорошо».
Правила, которые я вынес из практики
Первое: пишите для человека, который не был на Ваших встречах. ТЗ будет читать новый программист через полгода, тестировщик, который пришёл в середине проекта, другой подрядчик, если с первым не сложится. Всё, что «и так понятно», понятно только Вам.
Второе: одно требование, одна мысль. Требование «система должна быть быстрой, удобной и безопасной» невозможно проверить. Разделите его на три, и для каждого напишите, что именно значит быстро, удобно и безопасно.
Третье: описывайте, что делать, когда что-то идёт не так. Большинство ТЗ описывают только счастливый путь: пользователь всё ввёл правильно, оплата прошла, сервер ответил. А реальность состоит из ошибок, отмен, пустых полей и сбоев связи. Именно на этих развилках и рождаются баги и споры.
Четвёртое: ТЗ это живой документ, но с правилами изменений. Требования будут меняться, это нормально. Но каждое изменение должно фиксироваться, оцениваться и согласовываться, а не просто прилетать в чат. Иначе ТЗ через месяц перестаёт отражать реальность, и все снова работают по памяти.
Пятое: не пытайтесь описать всё сразу. Для первой версии продукта нужно ТЗ на первую версию. Подробное описание функций, которые появятся через два года, это потраченное время, потому что к тому моменту всё изменится.
Кто должен писать ТЗ
Мой ответ: вместе. Клиент знает свой бизнес, но не знает, как его превратить в программу. Исполнитель знает, как строить программы, но не знает бизнеса клиента. Хорошее ТЗ рождается в диалоге, где бизнес-аналитик или архитектор задаёт вопросы, а клиент отвечает, и где обе стороны рисуют и правят одну и ту же картину.
Если исполнитель берётся за проект без ТЗ или по ТЗ из двух абзацев и сразу называет фиксированную цену, будьте осторожны. Либо он заложил огромный запас, либо Вы скоро узнаете, что «это не входило в договорённость».
Как мы делаем это в Ingello
Мы пошли дальше классического текстового ТЗ. В Ingello Systems часть технического задания пишется не прозой, а формальными описаниями: схемой данных на SFL, картой экранов и сценариев на ISFL, разметкой интерфейсов на IFL. Генератор Fractal превращает это описание в работающий прототип с базой, API и админкой. Клиент видит не документ на пятьдесят страниц, а систему, в которой можно кликать уже через несколько дней. И спорить становится гораздо проще: вот экран, вот данные, это то, что Вы хотели, или нет?
Но даже без генераторов принцип тот же: чем ближе ТЗ к чертежу и чем дальше от пожелания, тем успешнее проект. Если завтра Вы начинаете новый проект, начните не с поиска разработчиков, а с ответа на вопрос, который задал бы архитектор: что именно мы строим, для кого и как поймём, что построили.
