Учимся работать с семью командами

Я очень удивился, когда узнал, что компании «МТС» и «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) для фичи сократилось.