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

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

• Платформенная команда, которая создает абстракцию для интеграции с прежней системой.

• Платформенная команда, которая управляет обработкой платежей.

• Платформенная команда, которая управляет расчетом узкоспециализированных налогов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 43. Расширение полномочий платформенных команд

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

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

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

Чтобы понять, как это влияет на платформенные команды, можно разделить два вида работы, которую должны выполнять все продуктовые команды — как платформенные, так и команды по работе с клиентским опытом.

С одной стороны, цели своей команды они ставят на первый план. Это их главная задача, и мы вскоре вернемся к ней.

Однако каждая продуктовая команда также имеет некоторый объем работы, которую мы называем поддерживающими обязательствами, позволяющими, фигурально выражаясь, держаться на плаву[38].

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

Нужно отметить, что платформенные команды обычно имеют больше таких обязанностей, чем средняя команда по работе с клиентским опытом, что объясняется характером работы — обеспечением деятельности команд, которые от них зависят. Это может составлять 10% рабочих обязанностей платформенной команды или доходить до половины объема работ.

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

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

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

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

Например, возьмем такой продукт, как система управления контентом (Сontent Management System — CMS). У вас есть платформенная команда, которая управляет внутренним хранилищем и API-доступом к контенту, и команда работы с клиентским опытом, которая управляет рабочим процессом с контентом, ориентированным на пользователя. Допустим, что вплоть до настоящего момента система CMS работала с графическим контентом, но появилась новая стратегия расширения рынка, и теперь она должна поддерживать видеоконтент.

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