Генератор технического задания

Структура не самоцель: каждый раздел закрывает один типовой спор.

Первые шесть обязательны. Седьмой, восьмой и девятый формально можно пропустить — и именно из-за них работа потом принимается со второго или третьего раза: «а в Safari не работает», «мы неделю ждали доступ», «мы думали, правки бесплатные».

Про состояния

В разделе «как должно работать» чаще всего описывают успешный путь. Между тем половина работы — это пустое состояние, загрузка, ошибка и права доступа. Если они не описаны, исполнитель придумает их сам, и на приёмке они окажутся не такими.

Критерий приёмки — это утверждение, которое можно проверить руками и ответить «да» или «нет», не созваниваясь. Всё остальное — пожелание.

Инструмент проверяет каждую строку по признакам: число, срок, явное «должен / не должен», условие «если …, то …», наблюдаемое действие. Это не разбор смысла — плохую формулировку без стоп-слов он пропустит, а нормальную иногда пометит. Пометка означает «перечитайте эту строку», а не «перепишите».

Сколько критериев нужно: обычно три-семь. Меньше трёх — скорее всего, описан только успешный путь. Больше десяти — в одном ТЗ, вероятно, несколько задач, и их лучше разделить: оценивать и принимать их всё равно придётся отдельно.

Есть слова, которые в ТЗ выглядят безобидно, а на приёмке стоят денег. Инструмент их подсвечивает — не потому что они запрещены, а потому что каждое из них нужно заменить на проверяемый результат.

• «Удобно», «интуитивно понятно», «современно». Оценка, а не требование. Заменяется либо на конкретное поведение («форма отправляется без перезагрузки страницы»), либо на измеримое («задача выполняется не больше чем в три клика»).
• «Быстро». Всегда заменяется числом: «страница открывается за 2 секунды на 4G» — это критерий, «быстро» — нет.
• «И т. д.», «и другие», «при необходимости». Открытая граница работ. Исполнитель заложит в оценку риск, а при приёмке скажет, что это в список не входило. Оба правы, потому что списка нет.
• «Как на референсе». Ссылка на чужой сайт — это не требование: непонятно, что именно вы там увидели. Опишите, что должно повторяться: раскладка, поведение, анимация, состав полей.
• «Небольшая доработка». Оценка объёма — работа исполнителя. В ТЗ это слово только снижает внимание к остальному тексту.

Документ не решает всех проблем, и иногда он просто не тот инструмент:

• Когда вы ещё не знаете, что нужно. ТЗ фиксирует решение. Если решения нет, сначала нужен другой разговор — про проблему, пользователей и варианты. Попытка написать ТЗ в этой точке даёт документ, который переписывают на второй неделе.
• Когда задача исследовательская. «Разобраться, почему падает конверсия» не раскладывается в критерии приёмки. Такие работы принимают по-другому: по отчёту и по списку проверенных гипотез, а не по списку «да / нет».
• Когда работа идёт внутри своей продуктовой команды. Там дешевле короткое описание задачи и разговор, чем документ с девятью разделами. ТЗ в этом виде нужно, когда между заказчиком и исполнителем есть договор, деньги и приёмка.
• Когда ТЗ пишут вместо разговора. Самое подробное задание не заменяет получасового звонка, на котором исполнитель задаёт вопросы. Документ — это протокол договорённости, а не её замена.
• Когда задача одна большая. «Переделать личный кабинет» в одно ТЗ не помещается: критериев приёмки станет тридцать, и принимать их будут месяц. Разбейте на части, которые можно сдать по отдельности.
• Когда его никто не откроет при приёмке. Если работу принимают «на глаз», документ не влияет ни на что. Тогда полезнее короткий чек-лист приёмки — его хотя бы пройдут; собрать такой можно в конструкторе чек-листа.

И честная оговорка про сам инструмент: он проверяет формулировки, а не содержание. ТЗ на ненужную доработку он одобрит, если критерии написаны проверяемо. Вопрос «а нужно ли это делать» решается раньше — например, через приоритизацию RICE.

1. ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» — состав разделов ТЗ; для доработки сайта применяется выборочно, но раздел о требованиях к приёмке полезен.
2. Wiegers K., Beatty J. Software Requirements, 3-е издание, 2013 — признаки хорошего требования: однозначность, проверяемость, полнота; отдельная глава о словах-ловушках.
3. Cohn M. User Stories Applied, 2004 — критерии приёмки как условия, по которым историю считают выполненной.
4. Adzic G. Specification by Example, 2011 — почему примеры и сценарии работают лучше абстрактных формулировок требований.
5. ISO/IEC/IEEE 29148:2018 — характеристики требований: verifiable, unambiguous, singular.