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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инвестиции в технологии – это создание ценности для ваших клиентов и вашей компании.

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

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

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

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

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

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

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