Эту страницу открывают, когда задачи закрываются слишком рано, а потом возвращаются с доработками, пропущенными проверками, дефектами или неожиданностями уже на показе и релизе.
Definition of Done задаёт минимальную планку завершённости. Это защита от иллюзии, что «раз статус зелёный, значит всё готово».
Что это за компетенция
Это умение определить общий набор условий, при которых задача или тип работы считаются завершёнными для команды и проекта.
Если acceptance criteria отвечают на вопрос «что должно быть приемлемо по конкретному требованию», то DoD отвечает на вопрос «что вообще означает завершённость работы в нашем процессе».
Зачем нужна
Навык нужен, чтобы:
- снижать количество ложных
done-статусов; - делать готовность работы одинаково понимаемой;
- снижать возвраты после формального закрытия задач;
- улучшать качество демонстраций, приёмки и релизов;
- создавать общий стандарт завершённости в команде.
Где проявляется в реальной работе
Это особенно важно:
- в командах с итерационной разработкой;
- при подготовке демо и релизов;
- в проектах с частыми возвратами на доработку;
- в средах, где качество страдает от спешки и неполных проверок.
Что ломается без неё
- статусы лгут;
- задачи закрываются раньше фактической готовности;
- демонстрации вскрывают то, что «должно было быть уже сделано»;
- релизный контур перегружается недоделками;
- PM и команда по-разному понимают слово «готово».
Что можно делегировать, а что нельзя
Нельзя делегировать управленческую работу по согласованию минимального стандарта завершённости.
Можно делегировать:
- детализацию проверок для конкретных типов задач;
- оформление стандарта в команде;
- анализ повторяющихся возвратов и пробелов в DoD.
Как выглядит слабый уровень
- каждая задача закрывается по внутреннему ощущению исполнителя;
- стандарт готовности либо не существует, либо звучит слишком общо;
- возвраты на доработку считаются нормой;
- процесс живёт на импровизации.
Как выглядит сильный уровень
- у команды есть реалистичный и применимый стандарт завершённости;
- DoD одинаково понимается и используется в работе;
- возвраты после done сокращаются;
- приёмка и релиз становятся предсказуемее.
Как понять, что это ваш пробел
- задачи часто возвращаются после закрытия;
- на релизе или демо регулярно всплывают недоделки;
- команда не может чётко ответить, что означает готовность;
- PM часто сталкивается с расхождением между статусом и реальным состоянием работы.
Что делать пошагово
1. Разберите, какие типовые возвраты происходят после закрытия задач. 2. Выделите минимальные общие условия завершённости. 3. Разведите обязательные и контекстные пункты. 4. Зафиксируйте DoD в рабочем процессе команды. 5. Используйте его в приёмке, демо и ретроспективах. 6. Обновляйте DoD по итогам повторяющихся провалов.
Что обычно входит в DoD
- работа реализована;
- ключевые проверки пройдены;
- acceptance criteria выполнены;
- документация обновлена, если это нужно;
- результат готов к демонстрации, приёмке или поставке.
Практический ориентир
DoD лучше всего работает, когда собран из реальных возвратов проекта, а не из идеальной теории. Полезно взять последние несколько случаев, когда задача была уже закрыта, но потом вернулась, и выписать, какого общего условия не хватило.
Чаще всего это один из блоков:
- проверки не были завершены по факту;
- результат не был готов к демонстрации или внешней проверке;
- документация и связанные артефакты не были обновлены;
- команда и PM по-разному понимали, что значит done.
Разные DoD для разных типов работ
Один и тот же DoD редко одинаково полезен для всех задач. Имеет смысл отдельно различать:
- DoD для пользовательских изменений;
- DoD для технических задач и инфраструктуры;
- DoD для работ, которые выходят в релизный или приёмочный контур.
Это помогает не перегружать простые задачи и не занижать планку там, где работа влияет на готовность, релиз или внешнюю приёмку.
Типовые ошибки
- делать DoD слишком абстрактным;
- включать в него всё подряд, включая недостижимый идеал;
- не адаптировать DoD под тип работы;
- не использовать его как практический инструмент.
Как качать навык
- разбирайте последние возвраты и ищите, чего не хватило в определении done;
- связывайте DoD с проверкой готовности и release checklist;
- держите DoD живым стандартом, а не разовым документом.