Ваня сделал задачу и отправил её на проверку. Он был уверен, что сделал всё так, как его просили 🫡 Но когда менеджер открыл результат, увидел совсем не то, чего ждал. Дальше начались споры о том, кто как понял задачу, кто что думал и почему в итоге получилось не то.
Зачастую в такой ситуации никто не виноват. Дело в том, что исполнитель и менеджер по-разному представляли результат. Обсудить это заранее помогают критерии приёмки. Рассказываем, что это такое, чем они отличаются от User Story и Definition of Done и как их писать. А ещё показываем примеры для разработки и обычных рабочих задач 😎
Коротко о главном
- Критерии приёмки — это условия, по которым команда и заказчик понимают, что задача готова
- Писать их лучше до начала работы, пока любое условие легко поменять
- Хороший критерий можно проверить вопросом с ответом «да» или «нет»
- Критерии приёмки у каждой задачи свои, а Definition of Done общий для всей команды
- Записать критерии можно списком или по схеме «Дано–Когда–Тогда»
Что такое критерии приёмки и зачем они нужны
— это условия, которым должен соответствовать результат, чтобы заказчик или менеджер принял работу
Допустим, команда делает форму заявки на сайте. Критерии для этой задачи могут быть такими:
- Форма отправляет заявку в CRM
- Если поле «Телефон» пустое, кнопка «Отправить» не работает
- После отправки человек видит сообщение «Спасибо, мы перезвоним в течение часа»
Каждый пункт можно проверить самостоятельно: открыть форму, оставить тестовую заявку и посмотреть, что пришло в CRM. Поэтому и поводов для споров потом заметно меньше.
Обычно о критериях приёмки говорят в разработке. Там их пишут к пользовательским историям (User Story), и они частично заменяют техническое задание. Но тот же подход подойдёт и для других задач: статьи, макета, отчёта для руководителя.
Что должно быть включено в критерии приёмки результатов проекта
Пока мы говорили про отдельные задачи, и там часто хватает трёх-пяти пунктов. Но когда команда сдаёт целый проект, например сайт или приложение, список длиннее. В него входит всё, что заказчик захочет проверить, прежде чем подписать акт.
Представим, что агентство делает сайт для онлайн-школы.
| Что описать | Зачем | Пример |
|---|---|---|
| Результат | Чтобы все одинаково понимали цель и объём работы | Сайт из 10 страниц: главная, каталог курсов, 8 страниц курсов |
| Функции | Что сайт умеет делать | Студент оплачивает курс картой и получает доступ на почту |
| Нефункциональные требования | Удобство, безопасность и надёжность, которых не видно в списке функций | Сайт корректно работает на телефоне, данные карт не хранят на сервере школы |
| Производительность | Сколько людей выдержит сайт и как быстро отвечает | Главная открывается за 2 секунды, даже когда на сайте 1000 человек |
| Качество | Уровень, ниже которого работу не принимают | На сайте нет битых ссылок, редактор вычитал все тексты |
| Законы и правила | Какие нормы и правила компании сайт соблюдает | Форма заявки спрашивает согласие на обработку персональных данных по 152-ФЗ |
| Ограничения | В какие рамки нужно уложить работу | Бюджет 400 000 ₽, запуск до 1 марта, сайт на Tilda |
| Как проверяем | По каким цифрам и тестам заказчик сравнит результат с ожиданиями | Тестовая оплата проходит с трёх банковских карт |
| Кто и как принимает | Кто проверяет работу и кто ставит финальное «ок» | Сначала проверяет менеджер агентства, потом директор школы подписывает акт |
Для большого проекта обычно нужны все девять блоков. А для лендинга хватает и четырёх: результата, функций, ограничений и того, кто принимает работу.
🔥 Как управлять несколькими проектами без постоянных уточнений
Гайд научит отслеживать статусы задач и сдавать проекты в срок →Чем критерии приёмки отличаются от User Story и Definition of Done
Пользовательская история (User Story) объясняет, что нужно пользователю и зачем. Её пишут по шаблону «Как [роль], я хочу [действие], чтобы [польза]». Например: «Как менеджер по продажам, я хочу выгружать список клиентов в Excel, чтобы готовить отчёт для руководителя».
По такой истории понятно, чего хочет менеджер. Но каждый в команде может представить выгрузку по-своему, и тут на помощь приходят критерии приёмки. Они описывают, когда историю можно считать готовой:
- В файле есть имя клиента, телефон и дата последней сделки
- Excel открывает файл без ошибок и сломанной кодировки
- Выгрузка 10 000 клиентов занимает не больше 10 секунд
- Менеджер видит в файле только своих клиентов
Definition of Done (DoD) — общий стандарт команды. Он один для всех задач в спринте или релизе и описывает то, что команда делает в каждой задаче. В разработке это может быть такой список: коллега проверил код, автотесты проходят, инструкцию для пользователей обновили.
Разницу хорошо видно и за пределами разработки. Возьмём редакцию блога, которая готовит статью про критерии приёмки.
Если свести всё вместе, выйдет такая таблица 👇
| Параметр | User Story | Критерии приёмки | Definition of Done |
|---|---|---|---|
| Отвечает на вопрос | Что нужно и зачем | Когда эта задача готова | Когда любая задача готова |
| К чему относится | К одной функции | К одной истории или задаче | Ко всем задачам команды |
| Кто пишет | Владелец продукта или менеджер | Владелец продукта вместе с командой | Команда |
| Как часто меняют | Новая для каждой функции | Новые для каждой истории | Редко, когда команда повышает планку качества |
Когда командам следует писать критерии приёмки
Лучше всего до старта работы. Когда критерии пишут задним числом, их легко незаметно подогнать под то, что уже сделали. И тогда они скорее фиксируют результат, чем помогают его получить.
В командах, которые работают спринтами, критерии обычно обсуждают три раза:
- 1. На груминге бэклога. Владелец продукта или менеджер приносит историю и черновик критериев. Команда задаёт вопросы и ищет граничные случаи
- 2. Перед планированием спринта. Команда перечитывает критерии и смотрит, понятны ли они и можно ли их проверить. Если какой-то пункт вызывает вопросы, историю иногда откладывают до следующего спринта, чтобы спокойно его переписать
- 3. Перед стартом работы. Разработчик и тестировщик ещё раз сверяют понимание и фиксируют финальную версию. По ней один делает функцию, а второй готовит тесты
🤫 Бывает, что уже в процессе работы кто-то хочет поменять критерии. Это нормально, просто такое изменение лучше обсудить с командой: возможно, команда сдвинет срок или перенесёт часть задач в следующий спринт
Какими должны быть хорошие критерии приёмки
Сами по себе критерии написать несложно. Сложнее сделать так, чтобы через неделю команда не гадала, что имел в виду автор. В этом помогают пять свойств 👇
Понятные всем. Менеджер, разработчик и тестировщик читают критерий и понимают его одинаково. Поэтому лучше обойтись без жаргона, который знают только разработчики.
Конкретные и измеримые. Вместо «быстро» стоит писать «за две секунды», а вместо «много товаров» — «до 500 товаров».
Проверяемые. На каждый критерий можно ответить «да» или «нет», не споря о вкусах. «Красивую кнопку» каждый оценит по-своему, а «кнопку в фирменном цвете #4A3AFF» проверить легко.
Про результат. Критерий описывает, что получит пользователь. Как это сделать, разработчик решит сам.
Короткие, но полные. Один критерий — одно условие. При этом в списке есть всё, без чего задачу не стоит принимать.
Вот как это выглядит на примерах из CRM:
| Слабый критерий | Как можно лучше |
|---|---|
| Поиск должен быть быстрым | Поиск по базе из 50 000 клиентов показывает результат за 2 секунды |
| Пользователь может фильтровать результаты | Результаты можно отфильтровать по дате, статусу и менеджеру |
| Пользователь нажимает «Отправить», чтобы сохранить форму | Система сохраняет форму, и пользователь видит подтверждение |
| Система обрабатывает ошибки | Если система не нашла адрес по индексу, пользователь вводит его вручную |
Давай выведем ещё три правила, которые помогают ничего не упустить:
- Опиши, что будет, если что-то пойдёт не так. Чаще всего баги сидят в пустых полях и дублях, у пользователей без прав доступа и в момент, когда пропал интернет
- Пиши словами команды. Если в компании говорят «заявка», а в критериях стоит «объект обращения клиента», тот, кто принимает работу, может пропустить ошибку
- Следи за длиной списка. Если критериев набралось больше восьми, скорее всего, задачу стоит разбить на несколько
Как написать критерии приёмки: порядок действий
Когда понятно, какими должны быть критерии, можно переходить к делу и писать их для каждой задачи. Ниже порядок, который можно повторять из спринта в спринт. Разберём его на одной задаче: интернет-магазин добавляет промокоды.
Шаг 1. Начни с пользовательской истории
Сначала пойми, кто пользователь и что он хочет получить. Если история размытая, критерии тоже выйдут размытыми.
👌 Как покупатель, я хочу ввести промокод при оформлении заказа, чтобы заплатить меньше
В Weeek можно создать задачу «Добавить промокоды в корзину» и в описании внести пользовательскую историю, а под ней — список критериев. Исполнитель откроет карточку и сразу увидит, что нужно сделать и по каким пунктам работу будут принимать.
Шаг 2. Опиши основной сценарий
Распиши, что делает пользователь и что в ответ делает система. Для начала хватит «счастливого пути», когда всё идёт без запиночки: покупатель вводит код, нажимает «Применить» и видит новую сумму со скидкой.
Шаг 3. Добавь границы и ошибки
Теперь подумай, что может пойти не так. Вдруг срок промокода истёк или код уже кто-то применил. А может, покупатель ввёл два кода подряд. Каждую такую ситуацию стоит записать отдельным критерием. Заодно добавь лимиты там, где они нужны: длину кода, срок действия или максимальную скидку.
Шаг 4. Сделай критерии проверяемыми
Там, где стоит оценка, попробуй поставить цифру: вместо «быстро пересчитывает» написать «пересчитывает сумму за секунду». Чтобы проверить себя, задай вопрос: сможет ли тестировщик написать тест по этому критерию, ничего не уточняя? Если нет, критерий стоит переписать.
В Weeek внутри карточки задачи можно назначить проверяющего в поле Утверждающие. У исполнителя не получится закрыть задачу, пока проверяющий не пройдёт по критериям и не подтвердит результат.
Шаг 5. Разбей сложные критерии
Хорошо, когда на одну строку приходит одно условие. Если критерий занимает больше двух предложений, скорее всего, в нём два условия, и его лучше разделить.
Если критериев стало больше восьми, задачу в Weeek можно разбить на подзадачи: например, отдельно «Ввод промокода» и «Расчёт скидки». У каждой подзадачи будут свои исполнитель, срок и критерии.
Шаг 6. Обсуди критерии с командой
Один человек легко упускает что-то из виду, поэтому перед спринтом прочитай критерии вместе с разработчиком и тестировщиком. Разработчик может спросить, складывать ли промокод со скидкой на товар, а тестировщик — что будет с пустой корзиной. Ответы на такие вопросы стоит дописать в критерии. Итоговая версия станет договором команды по задаче.
В Weeek можно отмечать сотрудников через @ в комментариях к задаче. Там можно обсудить насущные вопросы, и вся переписка останется на виду. Через месяц никому не придётся искать, почему решили именно так.
В итоге критерии для промокодов могут выглядеть так:
- Покупатель вводит действующий промокод и за секунду видит новую сумму и размер скидки
- Если срок промокода истёк, покупатель видит сообщение «Промокод больше не действует», сумма прежняя
- В одном заказе работает один промокод: второй код заменяет первый
- Если на товар уже есть скидка, система сравнивает её с промокодом и берёт бо́льшую
- Скидка по промокоду не больше 50% от суммы заказа
Форматы критериев приёмки: список правил и Given–When–Then
В примере выше мы записали критерии простым списком, но это не единственный вариант. У критериев приёмки два популярных формата, и у каждого свои сильные стороны.
Формат «Дано–Когда–Тогда» (Given–When–Then)
Здесь каждый критерий описывает один сценарий из трёх частей:
- Дано: исходная ситуация
- Когда: что делает пользователь
- Тогда: что он получает в итоге
Формат пришёл из BDD, разработки через поведение. Его часто выбирают тестировщики: по такому сценарию удобно писать ручные и автоматические тесты. Вот как можно переписать два критерия про промокоды.
Сценарий 1: действующий промокод
- Дано: в корзине товары на 3000 ₽, у покупателя есть действующий промокод на 10%
- Когда: покупатель вводит код и нажимает «Применить»
- Тогда: покупатель видит сумму 2700 ₽ и строку «Скидка по промокоду: 300 ₽»
Сценарий 2: просроченный промокод
- Дано: срок промокода истёк вчера
- Когда: покупатель вводит код и нажимает «Применить»
- Тогда: покупатель видит прежнюю сумму 3000 ₽ и сообщение «Промокод больше не действует»
Формат списка
В списке каждое условие занимает одну строку, как в чек-листе. Такой формат быстрее писать и проще читать, поэтому его часто выбирают для простых задач и для команд без разработчиков.
Например, так могут выглядеть критерии для задачи «Опубликовать статью о критериях приёмки»:
- Статья висит в блоге, у неё есть Title и Description
- Редактор вычитал текст и проверил факты
- Анонс вышел в Телеграм-канале в день публикации
- Ссылка на статью есть в ближайшей рассылке
🫠 Какой формат выбрать? Если у функции много веток и исключений, удобнее «Дано–Когда–Тогда»: каждая ветка станет отдельным сценарием. Для простых задач обычно хватает списка. Многие команды совмещают оба формата: список для общих условий и сценарии для сложных мест
Примеры критериев приёмки для User Story и рабочей задачи
Напоследок собрали три примера: два из разработки и один для обычной рабочей задачи. Их можно взять за основу и подстроить под свой проект.
Оформление заказа в интернет-магазине
✍️ Как покупатель, я хочу оформить заказ на сайте, чтобы не звонить в магазин
- На странице оформления покупатель видит список товаров, их количество и цены
- Покупатель может ввести промокод
- Итоговая сумма включает доставку, и покупатель видит стоимость доставки отдельной строкой
- Данные карты покупатель вводит на странице платёжного сервиса, магазин их не хранит
- В течение 5 минут после оплаты покупатель получает письмо с номером заказа и составом покупки
Приложение с прогнозом погоды
✍️ Как пользователь, я хочу видеть прогноз для своего города, чтобы понимать, что надеть
- На главном экране приложение показывает текущую температуру, осадки и прогноз на 5 дней
- Пользователь выбирает градусы Цельсия или Фаренгейта
- Приложение обновляет данные хотя бы раз в час
- Если синоптики объявили штормовое предупреждение, приложение присылает уведомление
- Пользователь добавляет до 10 городов и переключает их свайпом
Карусель для соцсетей
✍️ Критерии приёмки полезны и за пределами разработки. Вот как они могут выглядеть для дизайнера, который делает карусель про новую функцию:
- 9 карточек в формате 1080×1350 px
- На обложке заголовок не длиннее 7 слов
- Шрифты и цвета из фирменного стиля
- Редактор вычитал текст на карточках
- На последней карточке есть призыв к действию и ссылка
- Исходники и PNG лежат в файлах задачи
- Если дизайнер прикрепляет файлы прямо к задаче в Weeek, менеджер сверяет карусель с критериями в одном месте и не ищет макеты по чатам.
