Кейс PashaPay часть 3: развитие способностей и итоги

Уточнение организационных способностей

Кейс PashaPay часть 1: организационный дизайн и обучение менеджмента
Кейс PashaPay часть 2: проектирование организации

Первое, чем занялась группа трансформации, — уточнила организационные способности, так как на стратегической сессии их определили достаточно верхнеуровнево. Мы разбили leading team на мини-группы, которые работали над определением способностей и метрик для оценки их развития.

Что сделали мини-группы на этом этапе:

выяснили, что считать фасилитацией диалога;
поняли, что фокус на общих целях и приоритизация развиваются с помощью единого Бэклога Продукта;
решили отслеживать скорость обучения по Cycle Time и Time to Learn, а предсказуемую поставку — на диаграмме рассеяния цикла.

Информирование сотрудников

В командах и отделах быстро распространялись слухи о трансформации и едином Бэклоге Продукта. Мы запустили процесс регулярного информирования сотрудников компании обо всех нововведениях:

Town Hall — это та встреча, где спикеры сообщают важные новости для всех сотрудников компании.
Sprint Review — на нём мы получали еще и обратную связь о проделанной работе.

Мы также создали канал в корпоративном мессенджере, в котором тоже делились информацией.

Работа группы трансформации

Мы наблюдали высокий уровень вовлечения. Участники встречались почти каждый день, приносили новые инсайды, делились прогрессом и много дискутировали. Не все разделяли идею самоуправляемых команд, поэтому обсуждались разные модели формирования команд: с техническими и командными лидерами или без них.

Параллельно в компании прошел полноценный технический аудит. Аудиторы предложили свой вариант оргструктуры: с техническими и командными лидерами, менеджерами проектов, архитектурным офисом и другими традиционными решениями характерными для “большого” энтерпрайза.

К этому моменту мы на несколько недель выпали из трансформации по независящим от нас причинам — работу подхватили СРО и остальные Скрам-мастера. Мы опасались, что трансформация зайдет в тупик, но когда вернулись, увидели, что «звездная модель» Гилбрейта осталась.

Основа организационного дизайна PashaPay

Компания не приняла идею тимлидов — и культурный ДНК компании остался практически тем же.

К сожалению, группа трансформации отказалась от идеи формирования продуктовой группы как формального выделенного бизнес-юнита для m10, и дальше мы имели дело уже с виртуальной продуктовой группой.

В работе группа трансформации придерживалась рекомендаций из книги «Гибкие организации»:

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

Передайте власть и ответственность Владельцу Продукта

Было понятно, что Владельца Продукта (CEO) надо разгружать. Вокруг него сформировали команду (паттерн Команда Владельца Продукта), которая взяла на себя большую часть тактических задач. За Владельцем Продукта остались лишь стратегия, видение и финальные решения по приоритезации.

Команда Владельца Продукта

В команду Владельца Продукта позвали лидеров областей ценности (Area Product Owners) и представителей смежных функций вроде маркетинга, продаж, финансов и рисков. Их экспертные знания требовались Владельцу Продукта, чтобы решать, как именно приоритизировать задачи.

Команды с общим продуктовым фокусом

Для развития фокуса на общих целях и навыка приоритизации мы рекомендовали всем командам работать с единым Бэклогом Продукта. Структура самих команд не претерпела изменений: по-прежнему кросс-функциональные и кросс-компонентные, но с узкой специализацией вокруг своего домена. Так у них появились общие цели и сквозные приоритеты.

Это контринтуитивно, но общие цели заработали — удалось достичь сонаправленности

CEO PashaPay

Единый Бэклог Продукта с тремя областями ценности

Области ценности

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

продуктовый лидер (Area PO), который отвечает за часть единого Бэклога Продукта;
технический лидер (техлид), который помогает транслировать ИТ-стратегию, выстраивать процессы, оценивать и обучать участников команд, повышать техническое качество работы в целом;
Скрам-мастер, который фокусируется на достижении результата;
кросс-функциональные команды.

Компания сделала ставку на тех, кто уже работает в компании, и предложила им взять на себя эту ответственность.

Структура продуктовой группы и области ценности

К моменту работы над текстом существовало три области:

retail: 4 команды, розничные клиенты;
bizness: 3 команды, b2b-клиенты;
платформа: 3 команды, пользователи внутри организации, например, продажники и поддержка.

Архитектурный офис

На картинке выше вы можете заметить “архитектурный офис”. Это новое подразделение для PashaPay в которое входит системные архитекторы и аналитики. Как и роль технического лидера в продуктовых областях, это результат компромисса, выработанного в ходе работы над предложением от технических аудиторов.

В ходе обсуждения в команде трансформации пришли к выводу что тимлиды в контексте PashaPay отрицательно повлияют на работу Скрам-команд, но для того системной работы над техническим долгом и архитектурой добавили роль технического лидера и архитектурный офис.

Организационный ритм

Процесс разработки был вдохновлен масштабируемым Скрамом (LeSS), но имел особенности.

Первая неделя Спринта:

Общее планирование. Финализация общих приоритетов в Бэклоге Продукта и постановка Целей Спринта для каждой команды или группы команд. Участвуют команда Владельца Продукта, лидеры областей ценности (Area Product Owners), техлиды, Скрам-мастер(а) и топ-менеджеры руководители функций. Спустя время мы поняли, что такое планирование стало MetaScrum — форумом, где организация выравнивалась в приоритетах Бэклога Продукта и общих целях.
Командные планирования. Создание локальных Бэклогов Спринтов.
Общая Ретроспектива за предыдущий Спринт. Фокус на кросс-командных проблемах и запуск экспериментов на уровне продуктовой группы. Участвуют представители команд и Скрам-мастера.

Первая неделя Спринта

Вторая неделя Спринта:

Product Team Meeting. Приоритезация Бэклога Продукта на следующий Спринт, обсуждение стратегических инициатив и препятствий. Участвуют команда Владельца Продукта и Скрам-мастер.
Product Backlog Refinement (PBR). Формат Single-Team или Multi-Team PBR. Участвуют команды и лидеры областей ценности.
Pre-planning Tech Debt. Включение технического долга в Бэклог Продукта. Участвуют техлиды и лидеры областей ценности.
Pre-planning Areas. Приоритизация элементов в области ценности. Участвуют лидеры областей ценности.
Pre-planning Voice of Customer. Включение задач поддержки в Бэклог Продукта. Участвуют лидеры областей ценности и представители функции.
Sprint Review. Подведение результатов Спринта и сбор обратной связи по инкременту. Участвуют все команды и стейкхолдеры.
Team Retrospectives. Формат командных ретро.

Вторая неделя Спринта

Фасилитация диалога

В модели Copy Paste Scrum у каждой команды свое планирование. Как только команды стали работать с единым Бэклогом Продукта, на общее планирование начали приходить все ключевые лица и функции m10: продуктовики, технари, продажники, рисковики, юристы.

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

Эволюция команды Владельца Продукта

Работа над процессами продолжилась. Одно из последних изменений — формализация процесса работы самой команды.

Для обсуждения оперативных, но нерегулярных вопросов появился асинхронный канал — чат в WhatsApp. Если вопрос оперативно не решается в чате, собирается отдельная встреча. На регулярных событиях обсуждают нерешенные вопросы из группы, синхронизацию с другими компаниями в холдинге Pasha, проработка больших инициатив и раз в месяц обзор стратегических планов.

Эти изменения значительно разгрузили продуктовое планирование в начале Спринта и избавили от Product Team Meeting в начале второй недели — вопросы координации успешно решаются через чат.

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

Итоги

Что получилось

CEO компании был основным заказчиком и двигателем трансформации. По его словам, удалось добиться главного — сфокусировать команды и функции на общих стратегических целях и обеспечить работу над самым важным. Фокус на общих целях появился благодаря процессным изменениям и фокусу всех команд на общем Бэклоге Продукта (команды с общим продуктовым фокусом). А паттерн MetaScrum погасил конфликт CPO с остальной организацией, потому что создал форум, где стейкхолдеры обсуждают приоритеты. Кроме того, теперь командам проще реагировать на возникающую работу — на общем планировании обсуждаются сквозные приоритеты на следующие две недели и, при необходимости, порядок элементов меняется.

Что не получилось

Попытка сформировать формальную продуктовую группу m10 не удалась. Мы имеем виртуальную продуктовую группу, структура власти (репортинг) осталось нетронутой. К чему это приводит? Представители функциональных подразделений более лояльны по отношению к своим функциональным руководителям и часто не спешат, реагируя на запросы продуктовых лидеров областей (Area Product Owner), что замедляет продуктовую разработку. Кроме того, у команд остается специализация на домене, что мешает развивать адаптивность на уровне всего продукта.

Несколько цитат из интервью с CEO:

Трансформацию нельзя отдавать на аутсорс

Нам нужны люди, которые готовы брать ownership

Это путь и эта история еще не закончились

Мы не знаем все ответы, но найдем их вместе

Мы создали такое peer-пространство в котором вещи случались

Новый менеджер еще должен заслужить нашу культуру

Нам не нужен Скрам или Аджайл, нам нужно добиваться целей

Нет твоих и моих ребят, мы все эмоновцы

Чему мы научились

Важные выводы, которые сделали для себя авторы кейса — Илья Павличенко и Сергей Лобин:

активное вовлечение топ-менеджмента — критический фактор для успеха трансформации;
сопротивление значительно снижается, если вносить изменения совместно;
вместо попытки выстроить LeSS, SAFe и что-то еще лучше создать свой фреймворк, исходя из принципов системного или бережливого мышления и организационных способностей, которые необходимо развить.