Сроки в заказных проектах срывает не код. Их срывают требования – нечёткие, противоречивые и меняющиеся в середине разработки. Команда пишет систему по одному пониманию задачи, заказчик ждёт другую, а на приёмке выясняется, что согласованного документа, к которому можно апеллировать, попросту нет. Управление требованиями – это дисциплина, которая закрывает этот разрыв до того, как он превратится в просроченные сроки и перерасход бюджета.

Соберите и зафиксируйте, а не «обсудите»

Устные договорённости не считаются. Требование живёт только тогда, когда оно записано, пронумеровано и подтверждено подписью обеих сторон. На старте проекта мы разделяем требования на функциональные (что система делает), нефункциональные (производительность, нагрузка, безопасность, доступность) и ограничения (интеграция с действующими учётными системами, требования регуляторов, форматы обмена данными).

В госсекторе и на крупных предприятиях большая часть требований приходит не от пользователя, а из нормативки и из соседних систем. Поэтому требования по защите персональных данных в свете 152-ФЗ закладываются в техническое задание сразу, а не дописываются на этапе сдачи. Если система разворачивается в смешанном контуре, ограничения гибридного ИТ-ландшафта – тоже требование, и его надо описать в тех же терминах, что и бизнес-логику.

Каждое требование проверяйте на три вещи: оно проверяемо, непротиворечиво и реализуемо в заявленный срок. Формулировка «система должна работать быстро» – это не требование. «Формирование отчёта по 100 000 записей – не дольше 8 секунд» – требование.

Контроль изменений вместо запрета изменений

Запрещать изменения бессмысленно: бизнес и законодательство меняются быстрее, чем идёт разработка. Опасны не изменения, а изменения неучтённые. Поэтому в проекте работает простое правило: любое новое требование проходит через оценку влияния – на сроки, на бюджет, на уже написанные модули. Заказчик видит цену правки до того, как её внесли, и принимает решение осознанно.

Базовый объём работ (baseline) фиксируется в начале каждой итерации. Всё, что приходит сверх него, попадает в журнал изменений и переоценивается отдельно. Так «ползучее расширение» объёма перестаёт быть невидимым – оно становится строкой в смете, по которой стороны договариваются явно.

Трассировка: от требования до строки кода

Когда система состоит из десятка модулей и интеграций, нужно в любой момент ответить: откуда взялась эта функция и что сломается, если требование изменить. Матрица трассировки связывает требование с проектным решением, с конкретным кодом и с тестовым сценарием. Это не бюрократия ради бюрократии – это страховка. На приёмке вы по матрице показываете, что каждое согласованное требование закрыто тестом, а на этапе сопровождения быстро находите, какие компоненты затронет очередная доработка.

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

Вывод

Управление требованиями не делает проект медленнее – оно делает сроки предсказуемыми. Зафиксированный объём, дисциплина изменений и трассировка превращают разработку из переговоров на приёмке в управляемый процесс. Если вам нужна система, которую сдадут в срок и без сюрпризов, начните с требований: на них держится вся заказная разработка бизнес-систем.