Техническое задание ценно перечнем того, что в него не входит
В нашем регламенте техническое задание стояло между уточнением задачи и оценкой трудозатрат. Формально это документ о том, что будет сделано. Практически его ценность определялась другим разделом — перечнем того, что в работу не входит.
Разница видна в момент, когда заказчик просит «мелочь». Если в ТЗ описано только включённое, любая просьба выглядит уточнением в рамках согласованного. Если есть перечень исключений, та же просьба сразу опознаётся как изменение объёма — и разговор идёт о сроке и цене, а не о добросовестности.
Техническое задание — инструмент управления ожиданиями, а не описание решения. Его рабочая часть — перечень исключений, потому что он превращает будущее уточнение из бесплатного дополнения в отдельное решение. Данные о волатильности требований показывают статистически значимую связь изменений объёма с превышением сроков и бюджета, а исследования неоднозначности — что формальность документа сама по себе от разночтений не спасает.
Что делает перечень исключений
Разберём его функции по отдельности — их четыре, и ни одна не связана с описанием технического решения.
Переводит уточнение в решение. Пока граница не обозначена, каждая просьба обсуждается как вопрос отношений: пойти навстречу или нет. После обозначения границы обсуждается объём: включаем в текущий этап или в следующий, с каким сроком и на каких условиях.
Защищает обе стороны, а не одну. Заказчик получает понимание, за что он не платит и чего не получит, — это часто важнее списка включённого. Ошибка думать, что перечень исключений выгоден только исполнителю: без него заказчик обнаруживает недостающее после сдачи.
Делает оценку осмысленной. Оценить можно только ограниченный объём. Перечень исключений и есть та граница, относительно которой число имеет смысл; без неё оценка становится репликой в переговорах, а не стадией процесса.
Выявляет несовпадение картин мира до работы. Самая полезная функция. Заказчик читает перечень исключений внимательнее, чем описание работ, — потому что там написано, чего он не получит. Именно на этом чтении и обнаруживаются расхождения, которые иначе всплыли бы на приёмке.
| Раздел ТЗ | Кто его читает внимательно | Когда срабатывает |
|---|---|---|
| Описание решения | Исполнитель | При разработке |
| Перечень работ | Обе стороны при согласовании | При оценке |
| Перечень исключений | Заказчик | При первом уточнении и на приёмке |
| Критерии приёмки | Обе стороны в конце | При сдаче |
Второй столбец объясняет типичный перекос: документ пишется исполнителем и для исполнителя, поэтому раздел про решение получается подробным, а про исключения — коротким или отсутствующим. Между тем именно второй раздел определяет, как пройдут следующие три месяца.
Чего стоит подвижность объёма
Связь между изменениями требований и результатом проекта измерена, и цифры полезно знать до того, как согласовывать «мелочь».
Волатильность требований статистически значимо связана с превышением сроков и бюджета проекта. Только 14% проектов в выборке завершились раньше срока и в рамках бюджета; большинство вышло за график на 25–50% и за бюджет на 4–25%.
Ограничения существенные: это опрос, а не контролируемый эксперимент, доля ответивших 21% создаёт риск смещения в сторону респондентов с проблемными проектами, и работе больше двадцати лет. Использую её как указание на устойчивую связь, а не как норматив. Механизм при этом не устарел: изменение объёма без пересмотра срока и цены — это перенос риска на исполнителя, и он реализуется в статистике.
Почему формальность документа не спасает
Второе распространённое заблуждение: чем формальнее и подробнее ТЗ, тем меньше разночтений. Экспериментальная проверка даёт другой ответ.
Инспекция одного документа требований силами трёх рецензентов за 4,5 часа выявила 58 неоднозначностей: 4 собственно языковые и 54 специфичные для инженерии требований. Авторы предлагают выявлять неоднозначности инспекцией до написания формальной спецификации, а не после.
Масштаб эксперимента невелик — по сути кейс на одном документе с серией упражнений, и это ограничение я называю прямо. Но соотношение 4 к 54 показательно: подавляющее большинство разночтений возникает не из-за языка, а из-за предметных пробелов — того, что стороны считали само собой разумеющимся и потому не записали. Перечень исключений работает именно с этим слоем.
Что говорит стандарт
Международный стандарт ISO/IEC/IEEE 29148 регламентирует процессы инженерии требований для систем и программных продуктов. Издание второе, 2018 год, подтверждено без изменений в 2024-м.
Здесь нужна честность, которой обычно не хватает в ссылках на стандарты. Полный текст платный, я читал только официальную аннотацию с описанием предмета и области применения. Часто цитируемый список характеристик хорошего требования — полнота, непротиворечивость, проверяемость — по первоисточнику я не сверял и потому не привожу как цитату. Использую ссылку только для одного: подтвердить, что требования считаются самостоятельной инженерной дисциплиной со своим стандартом, а не приложением к договору.
Как писать перечень исключений
Второй источник — самый ценный и самый недооценённый. Список того, что обычно просят на проектах такого типа, накапливается из прошлого опыта и превращает перечень исключений из формальности в инструмент: он предугадывает разговор, который иначе состоится через месяц в худших условиях.
Третий источник снимает целый класс конфликтов. Всё, что зависит от третьей стороны — доступы, материалы, согласования, — должно быть названо явно вместе с последствиями задержки. Иначе задержка третьей стороны станет проблемой исполнителя по умолчанию.
Четыре правила для рабочего ТЗ
Пишите исключения раньше включений
Начав с того, что не входит, вы получите более точный список того, что входит.
Ведите список типовых просьб
То, что обычно просят на таких проектах. Он накапливается за год и экономит месяцы споров.
Назовите зависимости от третьих сторон
Доступы, материалы, согласования и последствия их задержки. Явно, с датами.
Опишите порядок изменения объёма
Не запрет на изменения — они неизбежны, — а правило: что происходит с оценкой и сроком.
Если в техническом задании нет раздела о том, что в работу не входит, документ описывает намерения исполнителя, а не границы проекта.
Вопросы, которые задают чаще всего
Что обязательно должно быть в техническом задании?
Четыре раздела: перечень работ, перечень того, что в работу не входит, зависимости от третьих сторон с последствиями задержки и порядок изменения объёма. Описание технического решения полезно, но необязательно и часто вредно на раннем этапе: оно фиксирует способ до того, как понята задача. Практически рабочая часть документа — второй и четвёртый разделы.
Как реагировать на просьбу «добавить мелочь»?
Сверять с перечнем исключений, а не оценивать по трудоёмкости. Если пункт в перечне есть, разговор идёт о сроке и цене и занимает пять минут. Если пункта нет — это повод дополнить перечень на будущее, а текущую просьбу решить по правилу изменения объёма. Опасна не сама мелочь, а накопление мелочей без единого разговора.
Помогает ли подробное ТЗ избежать разночтений?
Частично. Экспериментальная инспекция документов требований показывает, что подавляющее большинство найденных неоднозначностей — не языковые, а предметные: пробелы в том, что стороны считали очевидным. Объём документа с этим не справляется, а инспекция до формализации — справляется. Практический приём: дать документ прочитать человеку, не участвовавшему в его составлении, и записать все его вопросы.
Нужно ли ТЗ, если работаем итерациями?
Нужен его рабочий слой — граница текущей итерации и правило изменения объёма. Полное описание всего проекта в итеративной работе действительно бессмысленно: требования меняются, и данные о волатильности показывают, что это норма, а не отклонение. Но граница итерации и порядок пересмотра нужны тем более, потому что изменений больше.
Место технического задания в процессе (между уточнением задачи и оценкой трудозатрат) и стадийность работы с клиентом — из регламента взаимодействия Alego.Digital. Примеры технических заданий, на которых основано описание структуры документа, — из проектного архива компании (техзадания для консалтинговой группы и промышленного предприятия, 2026). Это внутренние материалы компании автора; они не проверялись независимой стороной и приводятся как иллюстрация механики. Правило ведения накопительного списка типовых просьб — авторская практика, в документах компании не формализованная.
- Zowghi D., Nurmuliani N. A Study of the Impact of Requirements Volatility on Software Project Performance. APSEC, 2002. opus.lib.uts.edu.au
- Kamsties E., Berry D. M., Paech B. Detecting Ambiguities in Requirements Documents Using Inspections. WISE, 2001. cs.uwaterloo.ca
- ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. iso.org