Реструктуризация группы продуктов Braze

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

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

Ранняя структура: соответствие продукта/рынка и не только

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

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

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

Кроме того, эта структура помогла нам достичь глубокого мастерства в некоторых технических областях, имея команду всего из 10–15 человек. Многие элементы наших основных продуктов — например, уровень контроллера представления модели внешнего интерфейса, API-интерфейсы и высокопроизводительный код отправки сообщений — были полностью поняты лишь несколькими людьми.

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

Более поздняя структура: рост и масштабирование

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

В конечном итоге мы переключились на организацию, построенную вокруг многофункциональных Agile-команд, аналогичную модели Squad/Tribe, популяризированной Spotify. Наша новая организационная структура выглядит так:

Большая часть нашей команды работает в «вертикалях продукта», соответствующих ключевой области нашего продукта или бизнеса. Например:

• Наша команда Email & Enterprise работает с электронной почтой сверху вниз, а также с некоторыми областями продукта, такими как управление разрешениями, которые имеют решающее значение для многих наших крупнейших клиентов.
• Наша команда по обмену сообщениями и автоматизации владеет несколькими областями продуктов, связанными с сегментацией пользователей, обменом сообщениями и нашим флагманским продуктом для оркестровки Canvas.

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

воздействия

Наша реорганизация значительно уменьшила зависимость между командами. Раньше мы боролись с проблемой планирования, похожей на судоку, — распределением правильного баланса специализированных наборов навыков (инженерия, дизайн, управление продуктом и т. д.) для данного проекта в определенное время. Это также согласовало краткосрочные стимулы — до перехода команды часто полагались на контрагентов, которые стремились к несвязанным целям. С нашей новой структурой команды разработчиков становятся независимыми, имеют гораздо больший контроль над сроками и полностью согласовывают цели, что повышает производительность и моральный дух.

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

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

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

Конечно, ни одна система не идеальна. Сосредоточив внимание на принципах, ориентированных на продукт, мы расширили возможности команд по оптимизации для удовлетворения локальных потребностей за счет целостных приоритетов. Например, можно сосредоточиться на локальном техническом долге («этот контроллер громоздкий») вместо глобальных проблем («изменение нашего внешнего интерфейса повысит общую скорость разработки»). Предвидя эту потребность, мы предприняли шаги по созданию сквозных команд, упомянутых выше, и использовали специальные комитеты для других крупных проектов — например, комитет для создания целостной системы продукта/дизайна из интерфейсных компонентов и шаблонов проектирования. .

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

Выводы

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

• Устранение зависимостей и согласование стимулов приводит к огромному повышению эффективности.
• Расстановка приоритетов «яблоки к яблокам» проще и эффективнее.
• Глубокий опыт в отношении конкретных потребностей клиентов или бизнеса приводит к лучшим результатам продукта.
• Работа с одними и теми же членами команды в течение длительного периода имеет решающее значение для построения хороших рабочих отношений.

Я бы рекомендовал эту структуру для любой команды, имеющей определенные ключевые характеристики: кросс-функциональная организация, в которой функциональные эксперты, такие как менеджеры по продукту, дизайнеры и инженеры, являются равными заинтересованными сторонами; более 15–20 человек в объединенной команде разработчиков продукта; и, самое главное, устойчивое соответствие продукта рынку. И если такая структура команды кажется вам привлекательной, мы нанимаем!