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

Зафиксировать факт релиза и состав изменений

Аналитик собирает, что на самом деле доехало до боевой версии:

• какие именно задачи реально попали в прод;

• какие возможности системы сейчас работают для пользователей, а какие:
  — уже есть в коде, но пока скрыты,
  — доступны только ограниченной группе (например, внутренним пользователям);

• какие ограничения остались:
  — что из запланированного не успели сделать,
  — что временно отключили,
  — какие есть известные «но» и компромиссы в работе функционала.

Обновить требования в Confluence / Wiki

Задача аналитика — сделать так, чтобы документация отражала то, как система работает сейчас.

Обычно он делает следующее:

• Обновляет страницы с требованиями:
  — убирает устаревшие формулировки «когда-нибудь сделаем»;
  — переносит пометки «планируется» в раздел «сделано»;
  — переписывает сценарии так, как они реально работают сейчас в продукте.

• При необходимости создаёт отдельный блок «История изменений» по фиче:
  — как было «до»,
  — что изменилось «после» этого релиза.

• Добавляет полезные ссылки:
  — на задачи в Jira (чтобы можно было посмотреть детали реализации),
  — на задачи по релизу / change request (как именно выкатили),
  — на дизайн-макеты (если по ним потом ориентируются команда или стейкхолдеры).

Обновить бизнес-сценарии и пользовательские потоки

После релиза аналитик заново собирает картинку «как теперь всё работает для пользователя и бизнеса».

Он:

• Обновляет описания бизнес-процессов:
  — какие шаги теперь делает пользователь (что, в каком порядке нажимает или заполняет);
  — какие системы при этом задействованы (например, сайт, платежи, CRM);
  — какие поля и состояния добавились или поменялись (новые статусы, новые обязательные поля и т.п.).

• Корректирует схемы процессов (если команда ими пользуется):
  — схемы в стиле BPMN / простые блок-схемы: кто что делает и в каком порядке;
  — сценарии вроде «как обрабатывается заявка», «как проходит платёж» и т.д.

• Фиксирует новые правила и проверки:
  — какие требования теперь есть к вводимым данным (что обязательно, какие форматы допустимы);
  — какие ошибки и сообщения может увидеть пользователь в разных ситуациях.

Описать интеграции, данные и технические нюансы (в части аналитики)

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

Он:

• Обновляет описания взаимодействия с другими системами (если это ведёт аналитик):
  — какие новые поля появились в запросах и ответах;
  — какие значения там допустимы (форматы, варианты, ограничения).

• Описывает изменения в данных:
  — какие появились новые сущности / таблицы / поля — но именно с точки зрения смысла для бизнеса (что это за данные, для чего они нужны);
  — по каким правилам они заполняются;
  — как они связаны с уже существующими данными (например: заказ привязан к клиенту, платёж — к заказу).

• Фиксирует особые случаи:
  — временные решения и костыли, о которых важно помнить в следующих релизах;
  — места, где фактическая реализация отличается от «идеальной» модели (например, договорились сделать проще, чтобы не затягивать релиз).

Зафиксировать ограничения, риски и «хвосты» на будущее

Аналитик отдельно описывает всё, что:

• не попало в этот релиз,
• или сделано «с оговорками».

Сюда обычно попадает:

• какие требования реализованы только частично;
• какие сценарии пока не поддерживаются (что пользователь пока сделать не может);
• какие риски или технические долги команда сознательно приняла:
  • «понимаем, что это решение неидеальное, но сейчас нам так ок»;
• какие доработки нужно оформить как отдельные задачи на будущие релизы:
  • что нужно доделать,
  • что переписать.

Обновить справочные материалы для команд и поддержки

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

Обычно он добавляет или обновляет:

• FAQ / типовые вопросы по новой фиче:

  • что умеет,
  • что не умеет,
  • какие есть особенности;

• инструкции для службы поддержки:

  • где смотреть нужные данные,
  • как воспроизвести сценарий пользователя шаг за шагом,
  • на что обращать внимание;

• при необходимости — краткие материалы для обучения внутренних пользователей:

  • операторов,
  • колл-центра,
  • внутренних бизнес-пользователей.

• Делится ссылками на обновлённые страницы в Confluence / Wiki:
  — в чате команды,
  — в релизных письмах/сообщениях,
  — в тех каналах, где команда привыкла следить за изменениями.

Заключение

Что дальше?

➡️ Подведём итоги 4ого блока