Можно отметить несколько необходимых форм сотрудничества, которые часто сбивают с толку продуктовые организации, поскольку те стремятся обеспечить автономию команд и расширить их права и возможности. Давайте обсудим два конкретных вида сотрудничества: совместные командные цели и общие цели.
Первой и наиболее базовой формой совместной работы является концепция совместной командной цели — когда несколько команд имеют одну и ту же командную задачу. Если речь идет о важной цели, в этом нет ничего необычного.
Особенно часто это встречается в случае крупных проектов, масштабных задач, требующих помощи целого ряда продуктовых команд.
Самый наглядный пример — продуктовая команда пользовательского опыта и платформенная команда имеют одну и ту же цель, так как ожидается, что команда разработчиков платформы должна предоставить один новый сервис или несколько, которые необходимы для работы продуктовой команды пользовательского опыта.
В этом случае команды заключают друг с другом простое соглашение в формате API, затем продолжают работать каждая над своей частью задачи, после чего снова объединяют усилия во время тестирования и реализации продукта.
Другая форма совместной командной цели — когда несколько команд временно объединяются для решения особо сложной проблемы. Обычно это касается проблем, работа над которыми требует различных навыков. Объединение команд часто может обеспечить знания и синергию, необходимые для быстрого поиска эффективного решения.
В определенных ситуациях команды «съезжаются» на несколько дней или на неделю, осуществляя так называемый сворминг. Это интенсивный метод совместной деятельности, позволяющий глубоко погрузиться в работу по исследованию или выпуску продукта либо одновременно по обоим направлениям для решения особо сложной проблемы.
Еще одна форма сотрудничества — общая цель, когда нескольким командам предлагают работать над одной проблемой, но решать ее разными способами.
Причиной такого рода сотрудничества является управление рисками. У нас есть надежная продуктовая стратегия, основанная на фокусировке и инсайтах, но нам нужно реализовать ее, а это часто связано с решением очень сложных проблем.
Если проблема особенно сложна, мы понимаем, что трудно определить, какой подход к ее решению, если таковой вообще есть, приведет к желательному результату.
В этом случае мы можем попросить несколько команд работать над одной проблемой — в надежде, что хотя бы одна команда сможет сгенерировать нужный эффект. Конечно, было бы лучше, если бы все они добились значимого успеха, но мы понимаем, что это маловероятно.
Хороший пример — ситуация, при которой одной из приоритетных областей является отток подписчиков, то есть когда слишком многие из наших клиентов покидают сервис. Разумеется, есть много способов решения этой проблемы, поэтому участие нескольких команд, смотрящих на нее с разных точек зрения, часто оказывается эффективным способом снижения риска[46].
В этом случае командам придется контактировать друг с другом, чтобы избежать противоречий в том, что делает каждая из них. Но, как правило, каждая команда решает проблему, исходя из единой точки зрения, существующей в команде, используя собственные код и технологии. Так что результаты их работы обычно достигаются независимо, а потом суммируются.
При работе над общими целями часто возникают вопросы насчет того, как соотнести прогресс с какой-то конкретной командой, ведь изменения вносятся многими командами, которые действуют параллельно. Это так называемая проблема атрибуции продукта. Существуют два широко распространенных подхода к этой проблеме, которые мы обсудим в главе 59 («Ответственность и подотчетность»).
Важнее уяснить, что вполне нормально и даже целесообразно поручать нескольким командам работать над одними целями одновременно.
Компании, избегающие общих целей ради обеспечения автономии команд, сужают свои возможности по решению наиболее сложных и важных проблем.