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

В книге  «Вдохновленные» упомянуты три главные характеристики сильных продуктовых команд, вне зависимости от используемых ими процессов. Первая — раннее устранение рисков, вторая — совместное решение проблем, третья — ответственность за результаты.
Что касается второй характеристики — совместного решения проблем, — то это уже не тот старый каскадный процесс, когда менеджер по продукту определяет требования к продукту и передает их дизайнеру, который должен разработать дизайн, отвечающий этим требованиям, а затем передать его инженерам для реализации концепции продукта.
  
Итак, что именно мы имеем в виду, когда говорим о сотрудничестве?
Начнем с того, чем сотрудничество не является.
Во-первых, сотрудничество не подразумевает достижения консенсуса. Хотя нам удобнее, чтобы продуктовая команда имела единое мнение насчет оптимального образа действий, но мы подобного не ждем и на этом не настаиваем. Скорее мы полагаемся на экспертное мнение каждого члена команды. В целом, если техлид чувствует, что нужно создать какую-то конкретную архитектуру, мы подчиняемся его мнению. Если дизайнер ощущает, что есть потребность в каком-то конкретном пользовательском опыте, мы следуем за дизайнером. Время от времени возникают конфликты из-за противоречивых субъективных решений. В этих случаях мы обычно проводим тестирование, чтобы урегулировать разногласия.
Во-вторых, сотрудничество не подразумевает составление артефактов управления. Многие менеджеры по продукту считают, что их работа предполагает создание некоего документа, который отражает «требования» или, по крайней мере, фиксирует на бумаге пользовательский опыт. Справедливости ради стоит отметить, что в некоторых случаях нам приходится составлять артефакты управления (особенно когда члены команды работают дистанционно), но это, безусловно, не является способом сотрудничества. На самом деле эти артефакты чаще всего мешают реальному сотрудничеству.
Почему так происходит? Как только менеджер по продукту заявляет, что таково «требование», все разговоры обычно прекращаются и дискуссия переходит в плоскость реализации. В этот момент дизайнеру кажется, что он здесь лишь для того, чтобы обеспечивать соответствие дизайна фирменному стилю компании, а инженеру — что он здесь лишь для того, чтобы писать код. Таким образом, мы снова возвращаемся к каскадной модели.
В-третьих, сотрудничество — это не компромисс. Если в итоге вы получаете посредственный пользовательский опыт, низкую производительность, ограниченную масштабируемость и сомнительную ценность для клиентов, значит, вы проиграли как команда.
Нужно найти решение, которое будет работать. Что имеется в виду? Что оно будет представлять ценность (достаточную ценность, чтобы целевые клиенты реально покупали продукт и предпочитали его использовать), окажется удобным в использовании (чтобы пользователи могли ощутить ценность продукта), осуществимым (чтобы мы могли реализовать доставку этой ценности) и жизнеспособным для нашего бизнеса (чтобы остальные подразделения нашей компании могли эффективно вывести наш продукт на рынок, продавать и поддерживать его).
Чтобы добиться этого, мы должны понять пределы нашего знания, согласиться с тем, что нам что-то не известно, и сосредоточить усилия на поисках решения, которое будет работать.
И вот это и требует реального сотрудничества.
Не забывайте, что наша роль в продуктовом бизнесе состоит в решении проблем, которые нас просят решить, теми способами, которые одновременно нравятся нашим клиентам и работают на благо нашего бизнеса. В этом и заключается наша работа как кросс-функциональной команды, наделенной расширенными полномочиями, где каждый участник привносит в общее дело свой вклад с помощью необходимых навыков.
И начинается это с подлинного и тесного сотрудничества между продуктовым менеджментом, дизайнерами по продукту и инжиниринговой группой.
Я предпочитаю такой способ взаимодействия: члены команды собираются вместе, имея на руках прототип (как правило, созданный дизайнером), чтобы сообща рассмотреть и обсудить предложенное решение. Дизайнеры могут обдумывать разные подходы к пользовательскому опыту, инженеры — рассматривать последствия, связанные с разными подходами, и потенциальные возможности прорывных технологий, а менеджеры по продукту — взвешивать эффекты и последствия каждого потенциального направления (например, не будет ли нарушен принцип конфиденциальности, подойдет ли это для реализации по нашему каналу продаж).
Обратите внимание, что на этапе продуктового исследования некоторые инструменты и методы служат как для облегчения совместной работы, так и для создания артефакта в качестве промежуточного результата этого сотрудничества. Два весьма популярных примера — создание прототипа и карты пользовательских историй.
Сам процесс создания и обсуждения прототипов и карт пользовательских историй способствует взаимодействию на основе сотрудничества. Если вы стараетесь актуализировать ваши прототип или карту пользовательских историй, они могут также служить артефактом, который отражает данные, полученные в результате продуктового исследования, и решения, принятые на его основе.
Реальная польза и сама цель использования инструментов в данном случае — укрепление сотрудничества. А получение артефакта в финале можно рассматривать как приятный бонус.
На самом деле главное здесь — не прототип, а само сотрудничество, развитию которого способствует создание прототипа.
Заметьте, что менеджер по продукту и инженеры не пытаются диктовать дизайнеру, как делать свою работу. Также менеджер по продукту и дизайнеры не указывают инженерам, как им делать свою. А дизайнеры и инженеры не указывают менеджеру по продукту, как работать должен он.
Напротив, в здоровой и компетентной команде каждый ее участник рассчитывает, что другие выполнили «домашнее задание» и использовали свои навыки в качестве вклада в общее дело.
Впрочем, не стоит превратно истолковывать все вышеизложенное и полагать, что дизайнеры отвечают исключительно за удобство в использовании, а инженеры — только за осуществимость, поскольку в этом случае вы упускаете истинный смысл сотрудничества.
Часто у дизайнеров бывают озарения, основанные на глубоком понимании потребностей пользователей и их потребительского поведения, которые указывают другой путь решения стоящей перед нами проблемы или меняют сам подход к проблеме. Такие озарения порой оказывают прямое влияние на ценность продукта и косвенное — на такие вещи, как производительность.
Аналогичным образом сильные инженеры обладают глубоким пониманием прорывных технологий, что порой открывает перед нами возможность совершенно другого решения поставленных проблем — и часто гораздо более эффективного, чем могли представить менеджер по продукту, дизайнер и особенно клиент. Если бы мне пришлось выбирать, что мне больше всего нравится в ощущении истинного сотрудничества в продуктовой команде, наделенной широкими полномочиями, я бы выбрал ту магию, которая происходит, когда ваши сотрудники: а) мотивированны и б) грамотны и опытны в своей области — продуктовом менеджменте, дизайне и инжиниринге, — а также способны совместно обсуждать прототип или наблюдать за взаимодействием с ним пользователя. Инженер показывает новые возможности, дизайнер — разные варианты потенциальных пользовательских впечатлений, а менеджер по продукту взвешивает возможные последствия, связанные с продажей, или финансами, или условиями конфиденциальности. И после изучения целого ряда подходов они создают вариант, который действительно работает. Он получается ценным, удобным в использовании, осуществимым и жизнеспособным.
  
Исходя из опыта, могу отметить, что есть две ситуации, когда чаще всего это не срабатывает.
Первая связана с тем, что менеджер по продукту не выполнил свою «домашнюю работу» и не имеет понятия о разных аспектах и ограничениях бизнеса, таких как продажи, маркетинг, финансы, правовые нормы, конфиденциальность и т. п. Поэтому у продуктовой команды нет информации, необходимой для решения порученных ей проблем (что обычно означает возврат к внедрению функций, прописанных в дорожной карте).