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

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

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

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

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

Для определения объема ответственности команды я использую термин «топология команд»[37]. Мне нравится этот термин, так как он отражает идею организации составляющих частей в рамках более масштабной системы.

Топология команд в продуктовой организации отвечает на следующие вопросы:

• Сколько продуктовых команд должно быть в нашей организации?

• Каков объем ответственности у каждой команды?

• Какие навыки требуются для каждой команды и в каком объеме?

• Какова степень взаимных зависимостей между командами?

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

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

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

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

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

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

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

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

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

Глава 41. Оптимизация для расширения полномочий

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

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

Тем не менее многие компании на уделяют этому решению того внимания, которого оно заслуживает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласование — это то, насколько хорошо границы между командами коррелируют с другими аспектами стратегического контекста.

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

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

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

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

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

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

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

Мы рассмотрим тему согласования подробнее в следующих главах.

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

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

Глава 42. Типы команд

SVPG имела возможность проводить консультации для сотен технологических компаний по вопросу топологии команд.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 44. Расширение полномочий команд по работе с клиентами

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

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

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

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

Вот несколько примеров такой согласованности:

• по типу пользователя или его имиджу (например, «команда гонщиков», «команда водителей»);

• сегменту рынка (например, «команда по электронике», «команда модельеров»);

• клиентскому пути (например, «команда по адаптации», «команда по удержанию персонала»);

• каналам продаж (например, «команда самообслуживания», «команда прямых продаж»);

• ключевым показателям эффективности бизнеса, KPI (например, «команда по привлечению новых пользователей», «команда по конверсии»);

• географическому положению (например, «команда Северо-Американского региона», «команда Азиатско-Тихоокеанского региона»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 45. Топология и близость

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

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

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

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

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

Однако существует и очень эффективное компромиссное решение — удаленные офисы.

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

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

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

Близость к команде

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

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

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

Близость к клиентам

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

Близость к бизнес-партнерам

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

Близость к менеджерам

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

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

Близость к другим продуктовым командам

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

Близость к топ-менеджменту

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

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

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

Вот две частые ситуации, когда компромиссы оказываются полезными.

Нужно выбрать, что лучше: менеджеры по продукту и дизайнеры находятся в штаб-квартире компании (рядом с руководителями, топ-менеджментом и стейкхолдерами) или вместе со своими инженерами. Следуя принципу оптимизации в интересах продуктовой команды, мы бы предпочли второй вариант.

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

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

Глава 46. Эволюция топологий

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

У стартапов необходимость в топологии обычно появляется, когда число инженеров превышает 15 человек или около того.

Именно в этот момент в компании возникает понимание, что широкие полномочия и самостоятельность, которыми пользовались сотрудники в период становления, начинают страдать под бременем координации их деятельности. Принимать решения и выполнять простые задачи становится все труднее и труднее. Поэтому принимается решение сформировать три кросс-функциональные продуктовые команды, чтобы «разделять и властвовать». Способ, каким это делается, и определяет топологию.

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

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

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

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

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

• Новая стратегия включает сворачивание продукта, выпуск которого поддерживается в настоящее время несколькими продуктовыми командами.

• Новая стратегия предоставляет доступ к некоторым ключевым возможностям одной продуктовой команды другим командам посредством внутренней платформы.

• Новая цель бизнеса — разработать предложение для расширения рынка.

• Масштабный рефакторинг архитектуры ПО.

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

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

• Вы постоянно перебрасываете разработчиков из одной команды в другую.

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

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

• Команды обладают слишком ограниченным объемом ответственности.

• Разработчики должны иметь дело со слишком большим количеством сложности во многих областях.

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

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

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

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

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

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

Глава 47. Профиль лидера: Дебби Мередит

Я впервые встретил Дебби в компании Netscape, где она руководила инжиниринговой организацией, отвечающей за Netscape Browser. Она пришла в Netscape в результате приобретения платформы Collabra в 1995 году. Возможно, вы ничего не слышали о Collabra, но это была необыкновенная команда с очень сильными лидерами, которые быстро стали играть ключевую роль в беспрецедентном росте компании Netscape.

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

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

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

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

Я видел, как обстояли дела до ее вмешательства и после, и, должен отметить, перемены были разительны.

Я попросил Дебби рассказать, каким образом ей удается с подобным постоянством трансформировать инжиниринговые организации.

Вот как она говорит об этом:

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

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

Все начинается сверху

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

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

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

Фокус внимания и стратегия

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

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

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

Установление доверия

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

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

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

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

Выполнение обещаний

Мне приходится добиваться от инженеров понимания того, что, давая какое-либо обещание или обязательство, они должны непременно его выполнить.

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

Из этого следуют два аспекта.

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

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

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

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