Как написать техническое задание на разработку ПО

Техническое задание пишут ради одной вещи — чтобы через три месяца заказчик и разработчик одинаково понимали слово «готово». Все остальное в ТЗ вторично.

Поэтому документ на сорок страниц по ГОСТ 34, который никто не открывает после подписания, задачу не решает. А четыре страницы, где по каждому требованию понятно, как его проверить, — решают.

Что происходит без ТЗ

Требование звучит одной строкой, а реализаций у него несколько. Каждая из них формально закрывает фразу, но стоит по-разному и делается разное количество времени.

Задача ТЗ — убрать эту вилку до начала работ, а не после.

Из чего состоит рабочее ТЗ

Порядок блоков важнее их количества. Каждый следующий опирается на предыдущий.

1. Зачем это делается. Одна-две страницы про бизнес-ситуацию: что происходит сейчас, что в этом плохо, какой результат считается успехом. Без этого разработчик не может принимать мелкие решения самостоятельно и тащит каждое к заказчику.
2. Кто пользователи и что они делают. Список ролей и для каждой — перечень действий. Не «администратор управляет системой», а «администратор создает заявку, назначает исполнителя, закрывает смену».
3. Сценарии. Основной путь каждого действия по шагам плюс что происходит при отказе. Сценарии — самая полезная часть документа и самая часто пропускаемая.
4. Данные. Какие сущности есть, какие у них поля, какие поля обязательны, как они связаны. Половина споров на приемке — это споры о данных, а не об интерфейсе.
5. Интеграции. С чем система обменивается, в какую сторону, как часто, что считается источником истины при расхождении. Последний вопрос стоит дороже всех остальных.
6. Нефункциональные требования. Нагрузка, время отклика на тяжелых операциях, требования к хранению данных и доступу, мобильная работа, offline. Коротко, но конкретно.
7. Критерии приемки. Список проверок, по которым работа считается сделанной. Если пункт нельзя проверить за пятнадцать минут руками, он сформулирован плохо.

Как формулировать, чтобы не спорить потом

Хорошая формулировка почти всегда содержит число или проверяемое условие. Если число неизвестно — это отдельный вопрос к заказчику, и лучше выяснить его на берегу.

Что убивает ТЗ

• Описание интерфейса вместо задачи. «Кнопка в правом верхнем углу» фиксирует решение, а не потребность. Через месяц выяснится, что удобнее иначе, но в ТЗ написано так.
• Требования без владельца. Пункт, который никто не может объяснить, обычно попал туда из чужого документа. Такие пункты стоят денег и не нужны.
• Все важно. Если приоритетов нет, первым сделают не то. Достаточно трех уровней: без этого запуска нет, нужно в первые месяцы, когда-нибудь потом.
• ТЗ как разовый документ. Требования меняются всегда. Вопрос только в том, фиксируются изменения или живут в переписке.
• Копирование ГОСТ-структуры ради структуры. ГОСТ 19 и ГОСТ 34 нужны там, где их требует заказчик или закупка. В остальных случаях они добавляют объем, но не ясность.

Пример: как строка превращается в требование

Исходная фраза от заказчика: «нужно, чтобы руководитель видел загрузку машин».

Дальше идут вопросы, и каждый ответ убирает вилку в смете.

• Загрузку за какой период. На сегодня, на неделю вперед, за прошлый месяц? Это три разных экрана.
• Что считается загрузкой. Часы в рейсе, число заявок, объем в кубометрах, выручка? Формула должна быть записана.
• Откуда берутся данные. Из статусов заявок в системе или из отметок водителя? Если из отметок, появляется требование к мобильной части.
• Что руководитель делает после того, как увидел. Если ничего — экран не нужен. Если перераспределяет заявки — нужно действие прямо с этого экрана, и это уже другой объем работ.

Готовое требование выглядит так.

Это один пункт из тридцати. Но по нему уже нельзя сделать «не то», и по нему можно назвать цену.

Что делать с изменениями

Требования будут меняться — это не провал планирования, а норма. Плохо не изменение, а изменение без следа.

Рабочая процедура состоит из трех правил.

1. Любое изменение фиксируется письменно. Одно предложение о том, что меняется, и одно — почему. Достаточно письма или задачи в трекере.
2. По каждому изменению называется влияние на срок и смету. Даже если оно нулевое. Фраза «это мелочь, сделаем заодно» — главный источник конфликтов на приемке.
3. ТЗ обновляется, а не дополняется перепиской. Иначе через три месяца актуальная версия требований существует только в чьей-то памяти.

Где здесь ИИ

Языковые модели заметно сдвинули эту работу, но не там, где ожидают.

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

Вредит. Когда ТЗ целиком генерируется по короткому запросу. Получается гладкий документ на тридцать страниц, где все формулировки правильные, а конкретики нет ни в одной. Такой текст выглядит как ТЗ, проходит согласование и разваливается на первом же спорном вопросе, потому что за ним не стоит ни одного разговора с теми, кто будет работать в системе.

Если писать ТЗ некому

Обычная ситуация. Внутри есть понимание задачи, но нет человека, который переведет его в документ, а разработчик просит ТЗ, чтобы назвать цену.

Варианты по порядку затрат:

• Описать своими словами и отдать на доработку. Достаточно перечислить роли, действия каждой роли и то, что должно получиться. Все остальное достраивается вопросами.
• Заказать ТЗ отдельной работой. Обычно это одна-две недели интервью и прототипов. Документ остается у заказчика и подходит для запроса цены у нескольких подрядчиков.
• Начать с прототипа вместо документа. Для нового продукта кликабельный прототип часто честнее текста: на экранах сразу видно, что противоречит.

Нормальный признак подрядчика — он задает неудобные вопросы до сметы, а не после. Если цена названа без единого уточняющего вопроса, она либо с большим запасом, либо будет расти по ходу.

Дальше по теме