Критерии приёмки задач в PM-системе: как оформить acceptance criteria, чтобы не спорить на демо

Пятница, конец спринта. PO показывает заказчику форму регистрации — поле email, кнопка «Создать аккаунт», редирект на главную. Заказчик смотрит секунд десять и говорит: «Я имел в виду, что после регистрации должно приходить письмо с подтверждением». PO: «Это не было в задаче». Заказчик: «Я думал, это очевидно». Следующие сорок минут команда выясняет, кто что имел в виду три недели назад. Задача уходит в следующий спринт.

Знакомая ситуация? Она повторяется в десятках команд каждую пятницу.

Причина не в том, что разработчик сделал что-то не так. Причина в том, что до начала работы никто не зафиксировал, что именно будет считаться принятым результатом. Как формулирует RB Tech: критерии приёмки отвечают не на вопрос «что разработчик делал внутри», а на вопрос «что должно работать, отображаться, сохраняться после выполнения задачи».

Эта статья — о том, как перевести acceptance criteria из англоязычного термина в рабочий русскоязычный шаблон для карточки задачи. Тему стандартизации описания задач мы уже разбирали в материале о шаблоне карточки задачи, здесь — следующий уровень.

Что такое критерии приёмки и почему русский перевод «acceptance criteria» — это не формальность

Acceptance criteria — это заранее согласованный список условий, при выполнении которых результат задачи считается принятым. Не «задача сделана», а «задача принята». Между этими формулировками — пропасть в виде возвратов, споров и потерянных спринтов.

В методологии PRINCE2 это описывается как приоритизированный список условий, которым продукт должен соответствовать, чтобы быть принят заказчиком — и формируется этот список до начала работы, а не после (PMpractice). В Scrum формулировка чуть другая: критерии приёмки описывают, при каких условиях user story считается выполненной с точки зрения конечного пользователя (ScrumTrek). Суть одна: AC фиксируют наблюдаемый результат, а не детали реализации.

Теперь про «перевод». Многие команды пишут AC на английском даже в русскоязычных проектах. На первый взгляд — профессионально. На деле — двойная двусмысленность. Языковая: «form should be validated» можно понять как «форма валидируется на фронте», «форма валидируется на бэке» или «форма валидируется где-нибудь». Смысловая: формулировка на неродном языке воспринимается абстрактнее, чем на том, на котором команда думает и разговаривает.

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

Когда разработчик читает «при вводе email без символа @ под полем появляется текст "Введите корректный email"» — он понимает задачу однозначно. Когда он читает «email field should be validated» — у него есть пространство для интерпретации. Это пространство и становится источником споров на демо.

Адаптация acceptance criteria для русскоязычной команды — это управленческая практика: убрать двусмысленность до того, как она стала конфликтом.

Acceptance criteria ≠ Definition of Done: где проходит граница

Путаница между этими двумя понятиями встречается часто, и она дорого обходится. Команда считает задачу «готовой» по DoD, PO ждёт проверки по AC, которых нет в карточке — и на демо выясняется, что у них разные представления о «готово».

Atlassian проводит границу чётко: Definition of Done — это общие требования к любому элементу бэклога, acceptance criteria — условия готовности конкретной user story.

Практически это выглядит так:

DoD — это минимальная планка для любой задачи. AC — это конкретный договор по конкретному результату. Задача может пройти DoD (код отревьюен, тесты написаны, задеплоено) и при этом провалить AC (письмо с подтверждением не отправляется, хотя это было в критериях).

Держать эти два инструмента раздельно — значит не смешивать общекомандные стандарты с конкретными договорённостями по задаче.

Шесть блоков критериев приёмки: шаблон для карточки задачи

Рабочий шаблон AC — это не свободный текст в описании задачи. Это структура из шести блоков, каждый из которых закрывает конкретный тип спора на приёмке. Шаблон основан на рекомендациях RB Tech.

Основной результат (observable outcome). Что видно пользователю, системе или интеграции после выполнения задачи. Не «реализовать экспорт», а «пользователь нажимает "Экспорт в Excel", браузер скачивает файл report.xlsx с данными из текущего фильтра». Этот блок снимает главный вопрос демо: «а что вообще должно было получиться?»

Основной сценарий (happy path). Пошаговый путь, при котором всё работает штатно. Для формы регистрации: пользователь вводит email и пароль → нажимает «Создать аккаунт» → видит экран «Проверьте почту» → получает письмо с ссылкой → переходит по ссылке → аккаунт активирован. Без этого блока команда и стейкхолдер могут говорить об одной задаче, имея в голове разные сценарии.

А вот блок, который пропускают чаще всего — и который вызывает больше всего споров:

Negative cases. Что происходит при ошибочных данных, пустых полях, обрыве сети, дублирующемся email. Разработчик спрашивает: «А что если пользователь ввёл уже зарегистрированный email?» Если ответа нет в карточке, ответ придётся искать на демо. Типичный антипример: в карточке написано «обработать ошибки ввода». Рабочий вариант: «при вводе email, который уже зарегистрирован, под полем появляется текст "Этот email уже используется", кнопка "Создать аккаунт" остаётся активной».

Способ проверки. Как именно проверить результат: ручной сценарий, автотест, запрос в БД, скриншот, лог в консоли. Без этого блока QA и PO могут использовать разные методы проверки и прийти к разным выводам.

Out of scope. Что явно не входит в задачу. «Восстановление пароля — в отдельной задаче», «мобильная верстка — вне скоупа этого спринта». Этот блок снимает претензии «а я думал, вы и это сделаете».

Owner / Reviewer. Кто принимает результат и по какому чек-листу. Если на демо приходит человек, который впервые видит задачу, — никакие AC не помогут. Owner должен быть назначен и согласован до старта работы.

Заполнить все шесть блоков для типовой задачи занимает 15–20 минут. Спор на демо — 40 минут плюс ещё один спринт.

Как формулировать критерии, чтобы они реально работали: пять правил без воды

Структура из шести блоков не спасёт, если формулировки расплывчаты. «Форма работает корректно» — это не критерий, это пожелание.

Писать через наблюдаемый результат, а не через реализацию. «Пользователь видит уведомление "Файл загружен"» — да. «Бэкенд отправляет событие upload_complete в очередь» — нет. Первое можно проверить на демо. Второе — только в коде.

Включать числа. Плохо: «страница загружается быстро». Хорошо: «страница загружается за ≤ 2 секунды при 100 одновременных пользователях». Стандарт IEEE 830 (SRS) прямо рекомендует задавать измеримые значения для каждого требования к производительности — иначе требование непроверяемо.

Каждый критерий — независимый pass/fail. Нельзя «частично принять». Если критерий можно принять наполовину — значит, он сформулирован как два критерия, которые нужно разделить.

Писать на языке команды. Если команда русскоязычная — критерии на русском. Англицизмы допустимы только для устоявшихся терминов: API, endpoint, UI. Всё остальное — на том языке, на котором люди думают.

Фиксировать до начала работы. Критерии, дописанные после разработки, — это не AC, а попытка задним числом обосновать то, что уже сделано. Они не снижают риск споров, они их маскируют.

Андрей Климов, руководитель продуктовых команд: «Мы ввели правило: задача без заполненных AC не переходит в "В работе". Первые два спринта было сопротивление — казалось, что это лишняя бюрократия. К четвёртому спринту команда сама стала возвращать задачи на уточнение критериев, потому что все уже видели: задачи с AC принимаются с первого раза, без них — нет».

Почему команды, у которых есть acceptance criteria, всё равно спорят на демо

Вот контр-интуитивный момент: наличие AC в карточке не гарантирует отсутствие споров. Шаблон есть, поля заполнены — а на демо всё равно конфликт. Причина не в шаблоне, а в системных ошибках.

AC написал один человек, а принимает другой. На Habr тестировщик из Sportmaster Lab описывал характерную ситуацию: ты пишешь критерии, просишь заказчика подтвердить, а в ответ получаешь «зачем мне это читать». Если стейкхолдер, который приходит на демо, не видел AC до старта и не согласовывал их — для него это просто чужой документ. Решение: owner/reviewer фиксируется в карточке и явно подтверждает критерии до того, как задача уходит в работу.

AC не обновляются при изменении скоупа. Задача мутировала в спринте: добавили edge case, поменяли бизнес-логику, сдвинули границу. Критерии остались от первоначальной версии. На демо — рассинхрон между тем, что написано, и тем, что реально ожидалось. AC нужно обновлять синхронно с изменениями скоупа, иначе они превращаются в устаревший артефакт.

AC слишком абстрактны, чтобы давать pass/fail. На Scrum.org прямо обсуждают: acceptance criteria «are not meant to provide detailed specifications», но это не значит, что они должны быть настолько общими, что по ним нельзя принять решение. «Система работает корректно» — это не критерий. Это отсутствие критерия в красивой обёртке.

Типичная динамика после внедрения AC: чего ожидать

Продуктовая команда, 12 человек, двухнедельные спринты. До внедрения AC: примерно треть задач возвращалась на доработку после демо. Не потому что разработчики делали плохо — потому что на приёмке выяснялось, что ожидания и результат расходятся.

Команда ввела обязательный шаблон AC из шести блоков в каждой карточке. Одно правило: задача без заполненных критериев не переходит в статус «В работе». Это минимальная версия Definition of Ready — задача считается готовой к разработке только тогда, когда понятно, по каким условиям её будут принимать. Связь между Definition of Ready и WIP-лимитами подробнее разобрана в материале о WIP-лимитах в Kanban.

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

Конкретные цифры зависят от зрелости процессов, размера команды и сложности продукта. Для обоснования инициативы внутри компании стоит провести собственный пилот на 2–3 спринта и зафиксировать метрики до и после: процент возвратов, длительность демо, количество уточняющих вопросов в спринте.

Как оформить критерии приёмки в PM-системе: от шаблона к чек-листу в карточке

AC в отдельном Confluence-документе или Google Doc не работают. Не потому что инструмент плохой — потому что никто не открывает ссылку. Разработчик смотрит в карточку задачи, а не в связанный документ. Если критерии не в карточке — их нет.

Рабочий паттерн: AC как чек-лист прямо внутри карточки задачи. Каждый пункт — отдельная строка с возможностью отметить «выполнено». Это решает сразу две задачи: разработчик видит критерии в контексте работы, QA использует тот же чек-лист для проверки.

Есть и дополнительный эффект. Если критерий сформулирован как конкретный pass/fail сценарий, он автоматически становится тест-кейсом. «При вводе пустого поля email кнопка "Войти" неактивна» — это и критерий приёмки, и готовый ручной тест. QA не тратит время на написание тест-кейсов с нуля.

В Shtab карточка задачи поддерживает чек-листы и шаблоны задач — шаблон AC из шести блоков можно зашить прямо в процесс создания задачи, так что ни одна задача физически не уйдёт в работу с пустыми критериями. Подробнее про механику шаблонов — в документации по созданию шаблонов задач.

AC как основа для AI-ассистента: почему без критериев приёмки автоматизация проверки невозможна

Если AC написаны как «система работает корректно» — ни человек, ни AI не смогут проверить готовность задачи. Если AC написаны как конкретные условия с числами и сценариями — AI-ассистент может пройти по чек-листу, сверить с логами тестов или комментариями разработчика и подсветить незакрытые пункты до того, как задача попадёт на демо.

Конкретный сценарий: AI-ассистент в PM-системе берёт чек-лист AC из карточки, сопоставляет каждый пункт с результатами автотестов в CI/CD-пайплайне, комментариями разработчика и статусами связанных задач. На выходе — не абстрактное «задача готова», а предметный отчёт: «пункты 1–4 закрыты, пункт 5 (negative case при пустом поле) не подтверждён — автотест test_empty_email_validation отсутствует в последнем прогоне». PO видит это до демо и может задать вопрос заранее, а не на встрече.

LLM-ассистенты уже работают со структурированными чек-листами — например, GitHub Copilot анализирует pull request на соответствие описанию задачи. Ограничение везде одно: качество входных данных. Расплывчатые AC дают расплывчатый результат. Конкретные AC с pass/fail дают конкретную проверку.

Мы разбирали механику подробно в материалах про LLM-ассистент для управления проектами и про три типа AI-ассистентов.

Как внедрить acceptance criteria в команде: практический план

Создайте шаблон AC из шести блоков и добавьте его в шаблон карточки задачи в PM-системе. Один раз, 30 минут. После этого каждая новая задача будет создаваться с уже готовой структурой — останется только заполнить.

Введите правило: задача без заполненных AC не переходит в «В работе». Договоритесь об этом на ближайшем планировании. Это минимальная версия Definition of Ready — не требует отдельного регламента, только одного явного соглашения внутри команды.

На первых двух демо сверяйте результат с AC вслух. Зачитывайте каждый пункт и отмечайте pass/fail. Первые разы это ощущается механически, но к третьему демо команда начинает делать это сама — потому что видит, как сокращается время обсуждений.

После двух спринтов проведите ретроспективу с цифрами. Сравните процент возвратов, длительность демо и количество уточняющих вопросов до и после внедрения AC. Эти данные — аргумент для масштабирования практики на другие команды и для разговора с руководством, если нужно обосновать время на заполнение критериев.

AC легче писать для задач, у которых один конкретный результат. Если задача слишком большая и критерии размываются — это сигнал к декомпозиции. Подробнее о том, как дробить задачи до управляемого размера, — в материале о декомпозиции задач.

FAQ

Что такое критерии приёмки (acceptance criteria)?

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

Как написать критерии приёмки?

Сформулировать основной результат через observable outcome, добавить happy path и negative cases, указать способ проверки, зафиксировать out of scope и назначить ответственного за приёмку. Каждый критерий должен давать однозначный результат: принято или не принято — без «частично» и «в целом да».

Для чего нужны критерии приёмки?

Чтобы убрать двусмысленность из задач до начала разработки, сократить споры на демо и дать команде объективную базу для приёмки результата. Дополнительный эффект: AC, написанные как конкретные pass/fail сценарии, становятся готовыми тест-кейсами и входными данными для автоматической проверки готовности задачи.