Последние 2,5 года я работаю руководителем продукта в Леруа Мерлен. В моей команде чуть меньше 30 человек, и мы занимаемся шагом клиента оформление заказа.
Кто такой руководитель продукта в Леруа
Задачи руководитель продукта очень похожи на роль Product Owner из Scrum — смесь проектного менеджмента с продуктовым. В переписках на английском языке даже фигурирует именно такое название должности.
Ответственность руководителя строится вокруг конкретного шага или сервиса для клиента. При этом он работает в связке с командой разработчиков, которые отвечают за одну или несколько технических систем, которые помогают этот шаг или сервис реализовывать.
О нашей зоне ответственности
Мы делаем Корзину и Чекаут на сайте и инструменты для создания заказа сотрудниками разных подразделений. В основном все для web, без нативного mobile. Его делает отдельная команда, но она зависит от наших технологий.
Оформление это, когда клиент уже определился с тем, что ему нужно. Теперь мы должны пообещать ему, когда и как он сможет получить выбранные товары или услуги, а после инициировать внутренние бизнес-процессы, чтобы его потребность была удовлетворена.
Фактически мы полностью отвечаем за омниканальный опыт и строим все системы независимо от того, в какой канал пришел клиент на этапе Оформления.
Это ответственность как за работоспособность, так и за весь цикл изменений: от идеи/“сформулированного проекта”/проблемы и до релиза все проходит внутри.
Для этого в команде есть специалисты всех направлений: продакты, дизайнеры, аналитики, frontend и backend инженеры, автоматизаторы тестирования.
Важная особенность — вся команда большую часть времени работает удаленно.
Как начиналось
Когда я пришел в команду, это была просто разрозненная группа из 18 человек. Некоторые даже не знали друг друга.
Команду буквально собрали из двух совершенно разных частей компании: не было общей цели, понимания куда двигаться и налаженных социальных связей внутри.
С точки зрения технологий было не лучше: 4 версии оформления заказов, каждая не отвечала всем потребностям бизнеса, имела критические недостатки в надежности и требовала срочной переработки.
Одновременно с этим в компании происходили трансформационные проекты, ряд из которых также зависел от нашей команды.
И, конечно же, мелкие фичи, которые по мнению инициаторов не требовали приоритезации, потому что “ну что сложно что ли, там делов на пару дней”.
Ребята были дезориентированы, не понимали за что браться, а давление было колоссальное.
Деление команды
Практически невозможно было сдвинуться.
Это было следствием фактического отсутствия общего контекста и жестких культурных различий в подходе к решению задач.
Попробовали разделить команду на две подкоманды, перетасовав часть ребят между ними, так чтобы они оказались на новом для себя периметре с новыми людьми рядом, и выделив несколько человек тех, кто будет в едином контексте.
Разделяя команды, ориентировались на текущие срочные проекты, которые компания определила как ключевые для стратегического развития. Принципиально делились на онлайн и офлайн бизнес. Драйвить концертные изменения стали системные аналитики.
Из 18 человек только 2 были в общем контексте: продакт (я) и проджект.
Этого оказалось недостаточно для объединения контекста. Но робко начали образовываться новые социальные связи, формироваться общая инженерная культура. С технологиями стало хуже: все разъезжалось еще сильнее.
Через 9 месяцев, один глобальный проект и съезжающие сроки по всем направлениям мы разбавили команду новыми людьми и устроили новую реорганизацию.
Новичков отбирали в первую очередь по софтам, инженерные скиллы ушли на второй план — не хватало тех, кто может драйвить команду.
Осталось разделение на онлайн и офлайн, но добавили еще одну мини-команду для работы с конкретным сегментом клиентов в рамках очередного ключевого проекта.
Кардинально поменялся подход к организации работы внутри спринта: PBR, цели, работа вместе стали обязательными, измерение производительности.
Как итог лидерство на себя взяли инженеры. Это усилило культуру разработки, технологически периметры начали ассимилироваться, выросла надежность.
Производительность мерить не научились, планировать не смогли, сроки поехали.
А главное бизнес ценность докатывалась слишком медленно — небольшое изменение раз в квартал. Но с такой скоростью ошибка в планировании следующего шага становилась близкой к фатальной.
Разрабатывать могли быстро, но проседало тестирование.
Мини-команда из 3-х человек, которая была сосредоточена на отдельном проекте и ни на чем другом, полностью смогла попасть в намеченные сроки.
Поняли, что проблема в большом количестве работы в моменте. Нужно было научиться расставлять приоритеты.
Еще через 6 месяцев усилились в тестировании: инвестировали много сил в инфраструктуру, покрыли легаси автотестами. Проблемы оставались, но мы смогли чаще выпускать мелкие релизы и проверять в правильную ли сторону движемся.
Разработку начали объединять и перемешивать людей между направления, но пока что сохранили разделение на фиче-команды по определенному бизнес-контексту.
Отделили в мини-команду продуктовые исследования, чтобы лучше понимать приоритеты и выкидывать все лишнее.
Получилось разделение на Discovery (исследование продукта) и Delivery (команда разработки).
Как работает Discovery
Исходя из целей, которые компания формулирует для себя приоритетными, команда исследований должна найти ответ, какой следующий шаг мы должны сделать из точки, в которой мы находимся, и объяснить команде Delivery суть этого шага. А после проверить насколько этот шаг сработал.
Какие роли необходимы для функционирования такой команды: менеджер продукта, бизнес аналитики, архитектор, дизайнер продукта.
Конкретно у нас сейчас работают 2 продакт, 2 дизайнера, 1 бизнес-аналитик/поддержка пользователей и архитектор. Еще одного системного аналитика мы растим в продакта.
Главные задачи менеджера продукта правильно сформулировать проблему, смоделировать ее на цифрах, скоординировать и задрайвить решение, взаимодействовать со стейкхолдерами.
Бизнес-аналитик помогает со сбором качественной информации от других участников бизнес-процесса и координации с ними, связанного с проблемой, ее структурировании и валидации предлагаемых способов решения.
Без участия Архитектора очень сложно подтвердить техническую реализуемость осуждаемого решения проблемы. Также эта роль помогает искать источники проблем в системах и иногда переадресовывать их.
На продуктового дизайнера ложится задача не только проектирования опыта, но и общения с пользователями и сбор качественной информации от них. Также у нас дизайнер сам готовит и проводит количественные тестирования интерфейсов с пользователями.
Верхнеуровнево этапы процесса Discovery такие:
- Предварительный сбор информации. Здесь становится точно сформулирована проблема.
- Сбор количественных и качественных данных.
- Анализ всей командой. Важно делать это вместе, что использовать все имеющиеся компетенции.
- Формулирование требований и передача в Delivery.
Подробнее я напишу отдельно.
Как работает Delivery
Выше я писал, что у нас большая команда разработки. Около 20-ти человек. Работать в едином контексте такой толпой невозможно, поэтому мы используем условное деление на мини-команды.
Поскольку наша команда работает над шагом пользовательского пути в нескольких каналах продаж, которые использует компания, то эти мини-команды образуются и по принципу канала, и по конкретной фиче.
На вход в разработку прилетают уже только самые приоритетные задачи. Мы стараемся рассказывать ребятам о всем контексте и о том, что сейчас откладывается, но это происходит не всегда.
Изменение формируется в виде пользовательского сценария, сопровожденного макетами и минимальными бизнес-требованиями.
При передаче продакт дает весь бизнес-контекст команде, который возможно уместить в короткий монолог. После он старается принимать участие в дейликах и обсуждении проблемы, но в большей степени как наблюдатель и источник ответов нарочные вопросы команды разработки.
Задачу берет системный-аналитик. Если необходимо он/она декомпозирует сценарии на более мелкие и проводит предварительный анализ, чтобы рассказать технические особенности реализации и в каких системах они будут делаться.
После этого задачку отправляют на PBR, где уже все потенциальные участники и заинтересованные ее детально разбирают и оценивают сложность каждого сценария в отдельности.
Для оценки используется scrum-покер.
В итоге мы получаем общие затраты на фичу в стори поинтах, условной единице сложности. Сравнив затраты с производительностью в стори поинтах, мы получаем временные затраты в спринтах.
Далее все получившиеся сценарии берет одна или несколько мини-команд, если их возможно распараллелить. В рамках мини-команды аналитик делает черновую версию системной спецификации, с которой после приходит к разработчику и тестировщику. Вместе они обсуждают реализацию и бизнес-контекст.
Именно такие обсуждения и имеют самую большую ценность. Именно во время них ребята лучше понимают задачу. В итоге мы получаем чистовую спецификацию и инженеров, которые хорошо понимают, какую проблему решают.
Иногда на этом этапе они могут кардинально пересмотреть предложенное решение. Что может замедлить поставку, но увеличивает вероятность того, что фича принесет бизнес ценность, а не просто будет сделана.
Обычно этап Delivery занимает у нас 2 спринта. Быстрее поставлять ценность, мы пока не научились.
Я описал скорее идеальную карт ину, и нам удается проходить по такому пути реже, чем в половине фичей. Но мы стремимся к такому подходу, и это дает позитивные результаты.
Какие проблемы
Мини-игра для онлайн ретро: собери продакта
- Не умеем планировать реальную нагрузку и производительность.
Как следствие много работы в процессе, не успеваем закончить в запланированный срок, но берем новое. Это размывает фокус и приводит к потерям на переключении контекста. - Конфликты с операционной частью компании.
Это следствие предыдущего пункта. Если вы систематически вылезаете за рамки спринта с изменениями, операционным командам, которые привыкли к парадигме “человек сидит — работа делается”, сложно планировать свои ресурсы.
Ситуация осложняется, если изменения, которые затронут операционную команду, произойдут через несколько циклов разработки. К этому времени намеченный срок может сдвинуться в 1,5 — 2 раза. - В итоге в лучшем случае от старта разработки до релиза требуется минимум 2 спринта (4 недели).
С такой скоростью страшно брать рискованные гипотезы и приходится сосредотачиваться на менее прибыльных, но надежных. - Системный аналитик нужен и в Дискавери и в Деливери.
Специалисту приходится участвовать сразу в нескольких контекстах, что повышает требования и порог входа. Если анализировать всю задачу на этапе архитектуру, системный аналитик превращается просто в координатора. Такая работа без возможности к креативну демотивирует, - Сложность поддержки несколько версий продукта.
Каждое изменение мы ориентируем на бизнес-показатели, но не каждое изменение дает эффект, поэтому почти все обновления проходят этап тестирования на пользователях (вообще тестируется все, но не всегда в режиме А/Б, иногда когортного сравнение достаточно).
Иногда изменения в том числе приводят и к серьезным архитектурным изменениям. Вплоть до изменения технологий. После таких обновлений нам ни разу не удавалось с первого раза запустить новую версию на том же минимальном уровне бизнес-показателей, что и до. В таких ситуациях поддерживать нам приходится долго поддерживать актуальность кода и главное набора тестов под несколько версий.
Итого
Сейчас нам удалось переломить тренд и начать двигаться одновременно и по ключевым бизнес-направлениям, и в небольших улучшениях важных для текущих пользователей. Все это благодаря налаживанию связей и выстраиваю процессов.
Но большой багаж дублирующих легаси систем, пока что не дает реализовать даже половины бизнес-идей, которые возникают в компании.
Я не считаю, что это плохо. Иногда успевать все может быть вредно. Лучше работать над умением расставлять приоритеты.
На саму проблему лучше взглянуть с точки зрения финансов и их распределения на поддержку и развитие. Но это объемная тема для отдельного поста.
Теперь практически 100% изменений измеримы и положительно влияют на бизнес результаты компании. Иногда не с первой итерации.
Ошибки случаются, но и они дают информацию для планирования следующих шагов.
Также мы убедились, что для больших трансформационных изменений лучше привлекать системных аналитиков еще на этапе исследования. Это поможет им и получить бизнес-контекст и предложить наилучшие подходы к решению проблемы, хотя и приведет к некоторому количеству чисто “технических улучшений” и только постфактум будет понятно, что от них можно было отказаться.
Команда устойчива к потерям людей. И иногда уход специалиста не приводит к увеличению срока по поставке изменения. Люди — это в первую очередь компетенции, а не скорость работы.
Если нам необходима скорость, то нужно работать с инфраструктурой, архитектурой и процессами внутри команды.
Связаться со мной