DoR открывают, когда команда регулярно берёт в работу задачи, которые ещё не готовы к старту: неясный результат, размытые условия, недостающие вводные, скрытые зависимости. В такой среде проблема проявляется не на intake, а уже в середине delivery, когда время и внимание уже потрачены.
Что это за подход
Definition of Ready полезен как рамка минимальной готовности задачи к началу работы. Для PM это способ уменьшать хаос на входе и отделять «можно брать» от «ещё нужно подготовить».
Когда он нужен
- backlog часто сырой и неоднородный;
- planning перегружается уточнением деталей;
- задачи заходят в работу с большим количеством скрытых вопросов;
- команде важно защищаться от преждевременного старта.
Когда он не нужен
- если среда совсем маленькая и понятная без отдельной рамки;
- если DoR превращается в жёсткий барьер для любой мелочи;
- если команда слепо следует чеклисту, не думая о контексте.
Что из него реально применимо для PM
- делать готовность задач видимой;
- снижать разрывы между требованием и стартом работы;
- улучшать качество planning и refinement;
- раньше поднимать нехватку контекста, решения или owner.
Какие артефакты, ритуалы и правила важны
- короткий и понятный список критериев ready;
- связь с refinement и planning;
- возможность адаптировать рамку под тип задачи;
- регулярный пересмотр, если рамка перестаёт помогать.
Какие ошибки чаще всего делают при внедрении
- делают DoR слишком длинным и тяжёлым;
- применяют одинаково к любому типу работы;
- используют его как оправдание не брать неудобные задачи;
- не объясняют, зачем критерии вообще нужны.
Чем можно заменить или упростить
- коротким ready-check на ближайший planning;
- гигиеной бэклога, если проблема шире, чем только вход в работу;
- prep-шаблоном для типовых задач.