Сроки сорваны, задачи возвращаются: как избежать провалов в IT-проектах

Фото: Christina / Unsplash

Авторская приемка может восприниматься как синоним UAT (User Acceptance Testing) — проверки продукта пользователями перед релизом. Но на деле это более ранняя и формализованная проверка по согласованным критериям, которую аналитик проводит вместе с заказчиком. Если UAT проверяет пользовательский опыт, то авторская приемка помогает сверить результат с требованиями из задач и документации.

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

Зачем нужна авторская приемка

Авторская приемка нужна, так как даже при наличии подробной документации остаются corner-кейсы — нестандартные ситуации, возникающие при экстремальных значениях или необычном поведении системы. Например, это может быть регистрация пользователя с максимально длинным логином, создание бронирования с датой выезда в прошлом или разрыв соединения на этапе редактирования.

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

Кто за нее отвечает

Ключевая роль — у системного аналитика: он согласовывает ожидания, переводит цели бизнеса в проверяемые требования, формулирует критерии приемки, фиксирует договоренности, следит, чтобы ни одно обсуждение не «утонуло» в устной речи без артефактов. Например, при разработке личного кабинета для сервиса бронирования отелей может звучать такое требование: «Хочу, чтобы при регистрации отеля автоматически проверялось поле «ИНН». Аналитик переводит это пожелание в конкретные критерии.

В форме регистрации отеля появляется отдельное поле для ввода ИНН.
При вводе система проверяет корректность номера, происходит валидация.
При уведомлении о новой регистрации в него автоматически добавляется ИНН, чтобы поддержка могла быстрее идентифицировать отель.

Главная ценность авторской приемки — экономия на доработках и своевременная поставка результата пользователям. Если функционал дошел до UAT, то с большой вероятностью он уже рабочий. Даже если заказчик не хочет тратить время на полноценную приемку, помогает демосессия: проще потратить час на демонстрацию, чем устраивать UAT вслепую.

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

Образование

Для оценки эффективности приемки команда обычно отслеживает три ключевых показателя:

• совпадение плановых и фактических сроков поставки;
• количество багов;
• число откатов релизов.

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

Итог — проблему устранили еще до релиза.

Чек-лист авторской приемки

1. Для функции или задачи есть бизнес-цель и измеримый ожидаемый результат. Например: «сократить время регистрации нового отеля на 30%».
2. Критерии приемки записаны в задаче: шаги, ожидаемые результаты, исключения. Например: «пользователь открыл форму регистрации → заполнил все поля, в том числе поле ИНН, валидными значениями → пользователь нажал кнопку «Отправить заявку» → поддержка получает заявку с полем ИНН».
3. Описаны corner-кейсы и альтернативные сценарии (экстремальные значения, тайм-ауты, прерывания, отмены). Например: ИНН самозанятого, ИНН не существует, пользователь уже зарегистрирован.
4. Зафиксированы ограничения: что точно не входит в поставку. Например: «проверка ИНН через Росреестр».
5. Проверены роли и права: кто может или не может выполнить действие; что видят разные роли. Например: менеджер отеля не получает письмо, а сотрудник поддержки — получает.
6. Решено, что делать при частичном несоответствии. Например: незначительное (текст, опечатка, отступы) — правим после релиза. Среднее (неблокирующая ошибка: неверная иконка статуса, неточное сообщение об ошибке) — правим, релиз не откатываем. Существенное (некорректная сумма, скидка, права доступа) — блокер, откатываем релиз.
7. Итог приемки задокументирован в задаче: что проверили, что получили, кто подтвердил. Например: «критерии 1–7 пройдены, 8 — отложен, согласовано с Ивановой И.И.».

Как ИИ помогает улучшить приемку

ИИ не замена аналитика, но мощный помощник. В процессе авторской приемки можно использовать общедоступные нейросети, например последнюю версию ChatGPT. Она подойдет для:

• Проверки полноты критериев. ИИ способен проанализировать сформулированные требования и подсказать, какие сценарии могли быть упущены: что еще может пойти не так, какие альтернативные пути стоит учесть.
• Выявления слабых формулировок. ИИ может подсветить неконкретные, непроверяемые или двусмысленные фразы — вроде «удобно», «быстро», «должно работать интуитивно». Такие критерии часто становятся причиной разногласий на этапе приемки.
• Сопоставления требований и реализации. В проектах с трассировкой требований ИИ может проверять покрытие: сопоставлять список запланированных требований с тем, что фактически реализовано, и выявлять пропущенные элементы.
• Поддержки аналитика при формулировке критериев. ИИ можно использовать для генерации шаблонов критериев, проверки их структуры и соответствия best practices. Это помогает ускорить работу и не забыть про важные детали.
• ИИ особенно полезен в проектах с трассировкой требований: он может выявить, какие элементы пропущены и на что не хватает тестов.

Однако полноту требований ИИ оценить не может: он не знает бизнес-контекст, историю обсуждений и особенности предметной области. Поэтому ИИ стоит использовать как помощника, но не как единственный инструмент.