Как собрать требования к ИТ-проекту перед оценкой разработки

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

Исходные ожидания, требования, ТЗ, согласованный объем работ, план реализации и discovery не являются одним документом. Если их смешать, оценка выглядит точной, но держится на предположениях. Поэтому требования сначала собирают и нормализуют, а уже потом используют для оценки бюджета, сроков и состава ближайшего этапа.

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

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

• бизнес-цель проекта и проблему, которую должен решить ближайший результат;
• роли пользователей, администраторов, операторов и внешних участников;
• ключевые сценарии, исключения и случаи, где процесс сейчас ломается;
• источники данных, интеграции, справочники, отчеты и ограничения доступа;
• существующие документы, макеты, старые системы, примеры форм и выгрузок;
• требования к программному обеспечению: функции, ограничения, безопасность, нагрузку, журналирование и критерии приемки;
• открытые вопросы, без которых оценка будет только предварительной.

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

• фиксировать источник каждого требования: интервью, документ, система, нормативное ограничение или решение владельца;
• разделять исходные ожидания, подтвержденные требования, гипотезы и отложенные идеи;
• указывать статус: подтверждено, требует проверки, гипотеза, отложено;
• разделять бизнес-требования, функциональные сценарии, ограничения, интеграции и данные;
• назначать приоритет и владельца решения;
• связывать требования с критериями приемки, рисками и вопросами для оценки.

• Исходные ожидания — идеи, письма, интервью, старое ТЗ, макеты и пожелания участников.
• Требования — нормализованные и проверяемые формулировки о том, что система должна уметь или соблюдать.
• ТЗ — документ или пакет документов, где требования уже оформлены для согласования, разработки или закупки.
• Согласованный scope — часть требований, которая входит в текущий этап работ и по которой можно брать обязательства.
• План работ — порядок действий команды, зависимости и контрольные точки.
• Discovery — отдельная проработка, если требований недостаточно для честной оценки или они противоречат друг другу.

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