DoR/DoD vs ТЗ: архитектура старта проекта

Конфликты на этапе приёмки редко связаны с качеством исполнения. Их корень — системный дефект управления требованиями и отсутствие формализованных ворот качества на старте. «Сделали не то» — это симптом размытых границ содержания и отсутствия механизма верификации.

В методологии (PMI, ISO 21502) стартовая фаза определяет траекторию всего жизненного цикла. На практике это сводится к выбору одной из двух архитектур доставки, каждая из которых требует строгой дисциплины.

Архитектура 1: Фиксированное ТЗ и каскадная верификация Применяется при стабильных требованиях и жёстких ограничениях. Ключевые элементы: • Детализация требований до уровня измеримых Acceptance Criteria. Формулировки вида «удобно» заменяются на сценарии «дано/когда/тогда» с количественными порогами. • Трассируемость требований: каждая задача в плане маппится на пункт ТЗ. Это исключает дрейф содержания и scope creep. • Formal Change Control: любая модификация после baseline проходит через Impact Analysis (оценка влияния на срок, бюджет, ресурсы) и утверждение CCB.

Архитектура 2: Итеративная доставка и критерии готовности (DoR/DoD) Применяется в условиях высокой неопределённости. Здесь ТЗ заменяется системой управленческих соглашений: • Definition of Ready (DoR): задача берётся в работу только при наличии чётких требований, проверенных зависимостей, доступных ресурсов и согласованных метрик успеха. • Definition of Done (DoD): единый стандарт завершения, включающий покрытие тестами, обновление документации, соответствие SLA, отсутствие критических дефектов и подтверждение стейкхолдеров. • Ритм валидации: регулярные демо с прогоном сценариев, а не демонстрацией слайдов. Feedback loop замыкается на бэклог, предотвращая накопление продуктового долга.

«Качество не проверяется в конце процесса. Оно проектируется в требованиях и валидируется на каждом этапе жизненного цикла» (принципы TQM и ISO 9001:2015).

Выбор модели не отменяет главного правила: ни одна работа не начинается без зафиксированных критериев приёмки. Смешивание подходов (например, «гибкие итерации» без DoD или «ТЗ» без процедуры изменений) — гарантированный путь к процессной энтропии.

#ИнсафВафин #RequirementsEngineering #PMBOK #AgileGovernance #QualityManagement #СистемныйПодход

DoR/DoD vs ТЗ: архитектура старта проекта | Сетка — социальная сеть от hh.ru DoR/DoD vs ТЗ: архитектура старта проекта | Сетка — социальная сеть от hh.ru