Что такое критерий завершения?

Что такое критерий завершения?

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

Ключевые цели и роль критериев завершения

• Создание единого понимания: Они устраняют ambiguity (неоднозначность) между командой разработки, менеджером проекта и заказчиком. Все участники знают, какой именно результат считается удовлетворительным.
• Объективная проверка качества: Вместо вопросов «кажется, что работает» мы получаем конкретные тесты: «система должна обрабатывать 1000 транзакций в секунду при нагрузке X».
• Формирование основы для тестирования: Часто критерии завершения напрямую переводятся в тестовые случаи (Test Cases) для QA-инженеров.
• Управление ожиданиями и снижение рисков: Четкие критерии предотвращают ситуации, когда заказчик говорит «я ожидал не это» после демонстрации готового продукта, что является одним из ключевых рисков проекта.
• Операционализация целей: Они переводят высокоуровневые бизнес-цели («улучшить пользовательский опыт») в конкретные, технически проверяемые действия («кнопка «Оплата» должна быть видимой и кликабельной в течение 3 секунд после загрузки страницы»).

Формы и примеры критериев заверчения

Критерии могут быть представлены в разных форматах, но всегда должны быть SMART: Specific (конкретные), Measurable (измеримые), Achievable (достижимые), Relevant (релевантные), Time-bound (ограниченные по времени/контексту).

Примеры для разных контекстов

1. Для пользовательской функции (User Story):

User Story: Как пользователь, я хочу фильтровать товары в каталоге по цене, чтобы быстрее найти доступные варианты.
Критерии завершения:
- В интерфейсе каталога присутствуют поля "Мин. цена" и "Макс. цена".
- При вводе значений и применении фильтра список товаров динамически обновляется, показывая только товары в заданном диапазоне.
- Фильтр работает корректно совместно с другими активными фильтрами (по категории, бренду).
- При некорректном вводе (например, буквы в поле цены) система показывает понятное сообщение об ошибке.
- Все изменения соответствуют утвержденному UI/UX макету (скриншот Figma #123).

2. Для технической задачи (Technical Task):

Задача: Миграция базы данных на новый кластер.
Критерии завершения:
- Все данные успешно перенесены, проверка через контрольный суммарный отчет (checksum report).
- Новый класер отвечает на запросы в течение ≤50 мс в 95% случаев (метрика из мониторинга Grafana).
- Автоматизированные скрипты бэкапа настроены и успешно выполняют тестовый бэкап.
- Документация по новой схеме подключения обновлена и размещена в Wiki.

3. Для этапа проекта (Phase Gate):

Этап: Завершение фазы проектирования (Design Phase).
Критерии завершения:
- Все архитектурные диаграммы (C4, UML) утверждены архитектурным комитетом.
- Технический план (Technical Roadmap) согласован со всеми lead-разработчиками.
- Риски, идентифицированные в ходе дизайна, занесены в реестр рисков с назначенными владельцами.
- Получен формальный sign-off (подпись) от ключевого стейкхолдера на документ "Архитектурное решение".

Как работают критерии завершения в процессе управления проектом

В моей практике, критерии завершения интегрируются в несколько ключевых процессов:

• Планирование: Они определяются совместно с заказчиком и командой на самых ранних стадиях (при создании бэклога продукта или технического задания).
• Разработка: Разработчики используют их как четкую техническую спецификацию для реализации.
• Контроль качества: QA-инженеры создают тесты, напрямую основанные на этих критериях. Задача считается готовой для тестирования только когда все критерии реализованы разработчиком.
• Приемка (Acceptance): Демонстрация заказчику (Showcase/UAT) проводится путем последовательной проверки каждого критерия. Это формализует процесс приемки.
• Закрытие задачи: В инструментах (Jira, Asana) задача перемещается в статус "Done" или "Closed" только после того, как все критерии проверены и выполнены, что часто требует подтверждения (approval) от менеджера или заказчика.

# Практический workflow в Jira (пример)
1. Задача создается с полями "User Story" и "Acceptance Criteria".
2. Во время работы разработчик ссылается на критерии.
3. Перед переносом в "Ready for Test" разработчик отмечает: "Все AC реализованы".
4. QA тестирует, отмечая каждый критерий: "AC1 - PASS", "AC2 - PASS".
5. После всех PASS задача перемещается в "Done".

Эволюция критериев: от фиксированных к динамическим

В классических методологиях (Waterfall) критерии часто фиксируются в начале проекта и меняются редко. В agile–подходах (Scrum, Kanban) они могут быть более гибкими и дополняться или уточняться в течение жизни спринта, но их основной набор также должен быть согласован до начала разработки конкретной задачи, чтобы избежать бесконечных изменений.

Итог: Критерии завершения — это не бюрократическая формальность, а фундаментальный инструмент управления проектом, который превращает субъективные ожидания в объективные, проверяемые договоренности. Их наличие и качественное написание напрямую влияет на снижение количества дефектов, скорость разработки (меньше возвратов и переделок) и, самое главное, на итоговое удовлетворение заказчика, получающего именно то, что было четко и заранее оговорено.