Ready и Done без ритуалов

Зачем разделять Ready и Done

Ready и Done часто превращаются в слова из процесса: есть колонка, есть чеклист, есть ритуал. Но смысл проще.

Ready отвечает на вопрос: можно ли начинать разработку без заведомо дорогой неопределенности.

Done отвечает на вопрос: можно ли считать результат поставленным, проверенным и пригодным для использования.

Если эти границы не проговорить, команда спорит в самые дорогие моменты: перед оценкой, перед релизом или после найденного дефекта.

Ready: вход в разработку

Задача готова к разработке не тогда, когда в ней много текста. Она готова, когда команда понимает достаточно, чтобы двигаться ответственно.

Минимум:

• зачем задача нужна;
• кто получает пользу;
• какой основной сценарий меняется;
• что входит в первую версию;
• какие данные нужны и кто их владелец;
• какие риски известны;
• какие критерии приемки проверят результат;
• какие вопросы остаются открытыми и кто за них отвечает.

Если часть ответов неизвестна, это не всегда блокер. Но нужно явно решить: уточняем до старта, делаем spike, ограничиваем scope или принимаем риск.

Done: выход из задачи

Done — это не “разработчик закончил код”. Для команды Done должно означать, что результат можно отдавать дальше без скрытого долга по смыслу.

Минимум:

• основной сценарий работает;
• исключения обработаны или явно вынесены за рамки;
• критерии приемки проверены;
• рискованные места обсуждены;
• нужные логи, статусы или сообщения понятны;
• документация или договоренность обновлена, если она нужна;
• команда понимает, что делать при ошибке.

Для простой задачи этот список короткий. Для интеграции, данных, безопасности или командного процесса он становится подробнее.

Как не сделать из этого бюрократию

Плохой путь — требовать одинаковый большой шаблон для любой задачи.

Рабочий путь — договориться о минимальной рамке и расширять ее по риску:

• простая UI-правка: цель, критерий, ожидаемое поведение;
• продуктовый сценарий: роли, данные, исключения, приемка;
• интеграция: контракт, ошибки, повторы, безопасность, диагностика;
• командный процесс: владелец, правило, исключения, проверка эффекта.

Чем выше цена ошибки, тем подробнее Ready и Done. Но сама логика остается одной: вход должен снижать неопределенность, выход должен подтверждать результат.

Формат короткой договоренности

Можно зафиксировать одну командную карточку:

## Ready

Задачу можно брать в разработку, когда понятно:
- зачем она нужна;
- какой сценарий меняется;
- что входит и не входит в первую версию;
- какие критерии приемки проверят результат;
- какие риски и открытые вопросы остаются.

## Done

Задача считается готовой, когда:
- реализован согласованный сценарий;
- проверены критерии приемки;
- исключения обработаны или явно вынесены за рамки;
- решение, риск или изменение процесса зафиксированы там, где это нужно.

Такой формат не заменяет аналитику, тестирование или код-ревью. Он просто дает команде общий язык.

Где это помогает тимлиду

Ready и Done полезны не только в задачах. Они помогают на интервью, risk-review и ретроспективах.

На интервью можно спросить кандидата: “Что должно быть понятно до старта задачи?” или “Когда ты считаешь свою часть работы готовой?”. Ответ показывает отношение человека к качеству, команде и риску.

На risk-review Ready помогает увидеть, что задача еще не готова к разработке. Done помогает не принять результат, который технически сделан, но операционно непонятен.

На ретроспективе Ready и Done дают спокойный язык для разбора: не “кто виноват”, а “какой вход был слабым и какой выход мы не договорили”.

Быстрая проверка

Перед стартом задачи спросите:

• что должно стать иначе после поставки;
• кто проверит результат;
• какие ошибки или исключения ожидаем;
• что мы сознательно не делаем;
• где риск, если мы ошиблись;
• что будет считаться готовым результатом.

Если команда не может ответить на эти вопросы, проблема не в ритуале. Проблема в том, что задача пока не имеет рабочей границы.