«Для эффективного внедрения инноваций командам по продукту необходима автономия. Но по мере роста организаций автономия без надлежащей структуры может привести к хаосу».
Будучи старшим руководителем продукта в команде Jira Product Discovery, я вижу отражение этой проблемы в разговорах с клиентами из всех отраслей независимо от масштаба. Снова и снова возникает вопрос: как дать командам возможность работать автономно, сохранив при этом согласованность, чтобы организация функционировала эффективно?
Переломный момент
Все растущие организации рано или поздно сталкиваются с одной и той же проблемой: с одной или двумя командами по продукту все идет гладко, в то время как с пятью командами начинаются заминки. Но когда команд становится десять или двадцать, все буквально сыплется.
Я постоянно замечаю эту закономерность в разговорах с клиентами. Команды по продуктам работают не в вакууме: им необходимо взаимодействовать с руководством, чтобы не отклоняться от целей компании, а также с разработчиками, чтобы реализовывать свои идеи, и с командами по маркетингу и продажам, чтобы продвигать новые возможности. Когда у вас лишь пара команд с иным подходом, остальная часть организации может подстроиться. Но по мере роста то, с чем раньше можно было справиться, превращается в хаос.
Вот что делает этот переломный момент особенно интересным: он часто является результатом успеха, а не неудачи. Все ваши команды по продукту добиваются успеха по-своему: одни сосредоточены на удовлетворении потребностей клиентов посредством совместной работы над дизайном и повышения удобства использования, другие — на стабильности платформы и производительности системы. Каждая команда работает по-своему и использует подходящие ей процессы. Но без целостной системы, которая все это объединит, такой успех становится непостоянным.
Решение двумя крайностями
В ходе бесчисленных бесед с клиентами мне встречались две распространенных попытки решить проблему координации команд по продукту. Некоторые организации пытаются добиться полной стандартизации, заставляя все команды использовать одинаковые процессы, шаблоны и инструменты. Другие же даруют командам полную независимость и надеются, что все получится.
Такие крайности ни к чему хорошему не приводят. Один из ответственных за операции по продуктам рассказывал: «Когда мы заставили все команды работать одинаково, мы добились соответствия требованиям, но без вовлеченности. Команды все делали как надо, но потеряли энтузиазм». С другой стороны, полная автономность приводила к раздробленности и неэффективности. Команды по продукту не могли эффективно обмениваться знаниями, у заинтересованных сторон не было общей картины, а возможности для совместной работы упускались.
Три составляющих идеального баланса
Наиболее успешные организации решают эту задачу, используя три ключевых элемента, которые обеспечивают баланс без ущерба для автономии.
На первом месте общий язык — единые способы обсуждать цели, этапы разработки и трудозатраты, которые позволят наладить общение без строгого регулирования. Затем они создают последовательные визуализации, благодаря которым команды могут работать по-своему, а заинтересованные стороны получают нужную им ясность. Наконец, организации внедряют передовые практики, сочетая культуру, гибкие платформы и вспомогательные инструменты.
В этой статье мы рассмотрим, как эти элементы сочетаются и создают идеальный баланс между автономностью команды и организационной ясностью. Вы увидите конкретные примеры того, как разные команды по продукту — от тех, кто специализируется на функциях для клиентов, до тех, кто работает над возможностями платформы — могут сохранить свой уникальный подход, в то же время внося свой вклад в достижение общей цели.
Создание общего языка
Командам по продукту важно понимать, что им не обязательно работать одинаково — им просто нужно говорить на одном языке. Работая с клиентами, мы определили три ключевых элемента, создающих взаимопонимание без ущерба для автономии команды.
Общие цели команд
Возьмем, к примеру, одного из наших клиентов, который поставил перед собой общекорпоративную цель повысить уровень удовлетворенности клиентов до 80 %. Команды по продукту подошли к этой цели совершенно по-разному в зависимости от контекста.
- Одна команда сосредоточилась на сокращении количества нажатий, необходимых для выполнения частых действий.
- Другая команда сосредоточилась на повышении надежности системы и сокращении времени простоя.
- Третья команда отдала приоритет точности результатов поиска.
Здесь единая цель и разные подходы, но все понимали, как их работа влияет на общую картину.
Вносящие ясность этапы
Вместо того чтобы загонять команды в жесткие рамки, успешные организации стандартизируют контрольные точки. Компания Atlassian выявила четыре ключевых этапа работы различных команд по продукту.
- Размышление: полное понимание решаемого вопроса.
- Изучение: поиск и утверждение решения.
- Создание: внедрение функции в разных регионах.
- Влияние: измерение результатов через 3 месяца.
Когда команда по продукту заявляет, что находится на этапе изучения, все понимают, что это значит: она уже разобралась в проблеме и ищет решения. Но как она дошла до этого этапа? Это зависит от конкретной команды.
Осмысленная оценка трудозатрат
Третий элемент представляет собой общую структуру для измерения трудозатрат. Это не значит, что работа всех команд должна оцениваться одинаково, однако оценки необходимо переводить на общий язык. Команды по разработке платформы могут учитывать сложность системы и риски развертывания, в то время как другие команды по продукту будут уделять особое внимание сложности взаимодействия с пользователями. Но и те, и другие могут представлять эти оценки в понятном для всех виде.
Лучше один раз увидеть
Хотите взглянуть на пример объединения этих трех элементов? Посмотрите мой вебинар о том, как в операциях по продуктам найти баланс между автономностью и согласованностью. Там я привожу практический пример того, как две команды могут работать совершенно по-разному для достижения одной и той же цели.
Project management
Keeping multiple product initiatives on track is no small feat. The product operations manager supports product managers by coordinating complex projects and timelines, tracking progress against product roadmaps, and managing the countless dependencies between teams. They anticipate potential roadblocks and clear the path for on-time delivery.
Создание последовательных визуализаций
Когда общий язык утвержден, наступает пора сделать работу всей организации наглядной. На этом этапе многие команды по продукту сталкиваются со знакомой проблемой: ежеквартальным составлением дорожной карты.
Это частая ситуация. Команды по продукту часами разрабатывают дорожные карты (при этом все используют удобный для себя формат). Одни создают подробные электронные таблицы, поскольку отслеживают сложные зависимости. Другие предпочитают презентации для заинтересованных сторон. Третьи вовсе ведут свои дорожные карты в рамках инструментов для разработки, чтобы держать их поближе к основным задачам.
What businesses need product operations?
И что в итоге? Перед ответственными за операции по продуктам встает непосильная задача. Им нужно просить каждую команду воссоздать дорожные карты в стандартизированном формате (что отнимает много времени и чревато ошибками) либо пытаться объединить разные форматы самостоятельно (что отнимает еще больше времени и тоже чревато ошибками).
Решение в том, чтобы не заставлять всех использовать один и тот же инструмент, а создать подход к визуализации, который будет удобен как командам по продукту, так и заинтересованным сторонам. Вот как это делают успешные организации.
Визуализация на месте
Вместо того чтобы копировать информацию между инструментами, ведущие организации визуализируют данные прямо там, где они хранятся. Например, одна команда по продукту может предпочесть представление доски, организованное по этапам разработки, а другая — представление хронологии для управления сложными зависимостями. Каждая команда работает по-своему, но заинтересованные стороны могут получить единую дорожную карту с согласованной всеми командами информацией о целях, этапах и сроках. Больше не нужно дробить данные по разным инструментам и везде обновлять их вручную.
Общие элементы, разные представления
Успех последовательной визуализации начинается с понимания вашей аудитории. В то время как команды по продукту нуждаются в подробной информации для повседневной работы, заинтересованные стороны обычно сосредотачиваются на небольшом наборе важных показателей, которые помогают им понимать прогресс и принимать решения. Обычно все сводится к следующим важным элементам.
- Цели, достижению которых способствует работа, — чтобы руководство могло отслеживать прогресс в достижении целей компании.
- Текущий этап разработки (размышление, изучение, создание, влияние) — дает четкое представление о прогрессе и следующих шагах.
- Ожидаемые сроки реализации — для улучшения координации между командами и внешними заинтересованными сторонами.
