Приёмка начинается до выполнения
Критерии приёмки — условия, по которым проверяют ожидаемый результат конкретной задачи.
Просьба «сделать удобную запись» оставляет слишком много пространства для разных трактовок. Исполнитель может сделать форму, заказчик ждать подтверждение на почту, а проверяющий — защиту от записи на заполненный сеанс. Все обсуждают одну задачу, но ожидают разные результаты.
Хорошие критерии переводят ожидания в наблюдаемое поведение. Ниже разбираем учебную форму записи на мастер-класс. Это пример требований к вымышленному сайту, а не перечень возможностей Sinqly. Метод можно применить и к документу, макету или организационной работе.
- Неясно
Форма работает корректно и удобно.
- Наблюдаемо
При занятом сеансе запись не создаётся; человек видит причину и может выбрать другое время.
Начните с результата и границ
Сначала назовите, что человек должен получить. В нашем примере посетитель выбирает сеанс, оставляет контакт и понимает, состоялась ли запись. Оплата, программа лояльности и перенос на другую дату в эту задачу не входят. Такие исключения помогают не превращать приёмку в бесконечное расширение работы.
Затем уточните исходные условия: какие поля обязательны, откуда берутся свободные места, что считается повторной отправкой. Без этого даже подробный список проверок будет построен на разных предположениях.
Не начинайте с десятков отрицательных сценариев, пока основной путь не согласован. Сначала разберите обычную успешную запись, затем ошибки ввода и ограничения. Это помогает удержать цель и не утонуть в деталях, которые не относятся к выбранному объёму.
Пять критериев для формы записи
| Условие и действие | Ожидаемый результат | Как проверяем |
|---|---|---|
| Есть место, контакт заполнен, отправляем форму | Создана одна запись, показаны дата и подтверждение | Проверяем итог на экране и сохранённую запись |
| Контакт не заполнен, отправляем форму | Запись не создаётся, ошибка указывает нужное поле | Повторяем отправку с пустым полем |
| Сеанс заполнен до подтверждения | Место не обещано, предложен выбор другого времени | Воспроизводим занятый сеанс |
| Повторяем подтверждение одной отправки | Не возникает вторая запись на то же действие | Проверяем число созданных записей |
| Сохранение завершилось ошибкой | Нет ложного сообщения об успехе, понятен следующий шаг | Воспроизводим предусмотренный отказ |
В реальном проекте последнюю строку нужно уточнить под известные ошибки. «При любой ошибке всё понятно» снова слишком широко. Назовите конкретный отказ, допустимое сообщение и возможность безопасно повторить действие.
Критерий про одну запись тоже требует границы: повторное нажатие, повтор запроса или новая осознанная запись могут быть разными сценариями. Если формулировку можно прочитать двумя способами, добавьте пример входных данных и ожидаемый итог.
Чем критерий отличается от технического решения
«Использовать библиотеку X» описывает способ реализации. «Не создавать вторую запись при повторном подтверждении» описывает поведение. Оба требования могут быть нужны, но их стоит разделять: первое проверяют как ограничение решения, второе — как результат для пользователя и системы.
Для макета критерием может быть наличие согласованных состояний формы и читаемость подписи на выбранной ширине. Для документа — ответ на конкретные вопросы и отсутствие неподтверждённых утверждений. Не обязательно превращать любую работу в программный тест.
- Результат задачи
Посетитель понимает, что место занято и запись не создана.
- Ограничение
Используем существующий источник доступности мест.
- Общее качество
Изменение соответствует принятой Definition of Done.
Общие требования качества не нужно полностью копировать в каждую задачу. Дайте ссылку на действующий стандарт, а здесь сохраните особенности результата. Это уменьшает расхождения между копиями и делает чтение короче.
Разбираем спор на приёмке
Исполнитель показывает форму: при пустом контакте она не отправляется, но человек не видит причины. В критерии было записано только «обязательное поле». Заказчик ожидал подсказку, разработчик считал достаточной блокировку. Это не повод выяснять, кто должен был догадаться; это двусмысленность исходной договорённости.
Уточните критерий: после попытки отправки ошибка видна рядом с полем, называет недостающий контакт и исчезает после исправления в предусмотренном сценарии. Затем оцените изменение объёма и согласуйте действие. Если требование появилось впервые, честно назовите его уточнением, а не доказанной ошибкой исполнителя.
Другая ситуация: подсказка была явно согласована, но не реализована. Тогда проверка показывает невыполнение критерия. Важно сохранять версию условий и пример результата, чтобы приёмка опиралась на факты, а не на память участников.
Как организовать саму проверку
- Согласовать критерии с теми, кто делает и принимает работу.
- Подготовить данные для обычного сценария и ключевых ошибок.
- Пройти каждый критерий и сохранить наблюдаемый результат.
- Отделить невыполнение обещанного от новой идеи улучшения.
- Зафиксировать итог: принято, требуется исправление или нужно дополнительное решение.
Скриншот полезен для видимого состояния, но не всегда подтверждает поведение. Одна картинка с подтверждением не доказывает, что повторная отправка безопасна. Выбирайте свидетельство под условие: последовательность действий, запись проверки или результат теста.
Не делайте список длиннее ради ощущения надёжности. Повторяющиеся строки можно объединить, но нельзя прятать под общим «всё работает» разные последствия. Хорошая проверка достаточно конкретна, чтобы другой участник мог её повторить и понять расхождение.
Где сохранить рабочий результат
В Sinqly можно создать задачу «Согласовать приёмку формы записи» и добавить в описание условия, примеры данных и результаты проверки; Sinqly здесь служит местом фиксации договорённостей; регистрация бесплатная.
Как улучшить одну текущую задачу
Найдите в описании слова «качественно», «удобно», «быстро» или «корректно». Для каждого спросите, что именно увидит проверяющий. Иногда достаточно одного примера, иногда нужен измеримый порог с условиями измерения. Не добавляйте число, если неясно, как и где его получать.
После уточнения попросите исполнителя пересказать один пограничный случай. Если ожидания совпали, задача стала лучше подготовлена. Если нет, короткий разговор сейчас обычно полезнее длинного спора в момент сдачи.
Общая Definition of Done дополняет критерии задачи единым стандартом качества.
Что ещё стоит уточнить
Сколько критериев нужно на задачу?
Столько, чтобы однозначно описать существенное поведение и границы. Фиксированного правильного количества нет.
Кто утверждает критерии?
Участники, которые вправе договориться о результате и принять его. Исполнителю важно участвовать в уточнении, чтобы обнаружить ограничения до старта.
Можно ли менять критерии во время работы?
Да, но изменение нужно явно согласовать вместе с последствиями для объёма и срока. Новое ожидание не должно незаметно становиться старым обещанием.
Помогло разобраться?
Оцените статью и расскажите, чего не хватило. Отзыв увидит редакция Sinqly — он не появится на сайте.
Источники и примечания
- Atlassian: acceptance criteria
- Предлагаемый порядок — редакционная практика, а не обещание одинакового результата для всех.
User story: как написать пользовательскую историю, с примерами
Формула user story, три исправленных примера и история записи на мастер-класс: отделяем потребность от функции, добавляем критерии приёмки и делим слишком большую задачу.
Definition of Done: что считать готовой работой, с примером
Как договориться о Definition of Done, отличить его от критериев приёмки и Definition of Ready и проверить готовность на примере формы записи.
Техническое задание: как описать результат и проверить готовность
Как описать требования к небольшой digital-задаче так, чтобы результат можно было проверить. С примером формы заявки, критериями приёмки и порядком изменений.