Как LeSS помог поддержать бурный рост e-commerce SOKOLOV во время пандемии

О компании SOKOLOV
SOKOLOV — это крупнейший российский производитель ювелирных изделий, который имеет давнюю историю и динамично развивается по сей день. SOKOLOV — производственная компания, имеющая не только большую производственную часть, но также физические продажи и цифровые продажи через интернет магазин. Периметром внедрения LeSS раз стал интернет-магазин SOKOLOV (e-commerce), который обеспечивает возможность удаленной покупки, доставки и примерки ювелирных украшений.

Контекст внедрения LeSS
Есть важный нюанс, который красной линией проходит через большинство решений, принятых в процессе развития продуктовой группы e-commerce в SOKOLOV. Это то, что запуск LeSS в компании совпал с стремительным ростом e-commerce направления. В марте 2020 года через неделю после запуска в России был введен локдаун по всей стране, связанный с распространением COVID. Что привело к закрытию на несколько месяцев всех офлайн магазинов ювелирных изделий. И по сути к парализации классического бизнеса. Одновременно это потребовало быстрых и значительных вложений в развитие e-commerce. Что и привело к стремительному росту направления с точки зрения как бизнеса, так и количества вовлеченных в это продуктовое направление людей.

Управление и структура в SOKOLOV
E-commerce направление в SOKOLOV развивалось последовательно. Сначала оно представляло собой совсем небольшую команду, которая в какой-то момент выросла до 14 человек и управлялась, по сути, как пул ресурсов, с помощью руководителей проектов. На этом масштабе уже начались проблемы с управляемостью, так как общего понимания продукта не было, задачи поступали от разных внутренних заказчиков. Команда продолжала быстро расти, в какой-то момент ее численность уже составляла 21 человек. И этот момент совпал с наймом нового руководителя данного бизнес-направления. Михаил (CTO SOKOLOV) понял, что это тот самый переломный момент, когда необходимо провести изменения. Но у каждой стороны (бизнеса и ИТ) был свой взгляд на решение данной проблемы, и диалог перерос в конфликт.

Существующий конфликт как отправная точка в LeSS
В этот момент Михаил и позвонил мне с просьбой помочь им в сложившейся ситуации. Он рассказал мне о проблеме выстраивания процессов разработки и разгорающемся конфликте между ИТ и бизнесом в периметре e-commerce. И попросил помощи в решении этой проблемы. В результате нескольких созвонов с конфликтующими сторонами у меня получилось уговорить обе стороны на 3-х дневную сессию для решения конфликта, на которой мы все вместе договоримся о продуктовой структуре подразделения, которая должна устроить бизнес и разработку.

Сессия по определению продукта для формирования общего контекста для изменений
Первый и второй день сессии был посвящен тому, чтобы сформировать понимание всей группы о том, каким образом выстраивается структура продуктовой компании с фокусом на ценности и адаптивности. В процессе обучения мы также на примерах разобрали типовые структуры, которые используют в продуктовых компаниях (component teams, Spotify-like specialized feature teams, channel teams, etc.) и проблемы, которые они порождают в организации. В процессе первых двух дней группа сформулировала единое определение продукта (сервиса) и это позволило перейти к следующей части — проектированию структуры продуктовой группы.

Сессия по самодизайну команд
Для формирования дизайна структуры команд решено было использовать воркшоп по самодизайну команд. Именно настоящему самодизайну, а не просто свободе выбора команд. То есть, в процессе самодизайна участники должны были определиться с тем, сколько будет команд, вокруг чего они будут собраны, какое количество бэклогов будет и т.д. Для этого я модифицировал схему предложенную Крэйгом Ларманом и Ахмедом Фами (link), добавив в нее дополнительный этап. На этом этапе участники должны разработать несколько вариантов дизайна структуры продуктовой группы и выбрать один итоговый.
Как это было сделано? На старте мы разбили всех участников на четыре смешанные группы, задача которых была в режиме world cafe разработать четыре варианта структуры продуктовой группы. Вся работа была поделена на три 15 минутных отрезка. Каждые 15 минут группы переходили к следующем столу и дорабатывали тот вариант структуры, который разрабатывался за данным столом. При этом за каждым столом было закреплено по одному человеку, который вводил в курс вновь пришедших и курировал работу по доработке соответствующего варианта структуры. Это помогало всем командам погрузиться во все четыре варианта дизайна структуры и понять отличия.

Через 45 минут работы владелец каждого стола презентовал разработанный вариант структуры всем, включая ключевых заинтересованных лиц. Все озвучивали проблемные моменты и положительные стороны каждого варианта.

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

Но все было не так просто. Несмотря на то, что данный вариант был выбран подавляющим большинством, директор по электронной коммерции настаивал на своем варианте. И отказывался двигаться дальше, не веря, что данный вариант может повлиять на результат. Что делать? Обстановка накалялась…
Ситуацию спасли три вещи:

1. Прозрачное голосование
2. Разговор тет-а-тет с директором по электронной коммерции.
3. Коммитмент команд через эксперимент.

1. Прозрачное голосование - то, что мы провели открытое голосование точками за варианты помогло всем понять, в какой из вариантов подавляющая часть группы готова идти. Что дальше позволило использовать этот факт в обсуждении с ЛПР.
2. Разговор тет-а-тет с директором по электронной коммерции - на перерыве между ключевыми моментами сессии. Я переговорил с ecom директором и спросил его о том, почему он сопротивляется изменениям. Он ответил, что не верит, что этот вариант позволит хоть как-то изменить ситуацию и ускорить процесс. Дальше я объяснил, что странно настаивать на реализации варианта, который не поддерживает большая часть участников изменений. Я попросил дать им шанс, если люди горят изменениями, при этом попросить их о том, что они явно сформулировали критерии успешности. Директор согласился провести данные изменения в качестве эксперимента, при этом через квартал подвести итоги.

Выбор пилота эксперимента
Вернувшись после перерыва группа решила двигаться по варианту, за который проголосовало большинство - 2-х командный LeSS.

Но при этом мы обсудили, что необходимо оформить данное изменение как эксперимент, с понятным изменением относительно текущего состояния. Мы поделили всех участников на несколько групп, чтобы они параллельно сформулировали несколько вариантов таких экспериментов. В качестве шаблона для оформления эксперимента мы воспользовались форматом Change Story из Lean Change Management.

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

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

Первое планирование спринта
И так непростую ситуацию с запуском команд и разрешением конфликта усложнило то, что запуск команд пришелся прямо на активную фазу пандемии. Через неделю после очного запуска команд по всей стране был введен lockdown. С одной стороны, это потребовало старта команд сразу в виртуальном пространстве: Zoom, miro и т.д.
А с другой стороны, открыло новые возможности, так как направление ecom для компании в этот год стало одним из самых приоритетных и активно растущих в связи с вынужденным закрытием офлайн магазинов.

Фото ранних планирований

Эксперимент по запуску discovery-сообщества
На самодизайне команд мы договорились еще об одном эксперименте — запуске discovery-сообщества, задачей которого является генерация и быстрая проверка гипотез для обеспечения наиболее ценного наполнения бэклога.

В это сообщество (виртуальную команду) вошли Data-аналитик, дизайнер, Front-разработчики из обеих команд (смотри картинку ниже) и продуктовый менеджер (правая рука PO). Ребята осуществляли работу по HADI-циклу, интегрированному в общий спринт; каждые две недели в дополнение к общему планированию они проводили генерацию и планирование гипотез для проверки. И на общем Обзоре Спринта показывали результаты проверки гипотез и обсуждали со всеми дальнейшие направления исследования. Аналогичный процесс запустила и команда Маркетинга.

По итогам каждого Обзора Спринта участники Discovery community производили самооценку своей работы по следующей шкале:

Такая механика позволяет понимать здоровье дискавери-процесса и поддерживать активность в нем за счет простой геймификации.

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

В течение года после старта изменений, направление претерпело очень быстрый рост, количество людей в периметре выросло в разы. И стало понятно, что PO на таком масштабе уже неизбежно требуется делегировать работу с бэклогом продукта своим помощникам (APO) и переходить к LeSS Huge. Но давайте обо всем по порядку.

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

В определенный момент количество проблем, которые создал данный эксперимент превысило позитивный эффект, полученный на старте. Главным образом, страдала эффективность Событий Скрама при такой численности команд.
В этот момент было решено, что продуктовая группа готова к переформатированию: к увеличению численности команд при сокращении количества участников внутри.

Сессия по самодизайну команд при переходе на LeSS Huge
Для переформатирования существующих и формирования новых команд было решено использовать самодизайн команд — формат, уже знакомый многим в продуктовой группе. После первых оценок, стало понятно, что количество команд будет больше 8. Было решено использовать LeSS Huge.

До сессии было принято решение о количестве и назначении Requirement Area. Их получилось 4: Marketing, Shop, Sales, Order Management. А также было принято решение о том, что в периметре будет одна компонентная команда Processing, имеющая отдельный пул задач.

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

В процессе сессии саморедизайна участники определились с составом и были сформированы девять e2e команд по четырем Requirement Area. Самые внимательные читатели тут скажут, но это явное нарушение правил LeSS Huge. Ведь в Requirement Area должно быть не меньше 3-х команд. И это правильное замечание. В итоговом дизайне только одна из четырех RA содержала 3 команды, три оставшиеся содержат по две команды каждая.

Вот почему было принято такое решение. Причина — это все тот же стремительный рост e-commerce и численности продуктовой группы. Эти RA были созданы с оглядкой на ближайший рост количества команд в них. Пока вы читаете этот абзац, в SOKOLOV идет найм разработчиков в периметр ecommerce ;)
Самое интересное произошло с разработчиками мобильного приложения (Flutter) — они приняли решение полностью разойтись по фиче-командам. В том числе по фиче командам полностью разошлись разработчики-эксперты из задуманного менеджментом центра компетенций Flutter.

Своевременный переход к продуктовой структуре позволил поддержать и реализовать быстрый рост e-commerce направления. В первый квартал после перехода в LeSS команды смогли закрыть только одну из девяти амбициозных бизнес целей, которые стояли перед e-commerce направлением. Но уже во втором квартале картина радикально изменилась — были закрыты 7 из 9 целей.

1. При таком динамичном росте большой проблемой становится выстраивание и выравнивание процессов командами. Постоянный приток новых людей и частый пересмотр структуры приводит к частой дестабилизации.

2. Очень сложно в уже существующую LeSS структуру нанимать новых людей, особенно на позиции уровня APO. Так как необходимы люди не только с экспертизой в продукте, но с нужным в LeSS майндсетом. Зачастую на такую позицию приходят люди, имеющий свой опыт не только в продукте, но и в процессах управления. И этот опыт они активно пытаются привнести в RA. Что вызывает конфликты и проблемы. Для решения данной проблемы сейчас решено собеседовать кандидатов на роль APO не только со стороны бизнеса, но также со стороны команд и менеджмента ИТ.