В предыдущей статье мы рассмотрели общий процесс работы аналитиков. 

Здесь подробнее остановимся на ключевых этапах подготовки постановки.

Разберём, как именно выстроена аналитическая работа внутри upstream: от преданализа до груминга, и какие практики помогают повышать качество требований и снижать риски на этапе разработки.

Преданализ

Этот этап помогает уточнить контекст задачи и подготовить её к аналитической проработке.

На этапе преданализа аналитик:

• Уточняет требования. Задача может прийти не только из декомпозиции эпика, но и после устных обсуждений, «быстрых» заявок или пожеланий интегратора — в таких случаях описание часто неполное или неструктурированное.

• Определяет границы. Полная детализация всех требований раздувает оценку до гигантских размеров, делая задачу нереализуемой в рамках одной итерации.

• Проводит исследование. До начала описания аналитик изучает конкурентов, анализирует их решения, а при необходимости проводит интервью с пользователями, чтобы убедиться в востребованности функциональности.

Иногда на этом этапе становится понятно, что задача утратила актуальность или требует значительно больше ресурсов. В таких случаях она переводится в статус «Отказ» либо возвращается в статус «Ожидает анализ».

Если задача имеет достаточные вводные и чётко определённые границы, аналитик может сразу перейти к этапу «Анализ».

Подготовка аналитической постановки

На этапе «Анализ» формируется аналитическая постановка, которая используется командой разработки.

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

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

При этом опытные аналитики могут выбирать удобный формат, а шаблон выступает ориентиром и опорой при подготовке постановки.

Шаблон постановки был совместно разработан командой аналитиков. В результате мы выделили следующие требования:

Постановка должна содержать описание, в котором передается бизнес контекст реализации функциональности. В данной части аналитик должен указать:

• как функциональность работает сейчас (опционально), приложить ссылки на связанные постановки (опционально);

• как будет работать: 

  • отрисовать use case диаграмму (опционально);

  • описать основной, альтернативные сценарии и исключения.
    Каждый шаг сценария может превратиться в требование.

  • отрисовать BPMN и/или UML последовательности и/или UML деятельности (блок-схема);

• возможные риски и ограничения (опционально). 

При описании требований на реализацию аналитик должен учесть, что постановка содержит:

для требований к фронтенду (Web Interface)

• Визуальный референс. Помимо ссылки на Figma, обязательно наличие скриншотов ключевых экранов.

• Валидация полей. Для каждого поля ввода прописаны ограничения:

  • максимальная длина строки;

  • обязательность заполнения (required / optional);

  • маска ввода и регулярные выражения (например, для телефона или email).

• Сортировка в реестрах:

  • тип сортировки (Серверная или Клиентская);

  • поля, по которым возможна сортировка;

  • детализирована логика по каждому типу данных: требования к строковым значениям, числам, датам, статусам и т.п.;

  • множественная сортировка (сортировка по нескольким полям);

  • визуальное поведение (UI/UX);

  • сортировка по умолчанию;

  • обработка краевых случаев (Null, Empty).

• Отображение данных по умолчанию. 

• Состояние «пустого окна». Что показывать, если поиск не дал результатов, а в базе — ни строчки.

для требований к бэкенду

• Изменения в архитектуре. Какие существующие сервисы будут затронуты, и требуется ли новый микросервис (опционально).

• Модель данных. Описание новых сущностей, поля в БД, их типы и индексы.

• CRUD-операции.

• Обратные операции. Не всегда, но часто нужно предусмотреть «откат» действия (например, возможность отменить отправку заявки).

• Порядок валидации.

• Сообщения для пользователя. Все тексты ошибок (с кодами, если есть) и тексты системных уведомлений (успех, предупреждение, информационные сообщения).

для требований при интеграции систем

• Диаграммы взаимодействия (UML Sequence или BPMN).

• Альтернативные и ошибочные сценарии: 

  • Что делает Система А, если Система Б не отвечает? 

  • Таймауты, ретраи, падение или кеширование.

• Тип интеграции:

  • асинхронное сообщение (брокеры: RabbitMQ, Kafka);

  • синхронный вызов (REST, SOAP, GraphQL, gRPC);

  • общая база данных или обмен через файловое хранилище.

• Входные и выходные параметры. 

• Формат сообщений (JSON, XML, Avro, Protobuf).

• Маппинг данных. 

• Надёжность доставки. Наличие подтверждения получения (опционально). Требования к поведению системы при наличии «повисших» сообщений.

• Идемпотентность. Поведение системы при обработке одного и того же сообщения в случае сбоев.

• Обратная совместимость. Требования к версионированию API.

Все требования опциональны, описываются в зависимости от реализации.

Помимо шаблонов, аналитики используют чек-листы при описании постановки:

1. Ознакомиться с кратким описанием задачи (требование для аналитика) и критериями приемки, которые были зафиксированы куратором эпика.

2. При необходимости связаться с куратором эпика, чтобы уточнить требования к аналитике.

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

4. Ознакомиться с внутренней документацией команды, к которой относится описываемая функциональность.

В разных командах подход к детализации требований может отличаться. В нашей команде действует принцип:

«Пишите, что нужно сделать, а не как именно это реализовать».

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

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

Рецензия постановки

После подготовки постановки задача переходит на этап «Рецензия».

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

Рецензирование позволяет:

• выявлять упущенные или альтернативные сценарии;

• контролировать границы задачи;

• находить двусмысленности и логические недочёты;

• повысить уверенность аналитика в качестве требований;

• сократить количество ошибок на этапах разработки и тестирования.

Для стандартизации ревью используется чек-лист, который помогает проверить бизнес-контекст, пользовательские сценарии, интеграции и алгоритмы. Замечания фиксируются в базе знаний. После их устранения задача переходит на этап «Согласование».

Согласование требований

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

Позже в процесс согласования был включён техлид. Теперь вопросы по требованиям обсуждаются на одной встрече с участием бизнеса и разработки. После этого задача переходит на этап «Готово к тестированию постановки».

Проверка постановки тестировщиком

На этом этапе постановку дополнительно проверяет тестировщик, подключаясь к задаче с позиции будущей проверки функциональности.

Такая проверка позволяет:

• выявить упущенные пользовательские и негативные сценарии;

• снять двусмысленности в требованиях;

• обнаружить влияние изменений на существующую функциональность;

• заранее выявить потенциальные дефекты.

В результате аналитик получает дополнительную обратную связь, требования становятся точнее, а команда получает более предсказуемый процесс реализации.

Груминг

После согласования с тестировщиком задача переходит на этап «Груминг».

На этом этапе постановку рассматривает вся команда разработки. Это позволяет выявить архитектурные ограничения и технические особенности системы, которые сложно полностью учесть на этапе анализа.

Совместное обсуждение помогает скорректировать требования и дать более точную оценку задачи.

После согласования постановки и оценки задачи в Story Points она выходит из upstream и переходит в статус «Готово к разработке». Переход возможен только при соответствии критериям DoR для downstream, подтверждающим готовность задачи к реализации:

• Для элемента четко прописаны Acceptance Criteria

• Элемент прошел ревью аналитиков / тестировщиков / техлидов / PO

С этого момента задача становится частью delivery-процесса, а аналитик продолжает сопровождать её реализацию.

Описанная модель не является окончательной — она продолжает развиваться вместе с проектом и командой. 

Наш ключевой вывод: инвестиции во время и качество аналитики на этапе upstream многократно окупаются на этапе downstream.