Создающие ценность. Как превратить команду в экспертов, которые меняют рынок - Каган Марти

Организация испытывала проблемы с очень значительным техническим долгом в связи с быстрым ростом бизнеса в предыдущие несколько лет. Годом ранее инжиниринговая компания предложила двухлетний план перехода организации на внедрение более современной архитектуры микросервисов на основе AWS.

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

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

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

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

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

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

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

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

Итак, продуктовые лидеры просят участников продуктовых команд встретиться с ними и вместе обсудить продуктовую стратегию [55].

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

Лидеры объясняют, что в ближайшие дни они поручат каждой продуктовой команде одну-две проблемы, которые нужно решить для достижения этих трех целей. А пока они бы хотели, чтобы команды рассмотрели проблемы, идеи и технологии, которые, по их мнению, могли бы им помочь [56].

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

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

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

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

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

• Слишком большой объем работы пришелся на одну конкретную команду — в данном случае команду главной страницы работодателя. Лидеры предложили два варианта: передать часть работы другой команде или добавить в нее еще одного-двух инженеров. В итоге они выбрали компромиссный вариант, использовав частично и первое, и второе решение.

• Самое распространенное препятствие — выявление одной командой зависимости от другой, когда нужно было знать, можно ли рассчитывать на получение необходимого в течение квартала. Это происходило как в процессе планирования работы на квартал вперед, так и неоднократно в течение данного времени, когда команды погружались в работу более основательно. Преимущественно речь шла о зависимости от платформенной команды, но иногда бывали случаи, когда изменения в команде, ориентированной на работодателя, требовали изменений со стороны команды, ориентированной на соискателя. В каждом случае менеджерам приходилось разговаривать напрямую с вовлеченными сторонами, чтобы понять, может ли проблема зависимости быть улажена и когда. В большинстве случаев интересы обеих сторон можно было удовлетворить в результате переговоров и компромиссов [57].

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

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

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

Глава 67. Цели продуктовой команды

Ниже — результат переговоров между продуктовыми лидерами и продуктовыми командами, а также между самими командами, когда одна из них выявила зависимость от другой.

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

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