Учимся работать с семью командами (МТС Касса 11-я часть)

7 мар. 2019 г. 5 min read

Я очень удивился, когда узнал, что компании «МТС» и «LiteBox» еще в 2017 договорились году увеличить количество команд до семи. Таким образом, сразу после изменения структуры к продуктовой группе стали присоединяться новые команды.

Команда RITG со стороны аутсорсинговой компании-партнера. Владелец Продукта был полон энтузиазма по поводу присоединения новых команд и заключил партнерство с одной из аутсорсинговых компаний в своем городе. Через несколько недель новая команда под названием RITG присоединилась к продуктовой группе. В течение нескольких Спринтов мы пытались интегрировать людей в наш процесс. Мы постоянно испытывали проблемы коммуникации во время Уточнений Бэклога Продукта (PBR). Кроме того, они не показывались на Обзоре Спринта. Тогда я порекомендовал переместить их в офис физически. Осуществить это было нелегко, однако, несмотря на все, Владелец Продукта добился успеха. С того момента у нас было пять команд в одном офисе.

Команда ROST в офисе. Тем временем, внутренний отдел по управлению персоналом помог нам создать еще одну фиче-команду под названием ROST. Два члена бывшей пилотной фиче-команды подключились к ней на несколько Спринтов, чтобы присоединение прошло максимально гладко.

Удаленная команда из Украины. У «МТС Кассы» было несколько разработчиков на Украине с самого начала разработки Продукта. Эти люди даже принимали участие в первоначальном тренинге по Скраму. Мы договорились не включать их в продуктовую группу до тех пор, пока они не сформируют фиче-команду, работающую в одном помещении в Киеве (они работали удаленно и жили в разных городах Украины). Наконец это произошло.

К сожалению, новые посредники. Ранее я говорил, что одним из основных препятствий при внедрении было привлечение людей, которые не поддерживали изменения и вели себя как посредники между командами и клиентами. Количество команд росло, и группа бизнес-анализа также росла. Был нанят новый бизнес-аналитик, который фокусировался на внешних активностях. Вот как выглядела структура в тот момент:

Смещение фокуса с локальных улучшений на системные

В первые месяцы мы были сосредоточены на том, чтобы установить эффективные процессы в новой структуре LeSS и грамотно проводить мероприятия LeSS (поверьте мне, Мульти-командное PBR и Обзор Спринта не так просты для эффективного внедрения). На самом деле мы добились многого. Вначале большинство разработчиков были новичками в LeSS, и большинство проблем, с которыми мы сталкивались, сводились к следующему:

  • Обучение и рост многофункциональных людей.
  • Помощь друг другу во время Спринта.
  • Swarming
  • Создание инструментария для Бэклога Спринта.
  • Ограничение WIP (количества незавершенной работы) в Бэклоге Спринта.

Координация между фиче-командами и сообществами хорошо работала с самого начала. Как бы то ни было, через некоторое время стало ясно, что большая часть проблем, на которых нам надо сфокусироваться, относилась к системному уровню. Грубо говоря, все системные проблемы были разделены на 3 больших категории: технический долг, CI/CD и процесс движения от идей или заявок стейкхолдеров до поставки.

Что стало с сообществами в дальнейшем

Сообщества еще живы. Через семь месяцев 5 сообществ все еще были живы (CI/CD, QA, сообщество Скрам-мастеров, UI/UX, фронтенд), 2 сообщества — CI/CD и бэкенд — слились в одно (CI/CD), а остальные умерли. И это нормально! Процессы рождения и смерти естественны для сообществ.

Координация. Сообщества регулярно встречались раз в одну–две недели. У каждого сообщества был свой канал в Slack для общения. В течение первых месяцев Скрам-мастера принимали активное участие в фасилитации встреч, но через некоторое время люди повысили свой профессионализм и научились фасилитировать их самостоятельно. Так или иначе, Скрам-мастер оставался доступен по требованию, и иногда сообщества просили его о помощи. Например, я помню важный момент для фронтенд-сообщества, когда им нужно было выбрать один из нескольких фреймворков. Это действительно трудное и сложное решение. Им нужна была помощь, и они пригласили Скрам-мастера, который помог им в конце концов прийти к консенсусу. У каждого сообщества было отдельное место на стене большой комнаты, где они размещали свои объявления.

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

Изменение потока требований с течением времени

Множество проблем с требованиями. Если посмотреть на системные проблемы, рассмотренные на общей Ретроспективе, становится ясно, что многие из них относились к потоку требований. И в самом деле, в течение первых месяцев я был сконцентрирован на обучении команд и фасилитации мероприятий. У меня не было времени на обучение Владельца Продукта и/или группы бизнес-аналитиков, которые не хотели участвовать во внедрении LeSS, и я не уделял им достаточного количества времени. Я получил фидбек от основных внутренних стейкхолдеров (в основном, от отделов маркетинга и продаж) о том, что они не были удовлетворены работой продуктовой группы. Для них это был «черный ящик», и они сказали мне, что Владелец Продукта не уделял достаточно внимания их заявкам. Еще один момент, который я понял: поток элементов из Бэклога Продукта в Спринт не был достаточно хорош. PBR проходили не так гладко, как я хотел, и иногда команды выбирали для Спринта слишком большие и неопределенные («неготовые») фичи. Я предложил сфокусироваться на потоке требований.

Продуктовый воркшоп. Я провел на месте интенсивный двухдневный воркшоп для Владельца Продукта, группы бизнес-аналитиков, Скрам-мастеров и представителей команд, во время которого мы сделали следующее:

  • Выстроили видение Продукта, используя формат Elevator Pitch.
  • Тщательно проанализировали и обсудили каждый из восьми профилей клиентов, используя шаблон jobs/pains/gains.
  • Создали бизнес-цель на следующий квартал и сформулировали ее по SMART (снизить процент оттока клиентов).
  • Создали карту влияния (Impact Map) и установили приоритеты влияний.
  • Отфильтровали фичи из Бэклога Продукта с учетом карты влияния.
  • Использовали карту историй (Story Mapping) для некоторых крупных фич в Бэклоге Продукта.

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

Улучшенный процесс Уточнения

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

Общее Уточнение Бэклога Продукта:

  • Краткое обсуждение и быстрая оценка
  • Если оценивается более 13 Story Points, фича анализируется с помощью карты историй или шаблонов разбиения.

Однокомандное PBR: только для украинской команды.

Мульти-командное PBR:

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

Новый процесс работы с требованиями был гораздо лучше предыдущего. Прежде всего, процесс стал более упорядоченным. Мы определили входные и выходные параметры каждого шага. Другим важным моментом стало то, что любую фичу теперь можно было явно связать с целями клиентов и бизнес-целями, а это важно для внутренней мотивации. Каждая команда снова отправлялась на воркшоп по декомпозиции и училась использовать карту историй. В конце концов, спустя несколько Спринтов, новый процесс оказался очень увлекательным для команд (по крайней мере, они нам так говорили), и поток требований улучшился. У нас стало возникать меньше сюрпризов в ходе Спринтов, у Владельца Продукта появилось больше свободного времени (он посещал только общее PBR), а среднее время цикла (Cycle Time) для фичи сократилось.

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.