Definition of Ready: как не брать в работу «сырые» задачи
Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов?
В итоге половина запланированного времени уходит на уточнения, описания и переделку того, что уже сделали (привет, миграции Liquibase!).
В таких случаях стоит внедрить в процессы команды практику Definition if Ready (DoR). DoR — это парная практика к Definition of Done, которую мы разбирали чуть раньше.
📉 Почему «начнём разбираться в процессе» — это налог на команду
Множество людей (и я в их числе :) считают, что можно взять задачу в работу даже в условиях высокой неопределенности. На практике это приводит к тому, что команда платит «высокий налог» на неопределенность:
⏱️ Постоянные уточнения вместо разработки.
⏱️ Частое переключение фокуса между задачей и согласованием.
⏱️ Увеличение числа переделок.
⏱️ Блокеры, которые можно было бы снять заранее.
В результате значительная часть времени работы команды уходит на выяснение требований и постоянные переделки.
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
Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов?
В итоге половина запланированного времени уходит на уточнения, описания и переделку того, что уже сделали (привет, миграции Liquibase!).
В таких случаях стоит внедрить в процессы команды практику Definition if Ready (DoR). DoR — это парная практика к Definition of Done, которую мы разбирали чуть раньше.
📉 Почему «начнём разбираться в процессе» — это налог на команду
Множество людей (и я в их числе :) считают, что можно взять задачу в работу даже в условиях высокой неопределенности. На практике это приводит к тому, что команда платит «высокий налог» на неопределенность:
⏱️ Постоянные уточнения вместо разработки.
⏱️ Частое переключение фокуса между задачей и согласованием.
⏱️ Увеличение числа переделок.
⏱️ Блокеры, которые можно было бы снять заранее.
В результате значительная часть времени работы команды уходит на выяснение требований и постоянные переделки.
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