Definition of Ready — критерии, которые спасут ваш проект от правок
Что такое DoR и почему он важнее, чем вы думаете. Практические советы для руководителей
Представьте: вы запускаете спринт, команда мотивирована, сроки согласованы. Но уже на третий день все буксует. Разработчик начинает писать код, но ТЗ составлено только наполовину. Дизайнер ждет бриф, но его никто не заполняет. Тестировщик не понимает, что нужно проверять в первую очередь. Менеджер в панике собирает экстренные созвоны. Заказчик злится, что ничего не готово.
В результате сроки горят, команда перерабатывает, качество падает. В Agile-проектах эту проблему решают с помощью Definition of Ready — набора критериев, которые защищают специалистов от сырых задач: без четкой цели, деталей и нужных материалов. Разберем, что такое DoR, зачем он нужен, чем отличается от Definition of Done и как использовать критерии так, чтобы они не превратился в бюрократию.
Что такое DoR (Definition of Ready)
Definition of Ready — это четкий, измеримый и согласованный командой набор критериев, которому должна соответствовать поставленная задача.
Если коротко, DoR отвечает на вопрос: «Готовы ли мы начинать работу по задаче прямо сейчас без дополнительных уточнений?»
Цель DoR — убрать неопределенность на старте работы и гарантировать, что у исполнителей есть все необходимое для успешного выполнения задачи.
Это помогает:
- точнее предсказывать сроки выполнения: команда знает, что на старте у нее есть все входные данные;
- избегать уточнений, на которые теряется время;
- фокусироваться на приоритетных задачах вместо того, чтобы копить невыполненные.
Зачем нужен DoR и что он дает
Definition of Ready помогает команде начинать только те задачи, которые действительно готовы к работе — с понятной целью, полным контекстом и нужными материалами. Это повышает качество выполнения работы и уменьшает количество переделок.
Разберем, чем DoR полезен для каждой стороны процесса.
DoR и DoD: в чем главное отличие
Эти два понятия часто путают в Agile. DoR и DoD действительно похожи по форме — оба определяют критерии, — но отвечают за разные этапы.
Definition of Done (DoD) — критерии, по которым команда понимает, что задача завершена. Например, не просто «написан код», а «приложение протестировано, подготовлена документация и все готово к использованию».
Простой способ запомнить:
- DoR = фильтр на входе — не начинаем, пока все не готово;
- DoD = фильтр на выходе — не заканчиваем, пока все не соответствует договоренности.
Если DoR отвечает на вопрос, когда можно начинать, то DoD — когда можно заканчивать.
Если одного из набора критериев нет, это отражается на процессе. Без DoR в работу попадают непонятные задачи, без DoD — результат получается недоделанным.
Как создать свой DoR: пошаговое руководство
Единого готового шаблона нет — набор критериев зависит от вашей команды, продукта и типа задач. Но есть рабочий алгоритм.
Шаг 1. Соберите «боли». На ретроспективе обсудите, что чаще всего мешает старту задач, например:
- нет ТЗ или оно неполное,
- непонятны приоритеты,
- нет доступов, данных или тестовой среды,
- нет утвержденных макетов.
Шаг 2. Проведите брейншторм критериев. Ответьте на вопрос: «Какая информация, ресурсы или условия нужны, чтобы мы могли стартовать без пауз?» Запишите все, что придет в голову.
Шаг 3. Сформулируйте критерии. Они должны быть:
- нет ТЗ или оно неполное,
- непонятны приоритеты,
- нет доступов, данных или тестовой среды,
- нет утвержденных макетов.
Для формулирования критериев советуем использовать принцип SMART.
Шаг 4. Согласуйте список. Финальный вариант утверждается всей командой. Каждый должен понимать и принимать критерии.
Шаг 5. Адаптируйте. Начните с минимального набора — 3–5 пунктов. Смотрите, как они работают, и дорабатывайте на ретроспективах.
Примеры DoR для разных задач
Ключевая сила DoR в его адаптивности. Критерии готовности должны быть релевантными для конкретного типа задачи. Вот как могут выглядеть примеры DoR.
Для разработчиков: Definition of Ready можно использовать разработчикам: он позволяет четко определить, когда задача (например, реализация нового API-эндпоинта или исправление бага) действительно готова к началу кодирования.
Это гарантирует, что у них есть все необходимое: утвержденные требования, дизайн, критерии приемки, решенные зависимости, тестовые данные и доступ к средам, что минимизирует простои и правки.
Для дизайнеров: позволяет убедиться, что задача имеет достаточно вводных для старта работы. Это означает наличие утвержденного брифа с целями пользователя, пользовательских сценариев, данных о целевой аудитории, бренд-гайдов и понимание технических ограничений, что фокусирует творческий процесс на решении реальных задач.
Для маркетологов: позволяет синхронизировать команду перед запуском кампании, например, email-рассылки или рекламной акции, подтверждая готовность всех ключевых элементов. Это могут быть утвержденные цели, KPI, финальное ценностное предложение, готовые сегменты аудитории, контент-план и ресурсы, что снижает риски сбоев и повышает согласованность действий.
Внедряем DoR в Kaiten
Kaiten дает готовые инструменты, чтобы превратить DoR из теории в практику. Вот инструменты, которые вы можете использовать.
Чек-листы
Фиксируйте в карточке критерии готовности задачи к работе. Таким образом, они будут всегда на виду.
В Kaiten вы можете настроить автоматическое добавление чек-листа в карточку — DoR будут появляться, как только задача появится на доске исполнителя.
Ограничение передвижения карточек в колонку «В работе»
Чтобы команда не забывала проверять готовность задачи, в Kaiten можно запретить передвижение карточки в следующую колонку, пока не выполнены все пункты чек-листа. Эта функция доступна в Модуле Ограничения.
Ответственные за пункт чек-листа и сроки
Чтобы задача была комплексно проработана, иногда ее должны посмотреть несколько специалистов. В Kaiten можно назначить ответственного на выполнение пункта чек-листа.
Также вы можете установить срок. Как только дедлайн будет близко, ответственному придет напоминание.
С какими трудностями сталкиваются при внедрении DoR и как поможет Kaiten
Даже полезные инструменты могут работать плохо, если их использовать неправильно. Вот 4 ошибки, которые допускают чаще всего, когда внедряют DoR.
- DoR превращается в бюрократию. Часто команды, вдохновившись идеей DoR, создают слишком длинный список критериев — по 10–15 пунктов. На проверку каждого уходит время, что тормозит работу. В итоге его перестают использовать.
Решение: начните с минимального жизнеспособного набора — 3–5 пунктов, которые реально влияют на качество старта задачи. Фиксируйте в Kaiten идеи по улучшению DoR прямо в отдельной колонке. То есть, у вас на пространстве будет доска с рабочими задачами и небольшая доска с идеями доработки DoR. Разбирайте предложения членов команды на ретроспективах, и меняйте критерии.
- Ответственность за выполнение DoR размыта. Если команда не понимает, кто именно должен проверять готовность задачи по каждому пункту DoR, критерии частично выполняются или не выполняются вовсе. Например, доступы не выданы, так как «думали, что это делает руководитель», или макет не приложен, «ведь это вроде задача дизайнера».
Решение: в Kaiten можно назначить ответственного не только за выполнение всей задачи, но и каждого пункта чек-лист внутри карточки. Это снижает риск, что критичный элемент останется без внимания.
- DoR игнорируется. Под давлением сроков или из-за неопытности команда иногда пропускает проверку DoR, чтобы побыстрее начать работу. Итог — задержки и переделки в процессе.
Решение: настройте автоматические правила, которые не дадут перемещать задачи в колонку «В работе», пока все пункты DoR не выполнены.
- DoR не проверяют и критерии устаревают. То, что было актуально на старте работы команды, через полгода может стать избыточным или, наоборот, недостаточным. Если DoR не пересматривать, он перестанет помогать.
Решение: встроите обсуждение DoR в регулярные ретроспективы. Это позволит быстро вносить изменения и собирать пожелания всех членов команды.
Итог
Definition of Ready — инструмент, который превращает хаос на старте задач в управляемый процесс. Для руководителя он означает:
- предсказуемость сроков,
- прозрачность процессов,
- снижение рисков.
Для команды — четкие правила старта работы, меньше стресса и больше фокуса.
А в связке с Kaiten DoR становится не абстрактной идеей, а частью повседневного рабочего процесса — без лишней бюрократии и с реальными результатами.
