DoR — это чек-лист готовности задачи к разработке.

Он отвечает на вопрос:
➡️ Можно ли начинать делать эту задачу без риска провала, блокеров и переделок?

Если задача не соответствует DoR → её нельзя брать в спринт.

Типичные пункты DoR:

задача имеет понятную цель (зачем мы это делаем)
сформулирован конечный результат (что должно появиться в продукте)
есть понятные Acceptance Criteria
требования понятны и не противоречивы
есть макет / API контракт / UX решение (если требуется)
известны зависимости (другие задачи, сторонние команды)
нет блокеров
объём задач оценён (story points / T-shirt size)
технический лидер подтвердил реалистичность решения

Зачем нужен DoR?

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

Без DoR обычно случается хаос:

разработчик начал делать → “ой, тут не хватает логики от аналитика”
половина задачи была непонятна → UI должен быть не такой
Продукт не сформулировал критерии → разработчик сделал “как понял”

Это прямой путь к возвратам.

✅ Что такое DoD (Definition of Done)

DoD — это чек-лист “готовности к релизу”.

Он отвечает на вопрос:
➡️ Можно ли утверждать, что задача действительно завершена и не принесёт скрытых проблем?

Примерные пункты DoD:

реализовано всё по Acceptance Criteria
код прошёл code review
написаны тесты (unit/integration/e2e — зависит от вашей команды)
пройдены тесты QA
UI соответствует макетам
обновлена документация (если нужно)
задача выложена на тестовый стенд / staging
фича не ломает backward compatibility
нет известных критических багов

Зачем нужен DoD?

Чтобы задача, которая “готова”, не была сюрпризом для продакшена.

Если DoD нет → разработчики считают “готово” по-своему, QA — по-своему, продукт — по-своему. А затем на релизе всё рушится.

🔄 Что такое “возвраты” (Reworks)?

“Возвраты” — это переделки, когда задача приходит обратно в разработку или тестирование, потому что была сделана неправильно или не полностью.

Возвраты — огромная скрытая проблема в командах. Они:

убивают скорость
делают сроки непредсказуемыми
демотивируют команду
вызывают конфликты между продуктом, QA и разработкой

Типичные причины возвратов:

❌ Неясные требования → не сделали то, что хотел бизнес
❌ Нет чётких Acceptance Criteria
❌ Плохие или неполные макеты
❌ Несогласованная логика между фронтом и беком
❌ Отсутствие тест-кейсов
❌ QA нашёл критические баги
❌ Отсутствие DoR / DoD → команда работает “по ощущениям”

🎯 Как DoR, DoD уменьшают возвраты

✳️ DoR уменьшает возвраты до начала работы

Потому что задача:

полностью понятна
согласована
содержит все детали
не имеет блокеров

Разработчик не делает “по догадке”, значит не будет переделок.

✳️ DoD уменьшает возвраты после завершения работы

Потому что:

QA тестирует по понятному списку ожиданий
PM видит прозрачный статус
Команда знает, что значит “готово”

Задачи перестают возвращаться из-за “упустили это”, “не учли валидацию”, “нет теста на edge-case”.

📉 Пример из реальной жизни — как отсутствие DoR/DoD рождает возвраты

Ситуация:
Продукт дал задачу “добавить фильтр по дате”.

Без DoR:

нет макетов
непонятно, какой формат даты
не уточнено поведение на мобильных
не описана логика по пустым значениям

Разработчик сделал как понял.
QA тестит → 4 баговых сценария → задача идёт назад.
Продукт смотрит → “это вообще не то”.

Возврат ×3 → потеря недели.

С DoR + DoD:

макеты согласованы
логика edge-cases описана
AC чёткие
тесты прописаны
код прошёл ревью
QA сделал smoke + regression

→ задача ушла в релиз без возвратов.

🧩 Как PM использовать DoR, DoD и возвраты для улучшения процессов

1) Собери статистику возвратов

Категории:

требования
баги
тесты
дизайн
API
несовпадение ожиданий

Через 2 недели ты увидишь закономерность.

2) Обнови DoR и DoD под реальность команды

Они должны быть живыми, не теоретическими.

3) Не допускай задачи в разработку без DoR

Это твой “щит” от хаоса.

4) Настрой Definition of Done для релизов

Когда команда видит прозрачные критерии — исчезают “полуготовые” задачи.

5) Возьмите за правило: возврат = анализ на ретро

Каждый возврат — симптом проблем в процессе.