Текст книги "Создающие ценность. Как превратить команду в экспертов, которые меняют рынок"
Автор книги: Крис Джонс
Соавторы: Марти Каган
Жанр:
Экономика
сообщить о нарушении
Текущая страница: 17 (всего у книги 28 страниц)
Глава 42. Типы команд
SVPG имела возможность проводить консультации для сотен технологических компаний по вопросу топологии команд.
Когда дело касается топологии, каждая ситуация уникальна. Тем не менее уже наработаны неплохие практики, которые помогут оптимизировать вашу топологию для расширения полномочий команд.
В этой главе мы рассмотрим два основных типа продуктовых команд: платформенные команды, которые управляют сервисами, чтобы их могли легко использовать другие команды, и команды пользовательского опыта, которые отвечают за взаимодействие пользователей и клиентов с продуктом.
Важно подчеркнуть: любая топология должна учитывать как основную технологическую архитектуру, так и общий стратегический контекст продукта (в том числе цели бизнеса, видение продукта, стратегию и т. д.).
Поэтому необходимо, чтобы топологию устанавливали совместно руководители отдела продуктов и инженерной группы.
ПЛАТФОРМЕННЫЕ КОМАНДЫ
Платформенные команды предоставляют полезные возможности для других команд, так как позволяют внедрить общие сервисы один раз, но использовать в разных местах. Например:
• Платформенная команда, отвечающая за совместные сервисы, такие как аутентификация или авторизация.
• Платформенная команда, отвечающая за поддержку библиотеки интерфейсных компонентов многоразового использования.
• Платформенная команда, отвечающая за предоставление разработчикам инструментов для автоматизации тестирования и выпуска продукта.
Платформенные команды также позволяют упрощать процесс, так как могут инкапсулировать особо трудные или специализированные области продукта. Например:
• Платформенная команда, которая создает абстракцию для интеграции с прежней системой.
• Платформенная команда, которая управляет обработкой платежей.
• Платформенная команда, которая управляет расчетом узкоспециализированных налогов.
Ваши конечные клиенты – и даже ваше руководство и стейкхолдеры – могут не иметь непосредственного отношения к работе, выполняемой вашими платформенными командами. Но эти команды все равно важны.
На самом деле во многих ведущих продуктовых организациях лучших инженеров компании просят работать в платформенных командах из-за широких возможностей и значимости для других разработчиков.
В маленьких компаниях платформа может быть создана одной платформенной командой. В ведущих технологических компаниях платформенными командами являются до половины продуктовых команд.
Кроме того, платформы снижают когнитивную нагрузку для команд пользовательского опыта.
Команды пользовательского опыта могут применять сервисы платформы, не вникая в то, как они созданы. Они могут сконцентрировать усилия на проблемах – клиентов или бизнеса, – над решением которых они работают.
КОМАНДЫ ПО РАБОТЕ С ПОЛЬЗОВАТЕЛЬСКИМ ОПЫТОМ
Эти команды несут ответственность за то, как пользователь взаимодействует с продуктом, – при помощи приложений, пользовательских интерфейсов, решений или карт пути пользователя.
Пользователи могут быть клиентами, покупающими ваш продукт, или (в случае бизнес-модели продажи продуктов B2B) сотрудниками этих клиентов. В любом случае, если продуктовая команда работает на опыт всех клиентов компании, включая потребителей, она называется клиентоориентированной командой пользовательского опыта.
Эти пользователи могут быть внутренними по отношению к самой компании, тем не менее они играют важную роль в предоставлении необходимого клиентского опыта.
В качестве примера этого типа пользователей можно привести агентов по обслуживанию клиентов или розничных продавцов. Если специализация продуктовой команды – опыт работы с продуктом для этих видов внутренних сотрудников, то она называется командой поддержки пользовательского опыта.
Вне зависимости от типа хорошая команда пользовательского опыта напрямую влияет на клиентов, если продукт оказывается неудачным. Например, если внутренний агент не может решить проблему или запрос клиента, так как что-то не работает, то мы понимаем, что это и есть подлинный пользовательский опыт.
Как и в случае платформ, опыт работы с продуктом обрабатывается одной командой или работа распределяется между несколькими командами. Например, работу с клиентским опытом можно отдать разным командам по типу пользователей, по рынкам или сегментам, по этапу в карте пути клиента и т. д. (более подробно об этом рассказывается в главе 44 о расширении полномочий команд по работе с клиентским опытом).
Во многих компаниях топология установлена таким образом, что каждая команда по работе с клиентами отвечает лишь за малую часть комплексного взаимодействия с клиентами. В этой ситуации командам приходится прилагать усилия, чтобы почувствовать себя способными что-то изменить, не согласовывая свои решения с другими командами, даже если речь идет о незначительных изменениях.
При этом команды по работе с клиентами чувствуют себя увереннее, когда на них возлагают как можно больше сквозной ответственности. Такие команды обладают осмысленным чувством сопричастности, большей автономией, видят свое влияние на решение проблем клиентов и достижение бизнес-результатов.
Многие успешные компании уже пришли к выводу, что сильная платформа – это эффективный инструмент для расширения объема сквозной ответственности команд по работе с клиентским опытом.
Платформенные команды снижают нагрузку, связанную с использованием базисной технологии, создавая когнитивные возможности для того, чтобы команды по работе с клиентами могли брать на себя ответственность за большее количество аспектов клиентских проблем.
Глава 43. Расширение полномочий платформенных команд
В предыдущей главе вы познакомились с двумя основными типами продуктовых команд и с тем, как платформенные команды создают максимальные возможности для команд по работе с клиентским опытом и инкапсулируют сложность.
Платформенные команды расширяют возможности для других команд путем абстрагирования от скрытой сложности сервисов и архитектуры.
Тема расширения полномочий платформенных команд не очень проста. Причина в том, что если целью команд по работе с клиентским опытом является решение проблем для пользователей и клиентов, то цель платформенной команды – предоставить возможности команде по работе с клиентами для более эффективного решения проблем для своих клиентов. Таким образом, их вклад носит опосредованный характер.
Чтобы понять, как это влияет на платформенные команды, можно разделить два вида работы, которую должны выполнять все продуктовые команды – как платформенные, так и команды по работе с клиентским опытом.
С одной стороны, цели своей команды они ставят на первый план. Это их главная задача, и мы вскоре вернемся к ней.
Однако каждая продуктовая команда также имеет некоторый объем работы, которую мы называем поддерживающими обязательствами, позволяющими, фигурально выражаясь, держаться на плаву[38]38
Некоторые компании используют термин «бизнес как обычно», но мне он никогда не нравился, так как слишком много компаний считают, что продуктовая команда именно этим и занимается.
[Закрыть].
Это – повседневная работа, необходимая для стабильной деятельности компании, которая поддерживает работоспособность продуктов и услуг. Она предполагает устранение критических ошибок, в том числе проблем производительности и использования дополнительных усилий для решения вопросов, которыми нельзя пожертвовать, таких как соблюдение законодательных норм и правил.
Нужно отметить, что платформенные команды обычно имеют больше таких обязанностей, чем средняя команда по работе с клиентским опытом, что объясняется характером работы – обеспечением деятельности команд, которые от них зависят. Это может составлять 10% рабочих обязанностей платформенной команды или доходить до половины объема работ.
Таким образом, если отделить эту обязанность от всего остального, то будет два способа, которые дают платформенным командам возможность продвигать платформу: это общие командные цели и цели платформы как продукта.
ОБЩИЕ КОМАНДНЫЕ ЦЕЛИ
Наиболее распространенный способ, используемый сильной платформенной командой для выполнения основной работы, основан на общих целях команд. Это означает, что платформенная команда имеет те же цели, что и команды по работе с клиентским опытом.
Мы обсудим механизм действия общих целей команд в главе 57 («Сотрудничество»), а пока достаточно сказать, что команды ведут совместную работу по исследованию продукта и разработке решения.
В некоторых случаях команды должны работать в очень тесном сотрудничестве, практически как одна команда.
Например, возьмем такой продукт, как система управления контентом (Сontent Management System – CMS). У вас есть платформенная команда, которая управляет внутренним хранилищем и API-доступом к контенту, и команда работы с клиентским опытом, которая управляет рабочим процессом с контентом, ориентированным на пользователя. Допустим, что вплоть до настоящего момента система CMS работала с графическим контентом, но появилась новая стратегия расширения рынка, и теперь она должна поддерживать видеоконтент.
В этом случае платформенная команда и команда по работе с клиентским опытом имеют общую командную цель – предоставить возможность просмотра видеоконтента. Обе команды должны работать в тесном сотрудничестве, чтобы определиться с соответствующим пользовательским опытом, а также с тем, как он будет реализован.
В иных случаях сотрудничество может быть более сегментарным. Платформенная команда и команда по работе с клиентским опытом могут определить API (программный интерфейс приложения), который согласован обеими командами, а затем каждая команда сможет работать в значительной степени независимо до завершения проекта.
Или, например, компания, работающая в сфере электронной коммерции, может ввести новый способ оплаты. Платформенная команда борется со сложностью платежей и предоставляет решение команде по работе с клиентским опытом в виде API. Продуктовая команда, ответственная за опыт оформления заказа, создает диаграммы пользовательского пути, тогда как платформенная команда осуществляет интеграцию с внутренними платежными процессами. Обе команды вместе тестируют и завершают разработку продукта.
Вне зависимости от того, тесно или нет команды взаимодействуют, важно отметить, что обе они имеют одни и те же стратегический контекст и цель. Они объединены пониманием того, почему их работа важна и что она значит для бизнеса.
ЦЕЛИ ПЛАТФОРМЫ КАК ПРОДУКТА
Для некоторых компаний их продукты и являются платформами. Они продают API, которые позволяют клиентам и пользователям (обычно разработчикам) создавать свои продукты, используя эти возможности. Мы называем такие платформы внешними.
В этом случае платформа сама по себе является продуктом и рассматривается именно в данном качестве. Клиенты и пользователи могут быть скорее разработчиками, нежели потребителями, но тем не менее это все равно настоящий продукт.
В связи с этим нужно отметить тенденцию к росту количества компаний, которые пытаются управлять своими внутренними платформами в большей степени как внешними платформенными продуктами.
Цели создания платформенных продуктов в значительной мере схожи с целями создания продуктов клиентского опыта: увеличить количество клиентов, убедить клиентов принять возможности продукта, лучше монетизировать клиентов (в случае внешних платформ).
Как с любой продуктовой командой, при наличии серьезной проблемы качества, или проблемы производительности, или проблемы опыта разработчика, можно поднять эти проблемы до уровня командных целей, а не рассматривать их как часть нормальной работы из категории «держаться на плаву».
Таким образом, когда речь идет о расширении полномочий платформенных команд, если мысленно отделить обычную работу, чтобы держаться на плаву, от основной работы по продвижению платформы, то командные цели и уровень полномочий будут сопоставимы с целями и полномочиями команд по работе с клиентским опытом.
Глава 44. Расширение полномочий команд по работе с клиентами
Как уже было отмечено выше, команды по работе с клиентским опытом отвечают за то, как ценность продукта воспринимается фактическими пользователями или клиентами.
Ключевой момент в том, что эти команды получают самые широкие полномочия в тот момент, когда на них возлагается как можно больше сквозной ответственности.
Чаще это происходит, когда объем ответственности каждой команды соответствует другим естественным структурам бизнеса, таким как каналы продаж, сегменты рынка или типы пользователей.
В большинстве случаев это означает создание топологии, согласованной с потребностями клиента.
Вот несколько примеров такой согласованности:
• по типу пользователя или его имиджу (например, «команда гонщиков», «команда водителей»);
• сегменту рынка (например, «команда по электронике», «команда модельеров»);
• клиентскому пути (например, «команда по адаптации», «команда по удержанию персонала»);
• каналам продаж (например, «команда самообслуживания», «команда прямых продаж»);
• ключевым показателям эффективности бизнеса, KPI (например, «команда по привлечению новых пользователей», «команда по конверсии»);
• географическому положению (например, «команда Северо-Американского региона», «команда Азиатско-Тихоокеанского региона»).
Эта согласованность не означает, что у команд по работе с клиентским опытом есть сферы приложения сил, соответствующие конечным результатам, которые нужны бизнесу. Между бизнес-результатами и работой над продуктом практически не требуется соответствия, и командам может быть предоставлена автономия, чтобы напрямую решать проблемы бизнеса.
Согласованность с клиентом для разных типов продуктов означает разное. Далее приведено несколько примеров согласованности. Этот список ни в коем случае нельзя считать исчерпывающим, и это не единственные возможные способы организации топологии команд по работе с клиентским опытом для данных ситуаций. Тем не менее есть определенные общие модели, которые доказали свою эффективность и их можно применять для создания вашей собственной топологии.
МЕДИАПРОДУКТ
Для журналов, новостных сайтов или стриминговых сервисов команды по работе с клиентским опытом можно организовать на основе рубрикации контента.
Управлением и общими возможностям контента занимаются платформенные команды, которые предоставляют общие сервисы ряду команд по работе с клиентским опытом (могут составлять большую часть персонала, работающего над продуктом).
Каждая команда по работе с клиентским опытом охватывает комплексные потребности каждой медийной категории (спорт, местные новости, погода) или бренда. В некоторых случаях одна команда может охватить несколько аналогичных категорий, а более широкие или узкоспециализированные категории опыта потребуют отдельных команд.
Такой подход помогает добиться удовлетворения потребностей разных типов клиентов. Кроме того, он способствует согласованности работы команды клиентского опыта с разными бизнес-целями в каждой категории и стратегиями вывода продукта на рынок, которые в таких компаниях обычно общие.
ПРОДУКТЫ ЭЛЕКТРОННОЙ КОММЕРЦИИ
Электронная коммерция может строиться по модели, аналогичной модели медиапродукта, особенно если опыт совершения покупок существенно различается в зависимости от категории (автозапчасти, билеты на концерты, ювелирные украшения).
И здесь продукт тоже создается на большой платформе общих сервисов (управление каталогом, биллинг, управление учетными записями и т. д.). Команды по работе с клиентским опытом распределяются по категориям.
КОРПОРАТИВНЫЙ ПРОДУКТ
Корпоративные продукты часто должны быть подогнаны под потребности клиентов из разных сегментов. В одних случаях различия обусловлены вертикальным рынком клиентов (промышленное производство, финансовые услуги, розничная торговля). В других случаях различия, и весьма существенные, основаны на стратегии вывода продукта на рынок. Иногда они вызваны размером компании клиента (например, с компаниями из сегментов малого и среднего бизнеса можно связаться через портал самообслуживания, тогда как для более крупных клиентов требуются торговый персонал и API для кастомизации продукта с учетом их потребностей).
Здесь целесообразны команды по работе с клиентским опытом на основе любой сегментации, связанной с деятельностью компании. Цель – организовать команды таким образом, чтобы дать им возможность предоставить оптимальное обслуживание конкретному клиенту, а также увязать свою работу с другими частями компании.
ПРОДУКТЫ ДЛЯ МАРКЕТПЛЕЙСОВ
Многие продукты имеют цель соединить разные группы людей с взаимодополняющими целями, например продавцов и покупателей, водителей и пассажиров, владельцев отелей и гостей. Большинство маркетплейсов – двухсторонние, но сторон может быть и больше.
В основном потребности людей по разные стороны маркетплейса не совпадают. Это относится и к остальному бизнесу, который старается поддерживать и ту и другую стороны.
В силу этих причин расширяются возможности для топологии, для организации команды по работе с клиентским опытом в зависимости от стороны, занимаемой на маркетплейсе.
ПРОДУКТЫ ДЛЯ ПОДДЕРЖКИ КЛИЕНТОВ
Продуктовая команда по поддержке клиентов создает инструменты и системы, которые используются сотрудниками внутри компании, обеспечивающими довольно значительную часть клиентского опыта.
Среди них могут быть, к примеру, системы для расширения возможностей службы поддержки клиентов или непосредственных работников магазина.
В этом случае топология может дать командам по работе с клиентским опытом более широкие полномочия, согласуя их с комплексными потребностями пользователей внутри компании.
И последнее: ваша топология не обязательно должна организовывать все команды по работе с клиентским опытом в соответствии с одним параметром, таким как вертикальный рынок или размер компании клиента. Некоторые топологии используют разные параметры согласованности в разных областях, если так лучше для дела.
Топология и дизайн
Большинство компаний понимают, что кросс-функциональная продуктовая команда – по крайней мере, для команды по работе с клиентами – должна иметь предметно-ориентированного продуктового дизайнера. Это свидетельствует о признании значимости продуктового дизайна для создания высококачественного продукта.
Однако в некоторых случаях руководитель по продуктовому дизайну компании предпочитает другую модель, которая называется моделью внутреннего агентства. В этом случае у руководителя есть сервисная команда дизайнеров, и продуктовые команды должны обращаться к ней с просьбой о создании дизайна для их продуктов.
Будет справедливо признать, что у этого подхода есть ряд определенных преимуществ, особенно в плане обеспечения целостного взгляда на дизайн.
Однако, как говорится, «нужно быть среди тех, кто принимает ключевые решения».
Модель внутреннего агентства не предполагает, чтобы дизайнер делал именно так, и, следовательно, дизайнеру – а в итоге и нашим пользователям – приходится за это расплачиваться.
Дизайн продукта слишком важная вещь, чтобы рассматривать его как задачу внутреннего поставщика услуги. Дизайнер должен быть полноправным членом продуктовой команды первого ряда, таким же, как менеджер по продукту и техлид.
Менеджер по дизайну может обеспечить целостный подход к дизайну продукта, устанавливая стандарты дизайна, его правила и системы, проверяя работу дизайнеров, а также реализуя стратегию дизайна и проводя обзорные сессии с более широкой группой продуктовых дизайнеров.
Обратите внимание: для компаний, где используются функциональные команды, это, по сути, не имеет значения, поскольку ключевые решения принимаются до того, как происходят первые консультации с дизайнером.
Топология и структура подчинения
Структура подчинения инженерного персонала чаще всего строится на основе конкретных наборов навыков. Например, группы инженеров по обработке данных, фронтенд-инженеров и мобильных инженеров, как правило, подчиняются разным менеджерам. Благодаря такой системе любой менеджер по инжинирингу может проводить специализированный коучинг для каждого инженера в своей команде.
Это не является большой проблемой, но руководители технологических компаний могут поддаться искушению полностью выстроить продуктовые команды в соответствии с подобной структурой подчинения. Например, создать отдельную команду только из фронтенд-инженеров.
Такой подход редко приводит к созданию продуктовых команд с расширенными полномочиями, поскольку команды не связаны ничем, кроме набора технических навыков, что редко оказывает влияние на конечные результаты, нужные бизнесу.
Например, при топологии, которая делит организацию на веб-команду, iOS-команду, команду Android и бэкенд-команду, очень трудно предоставить любой из них возможность отвечать за многоканальное обслуживание клиентов.
Знаменитый программист Мелвин Конвей придумал то, что часто называют «законом Конвея». Он гласит, что «любая организация, проектирующая системы, неизменно создает проекты, копирующие коммуникационную структуру этой организации».
Можно сформулировать это иначе: будьте внимательны, не рассылайте потребителям схему вашей оргструктуры.
Одно из преимуществ кросс-функциональных команд в том, что участие в них определяется тем, что будет полезней для продукта.
Подведем итог: нет никаких оснований утверждать, что схема подчинения должна диктовать топологию команд.
