Критерий завершённости¶

Критерий завершённости — это совокупность формальных и неформальных требований, определяющих, что процесс, задача, проект или этап работы могут считаться выполненными и не требуют дальнейших действий. В управлении проектами, разработке программного обеспечения, производстве и других сферах критерий завершённости служит основой для принятия решения о переходе к следующему этапу или о сдаче результата заказчику. Отсутствие чётко определённых критериев приводит к неоднозначности, затягиванию сроков и снижению качества.

¶История возникновения понятия

Понятие критерия завершённости (англ. Definition of Done, DoD) получило широкое распространение в начале 2000-х годов в рамках гибких методологий разработки программного обеспечения (Agile), в частности в Scrum. До этого в классических (каскадных) моделях управления проектами завершение этапа определялось формальными документами — актами приёмки, протоколами испытаний, утверждёнными спецификациями. Однако практика показала, что такие документы часто не отражают реального состояния продукта: код мог быть написан, но не протестирован, документация — составлена, но не актуализирована.

В 2001 году, после публикации Манифеста Agile, сообщество разработчиков начало активнее внедрять итеративные подходы. В Scrum, описанном Кеном Швабером и Джеффом Сазерлендом, критерий завершённости стал обязательным элементом спринта. Первоначально он был неформальным списком «что значит «сделано» для команды», но со временем превратился в стандартизированный перечень, который фиксируется в документах проекта и регулярно пересматривается.

В России термин начал активно использоваться в IT-компаниях с середины 2010-х годов, параллельно с внедрением Scrum и Kanban. В производственных и строительных отраслях аналогичные понятия (например, «критерии приёмки», «контрольные точки») существовали и ранее, но в современном менеджменте они были переосмыслены в контексте бережливого производства (Lean) и управления качеством.

¶Классификация критериев завершённости

Критерии завершённости можно разделить на несколько категорий в зависимости от области применения и уровня детализации.

¶По уровню иерархии

Критерии для задачи (User Story) — определяют, что конкретная функциональность или единица работы готова. Например: «Написаны юнит-тесты, код проходит ревью, документация обновлена».
Критерии для спринта (Sprint Goal) — устанавливают, что весь спринт считается успешным, если достигнута цель спринта и все задачи, запланированные на него, соответствуют своему DoD.
Критерии для релиза (Release Criteria) — более жёсткие требования, включающие нагрузочное тестирование, проверку безопасности, утверждение заказчиком, подготовку маркетинговых материалов.

¶По области применения

Технические (для разработки ПО): код проходит статический анализ, покрытие тестами не менее 80%, отсутствуют критические ошибки, выполнена интеграция с основными системами.
Производственные (для промышленности): изделие соответствует чертежам, пройдены испытания на стенде, подписаны акты ОТК, упаковка и маркировка выполнены.
Управленческие (для проектов): все запланированные работы завершены, бюджет не превышен, риски закрыты, отчётность сдана.
Образовательные (для курсов или модулей): студент сдал все обязательные задания, получил проходной балл, заполнил анкету обратной связи.

¶По степени формализации

Формальные — зафиксированы в регламенте, контракте или техническом задании. Их нарушение влечёт юридические или финансовые последствия.
Неформальные — приняты внутри команды или организации, но не имеют обязательной силы. Например, «все комментарии в коде написаны на русском языке» или «презентация должна быть отправлена за день до встречи».

¶Структура и содержание критерия завершённости

В большинстве методологий критерий завершённости представляет собой чек-лист, который применяется к каждой единице работы. Типовой набор для разработки программного обеспечения (по материалам Scrum Guide и практик российских IT-компаний) включает:

Код написан и отформатирован в соответствии со стандартами команды.
Код прошёл ревью (как минимум одним коллегой).
Написаны автоматические тесты (юнит-тесты, интеграционные тесты).
Все тесты пройдены (в том числе регрессионное тестирование).
Документация (API, пользовательская, техническая) обновлена.
Функциональность развёрнута в тестовой среде и проверена тестировщиком.
Отсутствуют известные критические и высокие дефекты.
Код интегрирован в основную ветку репозитория.
Задача в трекере переведена в статус «Готово» с указанием ссылки на коммит или версию.

В промышленности аналогичный чек-лист может включать: проверку геометрических размеров, испытания на прочность, контроль качества сварных швов, подписание паспорта изделия, упаковку в соответствии с ГОСТ.

¶Применение в различных методологиях

¶Scrum

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

¶Kanban

В Kanban критерии завершённости менее формализованы, но также применяются. Обычно они привязаны к колонкам доски: например, задача может перейти из колонки «В разработке» в «Тестирование» только если код написан и прошёл ревью. В отличие от Scrum, в Kanban DoD может быть динамическим и меняться в зависимости от загрузки команды.

¶Каскадная модель (Waterfall)

В классических проектах критерии завершённости этапа — это утверждённые документы (технический проект, протокол испытаний, акт сдачи-приёмки). Они жёстко фиксированы в контракте и редко пересматриваются. Например, в строительстве этап «Нулевой цикл» считается завершённым после подписания акта скрытых работ и получения заключения геодезической службы.

¶Бережливое производство (Lean)

В концепции Lean критерий завершённости часто связан с понятием «точно вовремя» (Just-in-Time). Завершённой считается операция, которая не требует доработок и готова к передаче на следующий этап. В российских производственных компаниях, внедряющих Lean, используются «стандартные операционные карты», где прописаны точные критерии для каждой операции.

¶Значение и критика

Критерий завершённости решает несколько ключевых проблем управления:

Снижение неопределённости: все участники проекта (команда, заказчик, менеджмент) понимают, что именно означает «сделано».
Повышение качества: обязательные проверки (тесты, ревью, испытания) снижают вероятность дефектов.
Ускорение поставки: чёткие критерии предотвращают бесконечные доработки («ещё чуть-чуть улучшить»).
Прозрачность: статус задачи становится объективным, а не субъективным («почти готово»).

Вместе с тем, существуют и критические замечания. Во-первых, излишне детализированный DoD может замедлять работу: команда тратит время на формальные проверки, не добавляющие ценности. Во-вторых, в условиях быстро меняющихся требований жёсткий критерий может стать препятствием: задача, формально не соответствующая DoD, может быть уже достаточной для демонстрации заказчику. В-третьих, в распределённых командах или при аутсорсинге разные участники могут по-разному трактовать один и тот же пункт (например, «достаточное покрытие тестами» — 70% или 90%?).

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

¶Примеры из практики

Пример 1. IT-компания (Россия). Команда разработки мобильного приложения для банка использует следующий DoD для каждой пользовательской истории:

Код написан на Kotlin, соответствует код-стайлу.
Написаны юнит-тесты (покрытие не менее 80% новых строк).
Проведено ревью двумя разработчиками.
Приложение собрано и протестировано на трёх версиях Android (11, 12, 13).
Все критические и высокие баги исправлены.
Обновлена документация в Confluence.
Задача в Jira переведена в статус «Done» и привязана к коммиту.

Пример 2. Производственное предприятие (Россия). На заводе по выпуску металлоконструкций этап «Сварка» считается завершённым, если:

Швы соответствуют ГОСТ 5264-80 и прошли визуальный контроль.
Проведён ультразвуковой контроль не менее 10% швов.
Составлен акт скрытых работ.
Деталь промаркирована и перемещена на склад полуфабрикатов.

Пример 3. Образовательный проект. Онлайн-курс по Python считается завершённым для студента, если:

Сданы все 8 обязательных домашних заданий.
Итоговый проект прошёл автоматическую проверку (не менее 80% тестов пройдено).
Пройден финальный тест (не менее 70% правильных ответов).
Заполнена анкета обратной связи.

¶Связь с другими понятиями

Критерий завершённости тесно связан с критериями приёмки (Acceptance Criteria), но не является их полным аналогом. Критерии приёмки — это требования к функциональности, которые формулирует заказчик (например, «пользователь может войти в систему по email»). Критерий завершённости — это внутренние требования команды к качеству и процессу (например, «код прошёл ревью»). В идеале, DoD включает в себя и критерии приёмки, но не сводится к ним.

Также DoD пересекается с понятием Definition of Ready (DoR) — критериями готовности задачи к началу работы. Если DoD определяет, когда задача считается выполненной, то DoR — когда её можно брать в работу. В российских компаниях DoR часто включает: наличие чёткого описания, оценённые трудозатраты, согласование с заказчиком.

¶Источники

Швабер К., Сазерленд Дж. «Руководство по Scrum» (Scrum Guide), 2020.
Кон М. «Scrum: гибкое управление продуктом и проектом», 2011.
Голдратт Э. «Цель: процесс непрерывного совершенствования», 1984 (в контексте Lean).
ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом».
Материалы конференций Agile Russia (2015–2023).
Практические руководства компаний «Яндекс», «СберТех» (в открытом доступе).