Definition of Ready: как не отдавать в разработку задачу-тыкву
Definition of Ready: как не отдавать в разработку задачу-тыкву
Задача попадает в разработку.
Исполнитель назначен.
Срок уже обсуждают.
В Jira статус «В работе».
Через час появляются первые вопросы:
— а какую проблему решаем?
— какой сценарий основной?
— кто принимает результат?
— что делать с пограничными случаями?
— где макеты?
— а зависимость от соседней команды точно закрыта?
Формально задача в работе.
Фактически команда только начала выяснять, что вообще нужно сделать.
И вот здесь начинается дорогой жанр: разработка как способ уточнения требований.
Команда может быстро писать код, оперативно ревьюить и регулярно выкатываться. Но если на вход приходит задача без цели, контекста и критериев готовности, delivery ломается ещё до первой строки кода.
Для этого и нужен Definition of Ready.
Definition of Ready, или DoR, — это договорённость команды о минимальных условиях, при которых задачу можно брать в работу.
Не огромный чек-лист.
Не новая церемония.
Не бюрократический забор вокруг разработки.
А простой фильтр от задач вида:
- «сделайте примерно как у конкурента»;
- «надо срочно, детали уточним потом»;
- «там всё понятно»;
- «начните пока, а бизнес определится по ходу».
То есть от классического управленческого оптимизма, оплаченного временем разработчиков.
Что может входить в DoR для обычной продуктовой задачи:
- понятна цель изменения;
- описан ожидаемый результат;
- есть критерии приёмки;
- определены основные сценарии;
- известны зависимости;
- доступны макеты, контракты или нужные данные;
- понятно, кто отвечает на вопросы;
- задача достаточно мала, чтобы её можно было закончить;
- команда видит основные риски.
Важно: DoR зависит от типа задач.
Для бага он один.
Для продуктовой фичи другой.
Для исследования третий.
Для срочного инцидента вообще могут быть отдельные правила.
Если сделать один универсальный список на 37 пунктов, команда быстро научится его ненавидеть. И будет права.
DoR должен помогать стартовать осознанно, а не превращать подготовку задачи в археологическую экспедицию.
Простой пример.
Без DoR задача уходит в разработку, а потом:
- два дня ждут уточнений;
- переделывают решение после первого показа;
- внезапно находят зависимость от другой команды;
- выясняют, что критерии приёмки все понимали по-разному.
С DoR часть проблем всплывает до старта:
- нет решения по спорному сценарию;
- не готов контракт;
- объём слишком большой;
- непонятно, кто принимает результат.
Задача стартует позже на день, но заканчивается раньше на неделю.
Иногда «быстрее начать» и «быстрее закончить» находятся по разные стороны здравого смысла.
Теперь важное ограничение.
DoR тоже можно испортить.
Он вреден, если:
- чек-лист используют механически;
- аналитики месяцами готовят «идеальную» задачу;
- разработчики прячутся за DoR и отказываются обсуждать неопределённость;
- DoR становится способом перебрасывать ответственность;
- одно правило применяют к фичам, багам, исследованиям и инцидентам.
Хороший DoR не говорит: «мы не начнём, пока всё не идеально».
Он говорит: «мы понимаем достаточно, чтобы начать без очевидного самообмана».
Как внедрить без MBA и процессного театра:
1. Возьмите пять последних задач, которые задержались.
2. Посмотрите, какой информации не хватало на старте.
3. Найдите 4–6 повторяющихся пунктов.
4. Сделайте из них первый Definition of Ready.
5. Через месяц проверьте, стало ли меньше зависаний и переделок.
Не надо начинать с идеального процесса.
Начните с того, что реально болит.
Хороший Definition of Ready не гарантирует, что задача пройдёт идеально.
Он просто снижает вероятность, что разработка станет местом, где команда впервые начинает понимать требования.
А какая информация чаще всего отсутствует в ваших задачах на старте: цель, критерии приёмки, макеты, зависимости или владелец решения?
Задача попадает в разработку.
Исполнитель назначен.
Срок уже обсуждают.
В Jira статус «В работе».
Через час появляются первые вопросы:
— а какую проблему решаем?
— какой сценарий основной?
— кто принимает результат?
— что делать с пограничными случаями?
— где макеты?
— а зависимость от соседней команды точно закрыта?
Формально задача в работе.
Фактически команда только начала выяснять, что вообще нужно сделать.
И вот здесь начинается дорогой жанр: разработка как способ уточнения требований.
Команда может быстро писать код, оперативно ревьюить и регулярно выкатываться. Но если на вход приходит задача без цели, контекста и критериев готовности, delivery ломается ещё до первой строки кода.
Для этого и нужен Definition of Ready.
Definition of Ready, или DoR, — это договорённость команды о минимальных условиях, при которых задачу можно брать в работу.
Не огромный чек-лист.
Не новая церемония.
Не бюрократический забор вокруг разработки.
А простой фильтр от задач вида:
- «сделайте примерно как у конкурента»;
- «надо срочно, детали уточним потом»;
- «там всё понятно»;
- «начните пока, а бизнес определится по ходу».
То есть от классического управленческого оптимизма, оплаченного временем разработчиков.
Что может входить в DoR для обычной продуктовой задачи:
- понятна цель изменения;
- описан ожидаемый результат;
- есть критерии приёмки;
- определены основные сценарии;
- известны зависимости;
- доступны макеты, контракты или нужные данные;
- понятно, кто отвечает на вопросы;
- задача достаточно мала, чтобы её можно было закончить;
- команда видит основные риски.
Важно: DoR зависит от типа задач.
Для бага он один.
Для продуктовой фичи другой.
Для исследования третий.
Для срочного инцидента вообще могут быть отдельные правила.
Если сделать один универсальный список на 37 пунктов, команда быстро научится его ненавидеть. И будет права.
DoR должен помогать стартовать осознанно, а не превращать подготовку задачи в археологическую экспедицию.
Простой пример.
Без DoR задача уходит в разработку, а потом:
- два дня ждут уточнений;
- переделывают решение после первого показа;
- внезапно находят зависимость от другой команды;
- выясняют, что критерии приёмки все понимали по-разному.
С DoR часть проблем всплывает до старта:
- нет решения по спорному сценарию;
- не готов контракт;
- объём слишком большой;
- непонятно, кто принимает результат.
Задача стартует позже на день, но заканчивается раньше на неделю.
Иногда «быстрее начать» и «быстрее закончить» находятся по разные стороны здравого смысла.
Теперь важное ограничение.
DoR тоже можно испортить.
Он вреден, если:
- чек-лист используют механически;
- аналитики месяцами готовят «идеальную» задачу;
- разработчики прячутся за DoR и отказываются обсуждать неопределённость;
- DoR становится способом перебрасывать ответственность;
- одно правило применяют к фичам, багам, исследованиям и инцидентам.
Хороший DoR не говорит: «мы не начнём, пока всё не идеально».
Он говорит: «мы понимаем достаточно, чтобы начать без очевидного самообмана».
Как внедрить без MBA и процессного театра:
1. Возьмите пять последних задач, которые задержались.
2. Посмотрите, какой информации не хватало на старте.
3. Найдите 4–6 повторяющихся пунктов.
4. Сделайте из них первый Definition of Ready.
5. Через месяц проверьте, стало ли меньше зависаний и переделок.
Не надо начинать с идеального процесса.
Начните с того, что реально болит.
Хороший Definition of Ready не гарантирует, что задача пройдёт идеально.
Он просто снижает вероятность, что разработка станет местом, где команда впервые начинает понимать требования.
А какая информация чаще всего отсутствует в ваших задачах на старте: цель, критерии приёмки, макеты, зависимости или владелец решения?