Как выстроить продуктовые процессы, если у вас 40 продуктов в 7 командах
Проектный и продуктовый подход в построениии процессов управления большим продуктовым портфелем
Этот рассказ будет интересен тем, у кого несколько продуктов / команд, и вы заинтересованы в том, чтобы ваши продукты развивались целенаправленно и соответствовали заложенной стратегии.
О спикере
Ваня Возлюбленный последние 3 года работал в SkyEng, занимал позицию Head of Product одной из групп продуктов. Затем стал Head of PMO в операционной платформе (это большое объединение команд, которое отвечает за все операционные продукты внутри SkyEng - CRM, телефония, мессенджеры, системы бизнес-процессов, подбор преподавателей и т.д). Для операционной деятельности компании - это довольно важные продукты, отказ любого из них сразу приводит к остановке операционной деятельности. Управлять этими продуктами нужно очень аккуратно, чтобы ничего не сломать.
"Определение, которое я использую для себя: я не претендую на истину, но считаю, что управление продуктом - это способность вносить изменения в продукт для достижения целей бизнеса или клиентов. Иными словами, это череда проектов. Так мы пересекаем грань между продуктовой и проектной деятельностью."
Не тот рост продукта, о котором мечтал
Любой продакт обычно работает примерно так. Есть продакт, команда разработки и продукт, на который возможно влиять через разработчиков. По мере роста компании команда разработки начинает делиться, у вас появляется коллега, далее в команде появляется продакт-лид (либо вы сами им становитесь). На этом этапе у вас может быть до 10 продуктов. При этом под продуктами мы здесь понимаем изолированные системы, выполняющие какую-то бизнес-функцию.
В работе продакта - немало подводных камней. Если вы хотите быстрее и безболезненнее вырасти до уровня Senior, лучше знать о них заранее. Совместно с ProductStar мы подготовили большой курс для тех, кто хочет вырасти в профессии и закрепить новые знания на практике. Промокод со скидкой на курс - по ссылке.
Далее у вас в структуре появляется CPO (либо вы сами дорастаете до этого уровня). На этом уровне у вас уже десятки продуктов и команд. Хорошо, если в эту ситуацию вы пришли эволюционно. Например, компания развивалась 5-10 лет - у вас было время, чтобы построить процессы.
Но мы в такой ситуации оказались революционно: сначала 3, затем 4, а затем 7 наших команд были объединены в одну структуру - в операционную платформу. Каждый продолжал эффективно заниматься своей работой, но как одна большая структура с назначенной целью мы работали не очень хорошо. У нас не получалось вносить в продукт желаемые либо значительные изменения. А вносимые изменения не соответствовали стратегии и были не всегда обоснованы.
Не связанные общей целью продукты не работают на пользу бизнесу. Портфель неуправляем.
Пример 1. Решили добавить у себя в чат поддержки кнопки для вызова бота. Спроектировали, собрали тимлидов (команд веба, iOS, Android), они оценили задачу так: по 5 стори поинтов, возъмем ее в следующий спринт. В реальности - задача заняла 2 квартала, потому что каждая из команд была самостоятельна. Задачу взяли, но затем нашли причины для того, чтобы ее подвинуть или сделать по-своему. Еще одна причина - отсутствие координации. Проект сильно буксовал.
Пример 2. Придумали классный виджет, который точно принесет много денег компании. Уверены в этом на 100%, можно ничего не проверять - надо скорее начинать делать. Ожидание: 8 процентных пунктов к выручке компании. Реальность - заработали 13 тысяч рублей, потратив 2 месяца на разработку. Причина провала - вера вместо расчетов.
Пример 3. Внутри SkyEng долго использовалась большая и сложная legacy система (CRM 1). В это время уже существовала CRM 2 - модная, красивая, с нормальным движком бизнес-процессов, но ужасно сложным фильтром. Решили выпилить легаси систему. Ожидали, что потратим на это 3 месяца, в реальности: 2 года "In progress". Причина в том, что нам нужно было договориться на уровне всех команд разработки SkyEng. Это никто не координировал, проект 2 года стоял на месте. Точнее, что-то делалось, но результата не было видно. К этому примеру и проекту я вернусь позже.
Рецепт проекта, который не взлетит
Посмотрев на эти проекты, мы вывели чек-лист, по которому стали определять проекты, имеющие высокий риск провала.
1) Заказчик принес не проблему, а решение. Что-то вроде: "Пожалуйста, сделайте мне так, чтобы при попытке оплатить пользователя разлогинивало. Не спрашивайте зачем."
2) Вера вместо расчетов.
3) Привлечено больше двух команд. Чем больше команд, тем хуже результат.
4) Пропущен этап проектирования. Как только вы поняли, что ваш проект сложный технически, технологически и архитектурно, начинайте делать. Не задумывайтесь как.
5) План проекта составлен без участников этого проекта. Например, у вас должны быть сроки, которые оправданы, но не реалистичны (нужно стартовать фичу 1-го мая, потому что это высокий сезон - оправдано, но т.к. сегодня 29-е апреля - нереалистично).
Так мы научились прогнозировать риск провала.
Мы поставили амбициозную цель. Создать такую структуру, в которой все продукты развиваются согласно продуктовой стратегии. А сложные проекты имеют ресурсы для их эффективной реализации.
Поиск решения
Мы начали с кастдева. Им занимался я. Провели 100 опросов и 20 интервью, на что ушло примерно 2 недели. Собрал огромный объем информации. Ключевой мой вопрос к людям - на слайде.
Я ожидал, что нам будут рассказывать про наши продукты (продукт плохо сделан, плохо стыкуются между собой и т.п.). Внезапно мы поняли, что бОльшая часть проблем (помечены на слайде выше сердечками) находится в проектной плоскости. Т.е. хромает процесс реализации проектов. Стало ясно, что стоит сфокусироваться на этом.
Мы подошли к процессам как к продукту. Нарисовали User Story Map. Определили, что у нас есть 3 вида пользователей и 4 этапа CJM: инициация, планирование, реализация и закрытие. Т.е., мы разложили проект как продукт.
Далее мы поняли, что нам нужен тот, кто будет оценивать все входящие проекты и находить те, которые, скорее всего, зафэйлятся. Потом он будет эти проекты координировать и завершать. Это должен быть отдельный человек, которого на тот момент у нас не было.
Я тем временем занялся Market research. Начал с запросов в Google "Как правильно быть CPO", "Продуктовая стратегия скачать", "Что делать если не получаются проекты", "Сложные проекты сделать онлайн", "Что делать если плохие процессы" и т.п. Так мы пришли к термину "Офис управления проектами" (проектный офис). Мы догадывались, что нам нужно именно это, но решили перепроверить гипотезу. При этом данному решению более 50 лет.
Project Management Office
Если коротко, это "спецназ", который ведет проекты. Мы взяли из PmBOK основные функции проектного офиса, убрали из списка то, что не применяется в нашей отрасли (улучшение качества процессов управления проектами, отчетность, поддержка системы EPM) и осталось 5 пунктов.
1) Инициация проекта
2) Планирование проекта
3) Исполнение, мониторинг и контроль проекта
4) Управление знаниями
5) Маркетинг деятельности
Первые 3 пункта - самые важные. 4-й и 5-й - "по вкусу".
Далее мы нарисовали процесс и определились - что будет делать проектный офис, а что будут делать команды так же, как они и делали. Так, мы полностью вынесли этап инициации в область проектного офиса: он занимается проверкой того, а нужно ли делать абсолютно все проекты, которые мы пытаемся стартовать. Далее определяем сложность (по чек-листу про риск фэйла). Если проект сложный - остается на уровне проектного офиса. А если простой - передается на уровень отдельной команды. Забегая наперед скажу, что 90-95% проектов переходили на уровень команды. То есть каждая команда обладала ресурсами, чтобы выполнять свои проекты. Лишь небольшая часть проектов, довольно важных, фэйлилась и оставалась под управлением проектного офиса.
Структура команд и связь с PMO
Как это выглядело у нас раньше? Много заказчиков, много продакт лидов, а Head of Product или CPO пытается как-то экранировать коммуникацию между ними, чтобы управлять развитием своего продуктового портфеля. В новой структуре PMO - единая точка, узел, где мы будем контролировать всю коммуникацию между стэйкхолдерами и командами.
Власть
Мы решили, что в новой структуре наш PMO должен находиться под Head of Product, но над командами. Это очень важный момент. Мы декларировали всем сотрудникам следующее: проектный офис вправе выделять любые ресурсы, потребные для выполнения проекта. То есть у меня, как у Head of PMO, не было своей команды. Но в рамках проекта, за который я отвечал, я был вправе аллоцировать любые ресурсы любой команды. Получается, что в рамках проекта мне подчинялись ребята, которые выполняют этот проект. Подчинение было не иллюзорным, т. к. я был в структуре на уровень выше них.
Защита идеи
Мы поняли, что у нас есть процесс, способ, структура - настало время попробовать. Мы перешли к внедрению: собрали всех ребят и начали продавать эту идею.
На уровне отдельных ячеек я показывал каждому продакту и продакт-лиду, как информация об их проектах будет перемещаться между планами.
Далее перешли к практике, к общему планированию. Делали его как обычно, но с той лишь разницей, что для всех 7 команд мы собирали бэклог в одном документе (чтобы ничего не потерять). Там были внутренние, внешние и межкомандные проекты. Выглядело это как файлик, открытый для редактирования любым сотрудником SkyEng в течение 2 недель. Туда вносят изменения все, кому это нужно. Далее я как Head of Product просматриваю каждый проект. Соответствует ли он стратегии? Есть ли описание, расчет ценности, метрики? Если чего-то нет, такой проект не уходит в план на квартал.
Далее я, как человек обладающий экспертизой во всех командах, размечал каждый из проектов на причастность к командам. Т.е. здесь я уже начинал аллоцировать ресурсы, определял зону ответственности. Далее ребята из команд дополняли каждый из проектов ресурсами, которые дополнительно потребуются. В итоге у нас получается такая карта ресурсов (рисунок ниже). Мы видели, в каком проекте какие команды потребуются. Финальный шаг - получить аппрув от команд и сообщить стейкхолдерам о том, что получилось.
Что получили в результате? У нас была полная картина происходящего.
1) В одном плане видны все запросы, включая внутренние проекты.
2) Видны все межкомандные связи
3) Все проекты прошли скоринг и соответствуют критериям важных/ценных проектов
Но что, если у вас вот такая структура?
Тогда у вас вот такой инбокс. 188 проектов нам занесли за 2 недели. Это было тяжело - приходилось за выходные переваривать огромный объем информации.
Фраза дня: "Не берем"
Мы отметали проекты, где не было обоснования. Я знаю, что во многих компаниях культура не позволяет этого сделать. Увы, у меня нет совета, как вам в таком случае можно перешагнуть этот барьер. Глобально рекомендация одна: не берите в проработку проекты, где нет обоснования, расчетов и с комментариями вроде: "итак ясно, что делать". Скорее всего, такой проект будет просто сжиганием денег.
Прокачайте навыки middle и senior продакта на нашем совместном курсе с ProductStar. Забирайте промокод на скидку в 56% по ссылке.
Командное планирование
Вернемся к общему плану. Видя бэклог, продакт лиды разбирают проекты по своим командам. Итого: у нас есть общий бэклог и 3 частных бэклога трёх команд. Далее я создаю отдельные планы для важных проектов, которые могут зафэйлиться. Далее подключается аналитик, который проверяет все проекты и также составляет свой бэклог на квартал (вписывает туда метрики, данные и всё, чем он должен будет поддержать эти проекты). Так выглядит структура бэклогов, которые фактически являются одним большим массивом, просто разбитым на подмножества либо по командам, либо по проектам.
А после оценки ресурсов мы получаем роадмэп на квартал: для каждой отдельной команды, проекта и для всей платформы в целом. Это очень удобно: мы его публикуем, зайти может каждый стейкхолдер и увидеть, в какой момент у нас будет готов тот или иной проект.
А так выглядит наш реальный таймлайн. 15/06 я закрыл файлик сбора, далее - 2 недели и 4 больших общих встречи.
Реализация
Здесь все довольно просто. Т.к. проектный офис не погружается на уровень команд, а работает только на уровне проектов, то мы еще на старте договорились, что не будем лезть во внутрикомандные процессы. SCRAM, Daily, планирование, скоринг бэклогов - все это команды делают так, как им удобнее.
Важные моменты в координации:
1) организовать точку входа для стейкхолдеров
2) организовать регулярные встречи
3) регулярное обновление плана
4) внесение изменений в план
5) выделять достаточно ресурсов
Важно. Тот, кто это делает, должен быть у вас: а) на фуллтайме (например, проектный менеджер из проектного офиса, б) с уровнем +1 от уровня продакт-лидов команд. Если нет координирующего человека на уровень выше, случается конфликт: группа равных по уровню продактов или тимлидов, которые никогда не договорятся о выделении ресурсов. Потому что у каждого из них есть свой фокус, каждый из них будет пытаться делать то, что может, а не то, что нужно в проекте. Поэтому нужен человек уровня +1, который будет разрешать конфликты ресурсов и прав.
Завершение проекта
Завершение проекта - не значит сделать все таски. Это значит: 1) достичь целей проекта либо ограничений проекта (например, бюджет, сроки и т.п.)
Поэтому завершение:
1) может наступить на любом этапе проекта
2) критерии завершения проекта должны быть описаны на старте
3) нельзя продолжать проект после наступления критериев его завершения
К концу первого квартала у нас были реализованы два сложных проекта. Мы удивились, т.к. раньше подобный проект занимал год.
Помните задачу про сложную легаси систему, которую нам нужно было выпилить? Мы организовали сложную коммуникацию, сфокусировались на управлении ресурсами. Задействовали 12 команд разработки, 21 участника, 240 человеко-часов. За 3 месяца мы справились (что соответствовало ожиданиям по срокам).
И еще один успешный кейс:
Выводы. Как мы теперь работаем
- Любое изменение в любом продукте мы считаем возможным.
- Руководитель знает все, что делает каждая из команд и это ценно. Ведь мы проверили каждый проект на его ценность
- Стейкхолдеры знают, что и когда появится для них в нужном продукте.
Основные принципы:
1) Координация проектов - это отдельная работа. Нужен выделенный человек, если у вас большие и сложные проекты с кучей команд.
2) Межкомандная задача - это уровень +1 от каждой из команд.
3) Смелей отказывайтесь. Не делайте работу, для которой нет оснований.
4) Не жди от заказчика описания или расчетов. Но если мы верили в проект, мы сами брались за расчеты, начинали собирать данные и т.д. Так удавалось затащить хорошие проекты, но на которые у стейкхолдеров не хватало обоснования.
5) Лучше планируй сложные проекты.
6) Проектирование - это обязательный этап проекта. В большой системе с кучей продуктов нельзя взять, что-то подергать и ожидать хорошего результата. Скорее всего, вы по пути еще и что-то сломаете.
7) Завершайте проекты, знайте свои ограничения и не сжигайте деньги.
Смотреть доклад по ссылке
Присоединяйся к чату комьюнити
Будь в курсе всех новостей, обращайся за помощью к коллегам и находи единомышленников!
