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 не гарантирует, что задача пройдёт идеально.
Он просто снижает вероятность, что разработка станет местом, где команда впервые начинает понимать требования.
А какая информация чаще всего отсутствует в ваших задачах на старте: цель, критерии приёмки, макеты, зависимости или владелец решения?
👍2
Team Working Agreements: правила команды, которые действительно помогают
Рубрика: «Из жизни тимлида»
В понедельник писал про готовность задач.
Но даже хорошо подготовленная задача может застрять, если у команды нет общих правил работы.
Большинство команд живёт по правилам.
Просто эти правила часто нигде не записаны.
Кто-то считает нормальным поставить встречу на свободное место в календаре.
Кто-то ожидает ревью в тот же день.
Кто-то пишет обо всех блокировках на daily.
Кто-то молчит неделю, потому что «пока пытаюсь разобраться сам».
Кто-то уверен, что открытый PR кто-нибудь обязательно заметит.
В итоге получается распределённая система без протокола.
Что даже для людей несколько рискованно.
А потом команда удивляется конфликтам, задержкам и разным ожиданиям.
Team Working Agreements — это явные договорённости о том, как команда работает вместе.
Не корпоративный кодекс.
Не документ про ценности.
Не «мы уважаем друг друга и стремимся к excellence».
Это практические правила, которые уменьшают неопределённость в ежедневной работе.
Например, команда может договориться:
- где задавать несрочные вопросы;
- когда писать лично;
- что считается срочным;
- за какое время обычно отвечаем;
- какие решения обязательно фиксируем письменно;
- когда встреча действительно нужна;
- можно ли отказаться от встречи без повестки;
- кто назначает ревьюера;
- за какое время PR должен получить первый взгляд;
- когда спор в комментариях пора переносить в разговор;
- сколько задач можно вести одновременно;
- когда задача считается заблокированной;
- когда нужно эскалировать проблему.
Это не звучит как что-то великое и стратегическое.
Но именно на таких мелочах команда часто теряет больше всего времени.
Пример небольшого набора договорённостей:
- блокировка дольше четырёх часов поднимается в командном чате;
- PR получает первый отзыв в течение рабочего дня;
- решение после встречи фиксируется в задаче;
- срочная задача должна сопровождаться решением, что снимается с текущей работы;
- встречи после 16:00 не ставятся без явной необходимости;
- у разработчика одновременно не больше двух активных задач.
Цифры здесь не универсальные.
Их нельзя торжественно скопировать в каждую команду и ожидать наступления инженерного рая.
Смысл не в конкретных числах.
Смысл в том, чтобы у команды появилась общая версия реальности.
Плохая договорённость:
Звучит красиво, но непонятно, что делать завтра.
Рабочая договорённость:
Тут уже есть конкретное поведение.
Как такие правила создавать?
Лучше не писать их тимлиду единолично и не спускать команде сверху.
Я бы шёл так:
1. Собрать повторяющиеся проблемы команды.
2. Выбрать 3–5 самых болезненных.
3. Сформулировать конкретные правила.
4. Договориться, как замечать нарушения.
5. Через месяц пересмотреть договорённости.
Последний пункт важен.
Working Agreements — это не каменная плита с заповедями.
Это рабочий инструмент.
Команда изменилась, нагрузка изменилась, процесс изменился — договорённости тоже могут измениться.
Что делает такие правила бесполезными:
- слишком много пунктов;
- абстрактные формулировки;
- правила без конкретного поведения;
- отсутствие пересмотра;
- разные правила для руководителя и команды;
- документ, который никто не открывал после создания.
Working Agreements нужны не для того, чтобы контролировать каждый шаг команды.
Они нужны, чтобы люди не тратили силы на постоянное угадывание чужих ожиданий.
Потому что когда правила не проговорены, они всё равно существуют.
Просто у каждого свои.
А это уже не командная работа, а интеграция через сюрпризы.
Какая одна договорённость сильнее всего упростила бы работу вашей команды прямо сейчас?
Рубрика: «Из жизни тимлида»
В понедельник писал про готовность задач.
Но даже хорошо подготовленная задача может застрять, если у команды нет общих правил работы.
Большинство команд живёт по правилам.
Просто эти правила часто нигде не записаны.
Кто-то считает нормальным поставить встречу на свободное место в календаре.
Кто-то ожидает ревью в тот же день.
Кто-то пишет обо всех блокировках на daily.
Кто-то молчит неделю, потому что «пока пытаюсь разобраться сам».
Кто-то уверен, что открытый PR кто-нибудь обязательно заметит.
В итоге получается распределённая система без протокола.
Что даже для людей несколько рискованно.
А потом команда удивляется конфликтам, задержкам и разным ожиданиям.
Team Working Agreements — это явные договорённости о том, как команда работает вместе.
Не корпоративный кодекс.
Не документ про ценности.
Не «мы уважаем друг друга и стремимся к excellence».
Это практические правила, которые уменьшают неопределённость в ежедневной работе.
Например, команда может договориться:
- где задавать несрочные вопросы;
- когда писать лично;
- что считается срочным;
- за какое время обычно отвечаем;
- какие решения обязательно фиксируем письменно;
- когда встреча действительно нужна;
- можно ли отказаться от встречи без повестки;
- кто назначает ревьюера;
- за какое время PR должен получить первый взгляд;
- когда спор в комментариях пора переносить в разговор;
- сколько задач можно вести одновременно;
- когда задача считается заблокированной;
- когда нужно эскалировать проблему.
Это не звучит как что-то великое и стратегическое.
Но именно на таких мелочах команда часто теряет больше всего времени.
Пример небольшого набора договорённостей:
- блокировка дольше четырёх часов поднимается в командном чате;
- PR получает первый отзыв в течение рабочего дня;
- решение после встречи фиксируется в задаче;
- срочная задача должна сопровождаться решением, что снимается с текущей работы;
- встречи после 16:00 не ставятся без явной необходимости;
- у разработчика одновременно не больше двух активных задач.
Цифры здесь не универсальные.
Их нельзя торжественно скопировать в каждую команду и ожидать наступления инженерного рая.
Смысл не в конкретных числах.
Смысл в том, чтобы у команды появилась общая версия реальности.
Плохая договорённость:
Уважительно относимся ко времени коллег.
Звучит красиво, но непонятно, что делать завтра.
Рабочая договорённость:
Не ставим встречи без повестки и ожидаемого результата.
Тут уже есть конкретное поведение.
Как такие правила создавать?
Лучше не писать их тимлиду единолично и не спускать команде сверху.
Я бы шёл так:
1. Собрать повторяющиеся проблемы команды.
2. Выбрать 3–5 самых болезненных.
3. Сформулировать конкретные правила.
4. Договориться, как замечать нарушения.
5. Через месяц пересмотреть договорённости.
Последний пункт важен.
Working Agreements — это не каменная плита с заповедями.
Это рабочий инструмент.
Команда изменилась, нагрузка изменилась, процесс изменился — договорённости тоже могут измениться.
Что делает такие правила бесполезными:
- слишком много пунктов;
- абстрактные формулировки;
- правила без конкретного поведения;
- отсутствие пересмотра;
- разные правила для руководителя и команды;
- документ, который никто не открывал после создания.
Working Agreements нужны не для того, чтобы контролировать каждый шаг команды.
Они нужны, чтобы люди не тратили силы на постоянное угадывание чужих ожиданий.
Потому что когда правила не проговорены, они всё равно существуют.
Просто у каждого свои.
А это уже не командная работа, а интеграция через сюрпризы.
Какая одна договорённость сильнее всего упростила бы работу вашей команды прямо сейчас?
👍2
Условие простое: пройти наш опрос про AI в работе тимлида. На все 14 вопросов уйдет 3-6 минут.
Спрашиваем, какие задачи вы уже отдали AI и что из этого получилось. Из ответов соберем срез того, как это устроено у тимлидов в России.
Трех победителей выберем с помощью рандомайзера. Остальным пришлем промокод на скидку 10% на билет.
Полный отчет по исследованию пришлем на почту после конференции. На закрытии TeamLead Сибирь 10-11 сентября объявим результаты со сцены.
Please open Telegram to view this post
VIEW IN TELEGRAM
Review Time: сколько код ждёт проверки
PR открыт в понедельник утром.
Первый комментарий появляется во вторник вечером. Автор отвечает в среду. Ревьюер возвращается в четверг. В пятницу изменение наконец сливается.
Само ревью заняло минут сорок. Но календарно код ждал почти неделю.
Если смотреть только на среднее время ревью, эту проблему легко не заметить.
Одной цифры недостаточно
Review Time лучше разделять на несколько интервалов.
Time to First Review — время от открытия PR до первого содержательного комментария или одобрения.
Показывает, насколько быстро команда вообще начинает проверку. Комментарий бота, запуск CI или автоматическое назначение ревьюера считать не стоит.
Time to Approval — время от открытия PR до получения необходимых approvals.
Сюда входят ожидание, обсуждение и циклы исправлений. Если PR несколько раз возвращается автору, это будет видно именно здесь.
Time to Merge — время от открытия PR до merge.
Кроме ревью, сюда попадают CI, ручной merge, зависимость от других изменений и ожидание релизного окна.
Разница между этими интервалами помогает понять, где именно лежит код.
Почему среднее обманывает
Представим:
девять PR слились за два часа;
один PR висел десять дней.
Среднее значение сгладит ситуацию. Процесс будет выглядеть терпимо, хотя один тип изменений регулярно попадает в очередь на неделю.
Поэтому я бы смотрел не только среднее, но и:
медиану;
85-й или 90-й перцентиль;
долю PR старше выбранного порога;
распределение по размеру и типу изменений;
время до первого содержательного отзыва.
Например, медиана Time to First Review у команды составляет три часа. На первый взгляд всё хорошо.
Но 15% PR ждут больше двух дней.
Значит, проблема не во всём процессе. Нужно искать конкретные репозитории, типы изменений или узких экспертов, возле которых образуется очередь.
Какие сигналы стоит проверить
PR регулярно ждут первого комментария больше рабочего дня;
большая часть ревью проходит через одного человека;
маленькие изменения обрабатываются так же долго, как крупные;
между ответами автора и ревьюера возникают длинные паузы;
PR проходят несколько одинаковых циклов доработки;
approvals уже собраны, но merge происходит значительно позже.
Высокий Review Time может означать что угодно: большой WIP, отсутствие владельца ревью, нехватку экспертизы, слишком крупные PR или архитектурный спор, который начался уже после написания кода.
Иногда причина ещё проще: за создание нового кода разработчика хвалят, а время на помощь коллегам считается отвлечением от работы.
Как не превратить метрику в дубинку
Review Time не нужен для рейтинга «самых медленных ревьюеров».
Количество комментариев тоже ничего не говорит о качестве проверки. А требование мгновенно отвечать на каждый PR быстро приводит к поверхностным approve.
Полезнее смотреть на командный поток:
где изменения чаще всего останавливаются;
сколько времени занимает ожидание, а сколько обсуждение;
какие размеры и типы PR задерживаются;
изменилась ли картина после новых договорённостей.
Из практических шагов можно начать с простого:
договориться о времени первого отзыва;
выделить окна для ревью;
уменьшать размер изменений;
автоматически назначать ревьюеров;
выносить архитектурные вопросы до написания большого PR;
отмечать блокирующие и необязательные комментарии;
показывать старые PR на ежедневном обзоре;
ограничить количество одновременно открытых PR.
Definition of Ready помогает лучше готовить задачи. Working Agreements задают правила ревью. Review Time показывает, работают ли эти договорённости в реальности.
Эта метрика нужна не для того, чтобы люди быстрее ставили approve. Она показывает время, когда готовое изменение лежит без движения.
Что чаще задерживает ваши PR: ожидание первого ревью, долгие обсуждения, исправления или проверки после approval?
PR открыт в понедельник утром.
Первый комментарий появляется во вторник вечером. Автор отвечает в среду. Ревьюер возвращается в четверг. В пятницу изменение наконец сливается.
Само ревью заняло минут сорок. Но календарно код ждал почти неделю.
Если смотреть только на среднее время ревью, эту проблему легко не заметить.
Одной цифры недостаточно
Review Time лучше разделять на несколько интервалов.
Time to First Review — время от открытия PR до первого содержательного комментария или одобрения.
Показывает, насколько быстро команда вообще начинает проверку. Комментарий бота, запуск CI или автоматическое назначение ревьюера считать не стоит.
Time to Approval — время от открытия PR до получения необходимых approvals.
Сюда входят ожидание, обсуждение и циклы исправлений. Если PR несколько раз возвращается автору, это будет видно именно здесь.
Time to Merge — время от открытия PR до merge.
Кроме ревью, сюда попадают CI, ручной merge, зависимость от других изменений и ожидание релизного окна.
Разница между этими интервалами помогает понять, где именно лежит код.
Почему среднее обманывает
Представим:
девять PR слились за два часа;
один PR висел десять дней.
Среднее значение сгладит ситуацию. Процесс будет выглядеть терпимо, хотя один тип изменений регулярно попадает в очередь на неделю.
Поэтому я бы смотрел не только среднее, но и:
медиану;
85-й или 90-й перцентиль;
долю PR старше выбранного порога;
распределение по размеру и типу изменений;
время до первого содержательного отзыва.
Например, медиана Time to First Review у команды составляет три часа. На первый взгляд всё хорошо.
Но 15% PR ждут больше двух дней.
Значит, проблема не во всём процессе. Нужно искать конкретные репозитории, типы изменений или узких экспертов, возле которых образуется очередь.
Какие сигналы стоит проверить
PR регулярно ждут первого комментария больше рабочего дня;
большая часть ревью проходит через одного человека;
маленькие изменения обрабатываются так же долго, как крупные;
между ответами автора и ревьюера возникают длинные паузы;
PR проходят несколько одинаковых циклов доработки;
approvals уже собраны, но merge происходит значительно позже.
Высокий Review Time может означать что угодно: большой WIP, отсутствие владельца ревью, нехватку экспертизы, слишком крупные PR или архитектурный спор, который начался уже после написания кода.
Иногда причина ещё проще: за создание нового кода разработчика хвалят, а время на помощь коллегам считается отвлечением от работы.
Как не превратить метрику в дубинку
Review Time не нужен для рейтинга «самых медленных ревьюеров».
Количество комментариев тоже ничего не говорит о качестве проверки. А требование мгновенно отвечать на каждый PR быстро приводит к поверхностным approve.
Полезнее смотреть на командный поток:
где изменения чаще всего останавливаются;
сколько времени занимает ожидание, а сколько обсуждение;
какие размеры и типы PR задерживаются;
изменилась ли картина после новых договорённостей.
Из практических шагов можно начать с простого:
договориться о времени первого отзыва;
выделить окна для ревью;
уменьшать размер изменений;
автоматически назначать ревьюеров;
выносить архитектурные вопросы до написания большого PR;
отмечать блокирующие и необязательные комментарии;
показывать старые PR на ежедневном обзоре;
ограничить количество одновременно открытых PR.
Definition of Ready помогает лучше готовить задачи. Working Agreements задают правила ревью. Review Time показывает, работают ли эти договорённости в реальности.
Эта метрика нужна не для того, чтобы люди быстрее ставили approve. Она показывает время, когда готовое изменение лежит без движения.
Что чаще задерживает ваши PR: ожидание первого ревью, долгие обсуждения, исправления или проверки после approval?
👍2