Сколько людей - столько и мнений о процессах в команде (с).
Давайте поразмышляем - как выстроить процесс анализа так, чтобы он стал для команды не формальным набором этапов, а рабочим инструментом? Опираемся на наш опыт работы в командах разработки одного из операторов электронного документооборота. Все описанные процессы формировались и развивались на практике.
За отправную точку возьмем несколько потребностей:
управлять неопределённостью,
повышать качество требований,
снижать риски на этапе разработки.
Поделимся опытом работы в команде разработки продукта электронного документооборота.
Расскажем о своих решениях, ошибках, находках, и компромиссах и о рабочей модели, которой мы сейчас придерживаемся.
Отдельно благодарим команду деливери-менеджеров, которые направляли нас в этом движении и предлагали различные инициативы.
Команда сама должна прийти к решению о необходимости изменений (с).
Начали свою работу мы в тот момент, когда накопился ряд неотвеченных вопросов о нашей работе:
Кто, когда и зачем согласует требования?
В какой момент задача действительно готова к разработке?
Какие этапы действительно нужны, а какие лишь создают иллюзию контроля?
Для тех, кто сейчас задается одним из этих вопросов и всех интересующихся ниже мы расскажем, как смогли на них ответить.
Если вам покажется смутно знакомым стиль - вы не ошибаетесь - каркасом для изложения информации послужит шаблон ценностного предложения Остервальдера (Value Proposition Canvas).
Аналитический бэклог
Бэклог аналитических задач формируется до того, как задача назначается на аналитика, но так было не всегда.
С момента старта работы над продуктом мы сталкивались с разными вызовами и последовательно решали их.
Тут можно посмотреть список наших трудностей и решения, которые мы приняли для себя:
Задачи | Сформировать бэклог, который помогает управлять работой Проанализировать задачи в бэклоге разработки на итерацию вперед Построить понятный поток от идеи до реализации Четко обозначить границы эпиков Сократить уточнение постановок при реализации | Решение | Канбан-доска аналитиков для управления потоком Ориентир по Lead Time для этапов процесса User Story Mapping PI-планирования для коммита перед бизнесом |
Боли | Беспорядок в бэклоге Хаотичное получение задач Частая смена приоритетов и пересмотр планов Многократное переключение контекста Работа “в стол” Зависание задач по разным причинам Нет полного списка сценариев по эпику Сложно оценить объем работы по задаче Сложно прогнозировать сроки и риски Много лишних согласований | Лекарство | Планирование времени Оценка трудозатрат Отслеживание причин “зависания” задач Анализ узких мест WIP-лимиты на работу Декомпозиция задач на этапе исследования |
Выгоды | Прозрачность работы Управление процессом | Инструмент | Бэклог аналитических задач в трекере USM в Miro |
Для первичного наполнения бэклога мы используем инструмент USM (User Story Mapping): в рамках исследовательской работы по новому эпику декомпозируем его на пользовательские сценарии и user stories. Это помогает нам понять функциональность целиком, выявить ключевые сценарии и зависимости и подготовить набор задач для PI-планирования.
На PI-планировании, участники совместно формируют и согласовывают с бизнесом бэклог на следующий квартал.
В бэклог аналитиков попадают истории из декомпозированных эпиков, отдельные инициативы, исследования следующего квартала. Особое место здесь занимают задачи по документации (15-20% емкости). Если не планировать эту работу явно, поддержка базы знаний постоянно проигрывает запланированным фичам и срочным доработкам.
После PI-планирования задачи попадают в трекер, для них указываются приоритеты, сроки, ответственные аналитики, и они переходят в статус «Ожидает анализ», формируя рабочий аналитический бэклог.
Для этапов аналитического канбана мы зафиксировали SLA по Lead Time. Например, подготовка постановки в статусе «Анализ» занимает до 7 рабочих дней, а согласование в статусе «Согласование» — до 3 дней. Для остальных этапов также заданы свои ориентиры. Выход за эти значения становится сигналом для разбора причин: перегруз, слишком крупная декомпозиция, блокировка со стороны бизнеса или техническая неопределённость.
Дополнительно мы ввели WIP-лимиты и ограничили количество задач в активной работе: один аналитик одновременно работает не более чем над 2–3 задачами. Это помогает меньше переключаться между контекстами, быстрее доводить задачи до результата и лучше контролировать сроки прохождения по этапам.
Работа над постановкой
В таблице ниже видно, какие сложности мы испытывали в процессе подготовки постановок и как научились их преодолевать.
Задачи | Управлять потоком аналитических задач легко Измерять и контролировать Lead Time по этапам процесса Подготовить требования, понятные для команды разработки Уточнить границы задачи перед подготовкой постановки Структурировать требования и контекст задачи Сформировать единый подход к описанию требований Подготовить задачу к передаче в разработку | Решение | Выделение этапов аналитической проработки задачи Введение этапа «Преданализ» Использование единой структуры аналитических постановок Проверка требований по чек-листам Многоэтапное согласование требований |
Боли | Нечёткие границы задач Разрозненные требования и пожелания Разный уровень детализации постановок Ошибки и упущенные сценарии Несогласованность требований между бизнесом и разработкой Выявление проблем уже на этапе разработки Неучтённые технические ограничения | Лекарство | Предварительный анализ задачи Структурирование требований на этапе анализа Использование согласованной структуры требований Рецензирование постановки Совместное согласование с техлидом Проверка постановки тестировщиком Груминг с участием всей команды разработки |
Выгоды | Более структурированные и понятные требования Раннее выявление рисков и ограничений Снижение количества доработок требований Повышение качества требований Более точная оценка задач | Инструмент | Корпоративная база знаний Шаблоны аналитических постановок Чек-листы проверки постановки Процесс ревью аналитических задач DoR для upstream и downstream |
Работа над плановой задачей начинается со статуса «Преданализ». Перед переходом в этот статус задача должна соответствовать критериям DoR для upstream, которые помогают понять её готовность к аналитической проработке.
Upstream DoR:
эпик и задача оформлены по шаблону;
определены критерии приёмки для аналитика;
указана команда-исполнитель.
Основным критерием старта является наличие верхнеуровневого описания задачи, оформленного по утверждённому шаблону. На практике такое описание включает минимально необходимую информацию:
Бизнес-цель — описание задачи в формате user story;
Затрагиваемые системы — какие сервисы или модули участвуют в изменении;
Критерии готовности — что аналитик должен подготовить по итогам проработки;
Зависимости от других команд — внешние согласования и связанные задачи;
Дополнительный контекст — важные детали для качественного анализа.
Такая структура помогает аналитику увидеть границы задачи, её пользовательскую ценность и ключевые особенности реализации.
Мы отдельно зафиксировали обязательные критерии DoR для команды разработки.
Downstream DoR:
подготовлена согласованная постановка;
зафиксированы критерии приёмки для команды разработки;
пройден груминг;
выполнена оценка в Story Points.
Участие аналитика на этапе разработки
А с такими задачами и болями мы столкнулись на этапах downstream:
Задачи | Сопровождать реализацию задачи после передачи в разработку Поддерживать требования в актуальном состоянии Передать команде знания о реализованной функциональности | Решение | Вовлечение аналитика на всех этапах downstream Актуализация постановки по мере реализации Внедрение мероприятия аналитического демо |
Боли | Расхождение реализации с изначальными требованиями Неочевидные решения остаются «в голове» разработчиков Сложно понять, как именно реализован функционал Нет обмена опытом внутри команды Повтор одних и тех же ошибок в будущих задачах | Лекарство | Регулярная актуализация постановки Подготовка документации по итогам разработки Проведение аналитического демо |
Выгоды | Требования остаются актуальными в ходе реализации Прозрачность принятых решений Повышение качества реализации Распространение знаний внутри команды Использование накопленного опыта в новых задачах | Инструмент | Документация по реализованной функциональности Актуализированная аналитическая постановка Аналитическое демо |
После перехода задачи в downstream аналитик продолжает сопровождать её реализацию. Он отвечает на вопросы команды, помогает разбирать возникающие нюансы и при необходимости уточняет требования.
Все изменения, возникающие в downstream, фиксируются в истории изменений аналитической постановки: что было скорректировано, по какой причине и на каком этапе реализации принято решение. За счёт этого команда всегда может быстро восстановить контекст, отследить принятые решения и понять, какие изменения повлияли на итоговую реализацию.
Аналитическое демо
После завершения разработки аналитик подготавливает документацию по реализованной функциональности и проводит аналитическое демо.
На демо команда разбирает:
бизнес-ценность реализованной задачи;
ключевые пользовательские сценарии;
интерфейсы и интеграции;
архитектурные решения и возникшие сложности;
практические выводы, полученные в ходе реализации.
Формат аналитического демо был внедрён относительно недавно, но уже показал свою ценность. Даже за короткое время команда успевает передать большой объём практического опыта — как по реализованной функциональности, так и по неочевидным решениям и рекомендациям.
Такая практика помогает делиться знаниями внутри команды, повышать общее понимание системы и учитывать накопленный опыт при подготовке новых требований.
В этой части мы показали общий процесс работы аналитиков — от формирования бэклога до сопровождения задачи на этапе разработки и передачи знаний по реализованной функциональности. Главный результат — выстроенный процесс, который помогает управлять потоком задач, повышать качество требований и делать знания внутри команды прозрачными.
Подробно этапы upstream-процесса разберём во второй части.