Definition of Ready: как не брать в работу «сырые» задачи

Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов?

В итоге половина запланированного времени уходит на уточнения, описания и переделку того, что уже сделали (привет, миграции Liquibase!).

В таких случаях стоит внедрить в процессы команды практику Definition if Ready (DoR).


📉 Почему «начнём разбираться в процессе» — это налог на команду

Множество людей (и я в их числе :) считают, что можно взять задачу в работу даже в условиях высокой неопределенности. На практике это приводит к тому, что команда платит «высокий налог» на неопределенность:

⏱️ Постоянные уточнения вместо разработки.
⏱️ Частое переключение фокуса между задачей и согласованием.
⏱️ Увеличение числа переделок.
⏱️ Блокеры, которые можно было бы снять заранее.

В результате значительная часть времени работы команды уходит на выяснение требований и постоянные переделки.

Definition of Ready — это способ уменьшить этот налог.


🔄 DoR: что должно быть у задачи, прежде чем отдать ее в разработку

Definition of Ready — это четкий набор критериев, согласованный в команде, которым должна соответствовать задача, прежде чем ее возьмут в разработку.

DoR отвечает на вопрос: «Готовы ли мы начать работу над задачей прямо сейчас, не отвлекаясь на бесконечные уточнения?» Это фильтр на входе, который защищает команду от сырых и непроработанных задач.

Как и Definition of Done, DoR не должен содержать чек-лист из 50 пунктов. Это несколько, обычно 5–7 критериев, которые защищают от ключевых рисков. Вот некоторые универсальные критерии:

✅ Четкое описание — задача описана понятно, есть цель (в том числе и бизнес-цель), контекст и ожидаемый результат.

✅ Есть критерии приемки — четкие, проверяемые условия, по которым понятно, что задача сделана.

✅ Дизайн/макеты/API спецификация готовы — все, что нужно, доступно и согласовано.

✅ Технические зависимости закрыты: контракты API со смежными командами согласованы, доступы получены, архитектурное решение (если задача крупная) утверждено.

✅ Задача декомпозирована — размер задачи позволяет закрыть ее в рамках одной итерации.

Если хотя бы один из критериев DoR не выполнен, задача не готова к передаче в разработку. Она готова к обсуждению, спецификации и проектированию, но не к разработке.


📝 Важное уточнение: DoR — это ответственность команды, не только бизнеса

Частая ошибка — относиться к DoR как к требованию к бизнесу. Это не передача задачи от бизнеса в разработку.

Это командная работа — подготовить задачу так, чтобы она удовлетворяла критериям DoR. Требуется, чтобы бизнес описал потребность, архитекторы приняли решения о том, какие системы менять, а команда разработки заполнила детали реализации.


🛡 Как сказать «нет» задаче на планировании без конфликта

Здесь можно воспользоваться рекомендациями из поста про то, [как выдержать давление при оценках]. DoR — это легальный способ перевести эмоциональный разговор в процессный:

🔄 Смена фрейма — задача важная, но сейчас не закрыты все DoR-критерии, давайте вернем ее в бэклог и доработаем, чтобы защитить качество и сроки разработки.

🗣 «Да, и…» — да, мы готовы взять задачу в разработку, но для этого нам нужны макеты до среды. Если дизайн будет готов, то задача пойдет в работу на следующей неделе.

🎯 Вопрос-возврат — нам важнее закрыть бэклог на спринт или взять в работу задачу, которую реально доведем до продакшена?


💡 Вместо вывода

Definition of Ready — это не бюрократия, не способ загрузить бизнес бумажной и формальной работой. Это инвестиция в предсказуемость.

Команда, которая использует DoR:

✅ Меньше простаивает в ожидании ответов;
✅ Реже переделывает уже написанное;
✅ Точнее попадает в оценки;
✅ Сохраняет фокус и мотивацию
.
Начните с малого: выберите 3–4 самых критичных пункта DoR и попробуйте применять их.

#DoR #agile #scrum #processes #management #TeamLead #team