От хаоса к системе: как мы выстроили процесс Discovery (часть 1)

Сколько людей — столько и мнений о процессах в команде (с). 

Давайте поразмышляем — как выстроить процесс анализа так, чтобы он стал для команды не формальным набором этапов, а рабочим инструментом? Опираемся на наш опыт работы в командах разработки одного из операторов электронного документооборота. Все описанные процессы формировались и развивались на практике.

За отправную точку возьмем несколько потребностей: 

• управлять неопределённостью,

• повышать качество требований,

• снижать риски на этапе разработки. 

Поделимся опытом работы в команде разработки продукта электронного документооборота. 

Расскажем о своих решениях, ошибках, находках, и компромиссах и о рабочей модели, которой мы сейчас придерживаемся.

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

Команда сама должна прийти к решению о необходимости изменений (с).

Начали свою работу мы в тот момент, когда накопился ряд неотвеченных вопросов о нашей работе:

• Кто, когда и зачем согласует требования? 

• В какой момент задача действительно готова к разработке? 

• Какие этапы действительно нужны, а какие лишь создают иллюзию контроля?

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

Если вам покажется смутно знакомым стиль — вы не ошибаетесь — каркасом для изложения информации послужит шаблон ценностного предложения Остервальдера (Value Proposition Canvas). 

Аналитический бэклог

Бэклог аналитических задач формируется до того, как задача назначается на аналитика, но так было не всегда. 

С момента старта работы над продуктом мы сталкивались с разными вызовами и последовательно решали их. 

Тут можно посмотреть список наших трудностей и решения, которые мы приняли для себя:

Для первичного наполнения бэклога мы используем инструмент USM (User Story Mapping): в рамках исследовательской работы по новому эпику декомпозируем его на пользовательские сценарии и user stories. Это помогает нам понять функциональность целиком, выявить ключевые сценарии и зависимости и подготовить набор задач для PI-планирования.

На PI-планировании, участники совместно формируют и согласовывают с бизнесом бэклог на следующий квартал.

В бэклог аналитиков попадают истории из декомпозированных эпиков, отдельные инициативы, исследования следующего квартала. Особое место здесь занимают задачи по документации (15-20% емкости).  Если не планировать эту работу явно, поддержка базы знаний постоянно проигрывает запланированным фичам и срочным доработкам.

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

Для этапов аналитического канбана мы зафиксировали SLA по Lead Time. Например, подготовка постановки в статусе «Анализ» занимает до 7 рабочих дней, а согласование в статусе «Согласование» — до 3 дней. Для остальных этапов также заданы свои ориентиры. Выход за эти значения становится сигналом для разбора причин: перегруз, слишком крупная декомпозиция, блокировка со стороны бизнеса или техническая неопределённость.

Дополнительно мы ввели WIP-лимиты и ограничили количество задач в активной работе: один аналитик одновременно работает не более чем над 2–3 задачами. Это помогает меньше переключаться между контекстами, быстрее доводить задачи до результата и лучше контролировать сроки прохождения по этапам.

Работа над постановкой

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

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

Upstream DoR:

• эпик и задача оформлены по шаблону;

• определены критерии приёмки для аналитика;

• указана команда-исполнитель.

Основным критерием старта является наличие верхнеуровневого описания задачи, оформленного по утверждённому шаблону. На практике такое описание включает минимально необходимую информацию:

• Бизнес-цель — описание задачи в формате user story;

• Затрагиваемые системы — какие сервисы или модули участвуют в изменении;

• Критерии готовности — что аналитик должен подготовить по итогам проработки;

• Зависимости от других команд — внешние согласования и связанные задачи;

• Дополнительный контекст — важные детали для качественного анализа.

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

Мы отдельно зафиксировали обязательные критерии DoR для команды разработки.

Downstream DoR:

• подготовлена согласованная постановка;

• зафиксированы критерии приёмки для команды разработки;

• пройден груминг;

• выполнена оценка в Story Points.

Участие аналитика на этапе разработки

А с такими задачами и болями мы столкнулись на этапах downstream: 

После перехода задачи в downstream аналитик продолжает сопровождать её реализацию. Он отвечает на вопросы команды, помогает разбирать возникающие нюансы и при необходимости уточняет требования.

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

Аналитическое демо

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

На демо команда разбирает:

• бизнес-ценность реализованной задачи;

• ключевые пользовательские сценарии;

• интерфейсы и интеграции;

• архитектурные решения и возникшие сложности;

• практические выводы, полученные в ходе реализации.

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

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

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

Подробно этапы upstream-процесса разберём во второй части.