В предыдущей главе вы познакомились с двумя основными типами продуктовых команд и с тем, как платформенные команды создают максимальные возможности для команд по работе с клиентским опытом и инкапсулируют сложность.
Платформенные команды расширяют возможности для других команд путем абстрагирования от скрытой сложности сервисов и архитектуры.
Тема расширения полномочий платформенных команд не очень проста. Причина в том, что если целью команд по работе с клиентским опытом является решение проблем для пользователей и клиентов, то цель платформенной команды — предоставить возможности команде по работе с клиентами для более эффективного решения проблем для своих клиентов. Таким образом, их вклад носит опосредованный характер.
Чтобы понять, как это влияет на платформенные команды, можно разделить два вида работы, которую должны выполнять все продуктовые команды — как платформенные, так и команды по работе с клиентским опытом.
С одной стороны, цели своей команды они ставят на первый план. Это их главная задача, и мы вскоре вернемся к ней.
Однако каждая продуктовая команда также имеет некоторый объем работы, которую мы называем поддерживающими обязательствами, позволяющими, фигурально выражаясь, держаться на плаву[38].
Это — повседневная работа, необходимая для стабильной деятельности компании, которая поддерживает работоспособность продуктов и услуг. Она предполагает устранение критических ошибок, в том числе проблем производительности и использования дополнительных усилий для решения вопросов, которыми нельзя пожертвовать, таких как соблюдение законодательных норм и правил.
Нужно отметить, что платформенные команды обычно имеют больше таких обязанностей, чем средняя команда по работе с клиентским опытом, что объясняется характером работы — обеспечением деятельности команд, которые от них зависят. Это может составлять 10% рабочих обязанностей платформенной команды или доходить до половины объема работ.
Таким образом, если отделить эту обязанность от всего остального, то будет два способа, которые дают платформенным командам возможность продвигать платформу: это общие командные цели и цели платформы как продукта.
Наиболее распространенный способ, используемый сильной платформенной командой для выполнения основной работы, основан на общих целях команд. Это означает, что платформенная команда имеет те же цели, что и команды по работе с клиентским опытом.
Мы обсудим механизм действия общих целей команд в главе 57 («Сотрудничество»), а пока достаточно сказать, что команды ведут совместную работу по исследованию продукта и разработке решения.
В некоторых случаях команды должны работать в очень тесном сотрудничестве, практически как одна команда.
Например, возьмем такой продукт, как система управления контентом (Сontent Management System — CMS). У вас есть платформенная команда, которая управляет внутренним хранилищем и API-доступом к контенту, и команда работы с клиентским опытом, которая управляет рабочим процессом с контентом, ориентированным на пользователя. Допустим, что вплоть до настоящего момента система CMS работала с графическим контентом, но появилась новая стратегия расширения рынка, и теперь она должна поддерживать видеоконтент.
В этом случае платформенная команда и команда по работе с клиентским опытом имеют общую командную цель — предоставить возможность просмотра видеоконтента. Обе команды должны работать в тесном сотрудничестве, чтобы определиться с соответствующим пользовательским опытом, а также с тем, как он будет реализован.
В иных случаях сотрудничество может быть более сегментарным. Платформенная команда и команда по работе с клиентским опытом могут определить API (программный интерфейс приложения), который согласован обеими командами, а затем каждая команда сможет работать в значительной степени независимо до завершения проекта.
Или, например, компания, работающая в сфере электронной коммерции, может ввести новый способ оплаты. Платформенная команда борется со сложностью платежей и предоставляет решение команде по работе с клиентским опытом в виде API. Продуктовая команда, ответственная за опыт оформления заказа, создает диаграммы пользовательского пути, тогда как платформенная команда осуществляет интеграцию с внутренними платежными процессами. Обе команды вместе тестируют и завершают разработку продукта.
Вне зависимости от того, тесно или нет команды взаимодействуют, важно отметить, что обе они имеют одни и те же стратегический контекст и цель. Они объединены пониманием того, почему их работа важна и что она значит для бизнеса.
Для некоторых компаний их продукты и являются платформами. Они продают API, которые позволяют клиентам и пользователям (обычно разработчикам) создавать свои продукты, используя эти возможности. Мы называем такие платформы внешними.
В этом случае платформа сама по себе является продуктом и рассматривается именно в данном качестве. Клиенты и пользователи могут быть скорее разработчиками, нежели потребителями, но тем не менее это все равно настоящий продукт.
В связи с этим нужно отметить тенденцию к росту количества компаний, которые пытаются управлять своими внутренними платформами в большей степени как внешними платформенными продуктами.
Цели создания платформенных продуктов в значительной мере схожи с целями создания продуктов клиентского опыта: увеличить количество клиентов, убедить клиентов принять возможности продукта, лучше монетизировать клиентов (в случае внешних платформ).
Как с любой продуктовой командой, при наличии серьезной проблемы качества, или проблемы производительности, или проблемы опыта разработчика, можно поднять эти проблемы до уровня командных целей, а не рассматривать их как часть нормальной работы из категории «держаться на плаву».
Таким образом, когда речь идет о расширении полномочий платформенных команд, если мысленно отделить обычную работу, чтобы держаться на плаву, от основной работы по продвижению платформы, то командные цели и уровень полномочий будут сопоставимы с целями и полномочиями команд по работе с клиентским опытом.