Найти в Дзене

Готово ≠ работает: зачем каждой команде нужен Definition of Done

Почти в каждом проекте бывает момент, когда кто-то радостно говорит: «Готово!», а через пару часов выясняется, что ничего не работает. Макет вроде есть, но кнопки не кликаются, API возвращает ошибку, а у QA подгорает. И начинается классическая сцена: Я же сделал, но оно не работает. В этот момент команда сталкивается с вечной проблемой: каждый понимает слово «готово» по-своему. В agile-командах эту путаницу давно научились устранять с помощью простого, но мощного инструмента Definition of Done, или просто DoD. Его придумали ещё на заре Scrum, когда стало ясно, что без общего понимания качества команда буксует даже при чётком плане. В официальном Scrum Guide говорится, что DoD   это единый набор критериев, который определяет, что задача действительно завершена. Но по сути, это не про теорию   это про доверие и прозрачность. Если упрощённо, то Definition of Done это договор внутри команды о том, что значит слово «готово» в конкретном проекте. Для дизайнера это когда макет адаптирован п

Почти в каждом проекте бывает момент, когда кто-то радостно говорит: «Готово!», а через пару часов выясняется, что ничего не работает. Макет вроде есть, но кнопки не кликаются, API возвращает ошибку, а у QA подгорает. И начинается классическая сцена: Я же сделал, но оно не работает. В этот момент команда сталкивается с вечной проблемой: каждый понимает слово «готово» по-своему.

В agile-командах эту путаницу давно научились устранять с помощью простого, но мощного инструмента Definition of Done, или просто DoD. Его придумали ещё на заре Scrum, когда стало ясно, что без общего понимания качества команда буксует даже при чётком плане. В официальном Scrum Guide говорится, что DoD   это единый набор критериев, который определяет, что задача действительно завершена. Но по сути, это не про теорию   это про доверие и прозрачность.

-2

Если упрощённо, то Definition of Done это договор внутри команды о том, что значит слово «готово» в конкретном проекте. Для дизайнера это когда макет адаптирован под все разрешения, шрифты подключены, а кнопки имеют состояния. Для разработчика, когда код прошёл ревью, покрыт тестами и задеплоен на staging без ошибок. Для контент-редактора, когда текст не только написан, но и вычитан, загружен в CMS и прошёл проверку на соответствие тону бренда. И пока все эти пункты не выполнены, задача не может считаться завершённой, как бы ни хотелось побыстрее поставить зелёную галочку.

Звучит бюрократично? На самом деле, наоборот. Это способ избавиться от бесконечных уточнений, переделок и “ой, я думал, ты проверишь”. Ведь без DoD каждый живёт в своей реальности: продакт считает задачу готовой, когда она закрыта в трекере, дизайнер   когда макет красивый, а разработчик   когда код не падает у него на машине. В итоге никто не врёт, но результат всё равно «не работает».

-3

Исследования внутри команд Atlassian и Basecamp показывают, что большинство задержек и конфликтов происходит не из-за отсутствия компетенции, а из-за разного понимания критериев готовности. Люди не ленивые, они просто не синхронизированы. И вот тут DoD выступает как инструмент синхронизации ожиданий. Он превращает абстрактное «готово» в измеримый результат.

-4

Представьте, что вы строите дом. Строители могут сказать «всё готово», если стены стоят и крыша есть. Но если электрика не подключена и вода не подведена   домом это назвать нельзя. Так и в проекте: Definition of Done помогает понять, где заканчивается «построено» и начинается «можно жить».

Чтобы DoD работал, важно не перегибать. Некоторые команды пытаются прописать десятки пунктов и превращают простую задачу в чек-лист на три страницы. Но сила метода не в объёме, а в договорённости. Брайан Робертсон, автор концепции холакратии, писал, что прозрачность и согласованные правила не убивают креатив, а наоборот   дают команде уверенность, где можно импровизировать, а где нет. Definition of Done именно про это: он убирает серые зоны и создаёт пространство для осознанной работы.

-5

Теперь немного практики.
Чтобы DoD стал не просто словами на митинге, а частью ежедневного процесса, его нужно встроить туда, где живут задачи. В
Groop это можно сделать прямо в карточке: добавить чек-лист «Definition of Done» и отметить конкретные шаги, которые нужно пройти до статуса «готово к ревью» или «готово к прод».

Представь: ты ставишь задачу, прикрепляешь DoD, и теперь у каждого в команде единая шкала качества. Когда разработчик отмечает последнюю галочку, ты знаешь, что действительно всё сделано   тесты зелёные, документация обновлена, макет на проде. Зелёная галочка в Groop перестаёт быть формальностью и становится честным отражением завершённой работы.

-6

Функционал реализован и протестирован локально

  • Все ошибки (401, 403, 500) корректно обрабатываются
  • Код прошёл peer review (проверен коллегой)
  • ESLint / Prettier без ошибок
  • Unit-тесты и e2e-тесты зелёные
  • Изменения задеплоены на staging
  • QA подтвердил стабильность
  • Документация обновлена в Notion
  • Ссылка на MR прикреплена в карточку

В итоге Definition of Done - это, когда у всей команды одно понимание слова «готово», меньше недопониманий, меньше споров и больше фокуса на том, что действительно важно   продукте, который работает.

А если прикрутить DoD прямо к задачам в Groop, каждая зелёная галочка станет честной.
И тогда фраза «готово» наконец-то будет значить ровно то, что должна:
работает.