Читать книгу Бизнес-трансформация. Как перестроить традиционную модель по законам Кремниевой долины - Марти Каган - Страница 10

Существует много негативных образов, связанных с трансформацией.

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

Один из вопросов, который мы слышим довольно часто: «Что такого наша компания сможет сделать после трансформации, чего мы не могли сделать раньше?»

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

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

Итак, предположим, что руководители компании искренне считают, что им необходима трансформация. Что это значит на самом деле?

Многие из вас слышали такие слова: «Хотя переход на “гибкую методику” Agile необходим, но его недостаточно».

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

Или: «Цель – превратиться в компанию, ориентированную на продукт».

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

Поэтому в этой книге мы используем другой подход.

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

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

1. Изменение подхода к разработке.

2. Изменение алгоритма решения проблем.

3. Изменение подхода к определению приоритетов.

МЕНЯЕМ ПОДХОД К РАЗРАБОТКЕ

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

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

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

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

Если вы не применяете практики непрерывной разработки и внедрения, то как минимум следует выпускать настоящие релизы[4] не реже чем раз в две недели.

МЕНЯЕМ АЛГОРИТМ РЕШЕНИЯ ПРОБЛЕМ

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

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

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

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

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

МЕНЯЕМ ПОДХОД К ОПРЕДЕЛЕНИЮ ПРИОРИТЕТОВ

Когда ваши сотрудники овладевают навыками исследования продукта, чтобы стабильно и оперативно решать сложные проблемы на радость клиентам и одновременно на пользу бизнесу, – это скачок в развитии компании, по любым меркам. Но возникает вопрос: «А как вы определили, что это и есть главная проблема, которую нужно решить?»

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

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

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

Несколько важных замечаний.

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

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

Итак, поведем итог.

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

• Изменение алгоритма решения проблем означает отказ от «дорожных карт» и команд по разработке функций, подчиненных стейкхолдерам, и переход к командам по разработке продуктов, которым дали полномочия самостоятельно решать поставленные задачи, а затем позволили проводить исследование продукта для обнаружения технологических решений, которые будут ценными для пользователей, пригодными для применения, рентабельными и жизнеспособными. Это означает, что вы решаете проблемы как для клиента, так и для вашего бизнеса. Данное изменение – ключ к постоянному улучшению сроков окупаемости.

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

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

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

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