Эту страницу открывают, когда задачи слишком рано попадают в работу: требования сырые, сценарии неполные, зависимости не прояснены, критерии проверки не собраны, а команда всё равно начинает делать «чтобы не тормозить».
Definition of Ready создаёт минимальный порог качества входа в исполнение. Это не про бюрократию, а про снижение лишней неопределённости до старта работ.
Что это за компетенция
Это умение определить и удерживать набор условий, при которых задача, история, требование или кусок работ считаются достаточно подготовленными для старта.
DoR нужен не для идеальной проработки всего на свете, а для того, чтобы команда не работала на голых предположениях.
Зачем нужна
Навык нужен, чтобы:
- уменьшать хаос на старте задач;
- улучшать точность оценки;
- сокращать объём доуточнений уже в процессе работы;
- делать загрузку команды более осмысленной;
- защищать проект от иллюзии прогресса на сыром материале.
Где проявляется в реальной работе
Это особенно важно:
- в итерационной разработке;
- перед планированием спринта или этапа;
- перед передачей задач исполнителям;
- в проектах, где нет сильного аналитического входа;
- при работе без выделенного BA.
Что ломается без неё
- задачи стартуют на догадках;
- команда тратит время на базовые уточнения во время выполнения;
- оценки системно неточны;
- блокеры появляются в первый же день работы;
- PM путает занятость команды с реальным движением проекта.
Что можно делегировать, а что нельзя
Нельзя делегировать управленческую ответственность за качество входа в выполнение.
Можно делегировать:
- детализацию отдельных пунктов готовности;
- подготовку шаблона или чек-листа;
- техническую валидацию части условий готовности.
Как выглядит слабый уровень
- задачи идут в работу по принципу «разберёмся по ходу»;
- команда привыкла стартовать без ясных вводных;
- нет минимального общего стандарта качества входа;
- PM замечает сырость только после первых блокеров.
Как выглядит сильный уровень
- есть понятный и реалистичный минимум готовности;
- команда понимает, что можно брать в работу, а что пока рано;
- DoR адаптирован под тип работы, а не висит абстрактным списком;
- входные дыры становятся видны до старта, а не в момент срыва срока.
Как понять, что это ваш пробел
- задачи регулярно доуточняются уже после старта;
- команда жалуется, что получает слишком сырой вход;
- по оценке видно, что неопределённость попадает в работу слишком рано;
- на первых днях выполнения возникает много блокеров и пересборок.
Что делать пошагово
1. Определите, на каком уровне вам нужен DoR: задача, история, эпик, этап. 2. Выделите минимальный набор условий, реально необходимых для старта. 3. Разведите обязательные и желательные пункты. 4. Используйте DoR как рабочий фильтр перед началом выполнения. 5. Разбирайте возвраты и блокеры, чтобы улучшать этот стандарт. 6. Не делайте список избыточным: он должен помогать, а не душить процесс.
Что обычно входит в DoR
- понятное описание задачи;
- бизнес-контекст;
- базовые acceptance criteria;
- ясные зависимости;
- понятный владелец подтверждения;
- отсутствие критичных открытых вопросов для старта.
Практический ориентир
DoR почти никогда не должен быть одинаковым для всех уровней работы. Полезно отдельно отличать:
- DoR для фичи или бизнес-истории;
- DoR для технической задачи;
- DoR для крупного этапа, который идёт в план этапов.
Например, для бизнес-фичи критичны сценарий, владелец решения и критерии проверки. Для технической задачи может быть важнее зависимость, архитектурный контекст и подтверждённый ожидаемый результат. Если этого различия нет, команда либо тонет в лишних требованиях, либо стартует слишком рано.
Как внедрять DoR без войны с командой
Рабочий путь обычно проще, чем кажется:
1. Возьмите реальные недавние срывы на старте задач. 2. Соберите 4-6 пунктов, которых не хватало почти всегда. 3. Согласуйте это как минимальный фильтр, а не как идеальный стандарт. 4. Несколько циклов подряд возвращайте в доработку то, что явно не проходит фильтр. 5. Пересматривайте список, если он перестал помогать.
Так DoR начинает работать как защита команды от сырого входа, а не как декоративный документ.
Когда DoR можно ослабить, а когда нельзя
Ослабление допустимо, если задача короткая, риск низкий, а цена доуточнения невелика. Но если работа влияет на срок этапа, внешний релиз, интеграцию или приёмку, снижение порога готовности почти всегда возвращается потом отклонением, блокером или повторной сборкой требований.
Типовые ошибки
- превращать DoR в огромный чек-лист для галочки;
- требовать идеальной проработки там, где нужна скорость;
- использовать одинаковый DoR для всех типов работ;
- считать DoR формальностью, а не рабочим фильтром.
Как качать навык
- соберите минимальный DoR на основе реальных провалов проекта;
- связывайте его с уточнением требований и backlog hygiene;
- регулярно пересматривайте, какие пункты реально помогают, а какие просто висят в списке.
Связанные материалы
- Definition of Done
- Acceptance criteria
- Backlog hygiene
- Planning