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 #СистемныйПодход
· 03.07
ЧТЗ обычно спасает. И обязательная постоянная коммуникация с заказчиком( ни в коем случае не уходить даже с согласованным ТЗ в разработку без уточнений по блокам). По моему опыту успешная реализация возможна только при продуктовом подходе( заказчик часть команды). Это дает и большую вовлеченность и более предсказуемый результат. В ТЗ/ЧТЗ как бы хорошо они ни были написаны- что-то не будет учтено/ размытая формулировка . Были случаи когда при демонстрации на вопрос заказчика: вы зачем так сделали? Ответ исполнителя: я так увидел. В итоге видение ушло в убытки. Пришлось переделывать.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён