Марти Каган – Вдохновленные. Все, что нужно знать продакт-менеджеру (страница 4)

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

Глава 5. Корпорации: непрерывные продуктовые инновации

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

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

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

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

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

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

А еще в компании постоянно ведутся разговоры о том, как же так получается, что такие крупные корпорации, как Adobe, Amazon, Apple, Facebook, Google и Netflix, смогли избежать этой печальной участи. Руководство ломает голову над вопросом, почему же им не удается сделать то же самое. Но факт остается фактом: они смогли. И чтобы и мы смогли, нужно внести серьезные изменения, о которых и рассказывается в этой книге.

Глава 6. Фундаментальные причины неудач в работе над продуктом

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

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

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

Рис. 6.1. Основные этапы создания продукта

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

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

Для этого в компании обычно проводится ежеквартальное или ежегодное совещание по планированию; на нем руководство рассматривает и оценивает идеи и обсуждает дорожную карту продукта. Но чтобы определить приоритетность идей, нужна оценка каждой из них в той или иной форме. В одних компаниях приняты формальные процедуры, в других – неофициальные; как бы там ни было, все сводится к необходимости ответить на два вопроса относительно каждой идеи: сколько денег она принесет или какую ценность обеспечит? Сколько денег или времени уйдет на ее реализацию? Далее эта информация используется для составления дорожной карты, обычно на следующий квартал, но иногда и на целый год.

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

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

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

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

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

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

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