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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При работе над общими целями часто возникают вопросы насчет того, как соотнести прогресс с какой-то конкретной командой, ведь изменения вносятся многими командами, которые действуют параллельно. Это так называемая проблема атрибуции продукта. Существуют два широко распространенных подхода к этой проблеме, которые мы обсудим в главе 59 («Ответственность и подотчетность»).

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

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

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