Кітаптан алынған дәйексөздер Бизнес-трансформация. Как перестроить традиционную модель по законам Кремниевой долиныавторлар Джон Мур, Марти Каган, Крис Джонс, Кристиан Идиоди, Ли Хикман
ПРОДУКТОВЫЕ КОМАНДЫ
Фундаментальное понятие в продуктовой модели — это концепция расширенной, межфункциональной продуктовой команды. Именно здесь рождаются эффективные инновационные продукты, а большая часть продуктовой модели так или иначе направлена на то, чтобы формировать и подпитывать такие продуктовые команды.
От проектов к продуктам
Разговор о культуре продукта может казаться оторванным от жизни, но она ежедневно влияет на каждого сотрудника. Чтобы попытаться воплотить эти принципы в жизнь, приведем пример очень распространенной ситуации «до и после».
В старых моделях часто все сводилось к тому, чтобы разработать проекты к определенным датам.
Понятно, откуда это берется, ведь от ИТ-отдела постоянно требуют, чтобы конкретные функции и проекты были реализованы как можно быстрее.
Проблема в том, что такой подход игнорирует реалии продукта, работающего на основе технологий.
Проекты — это, как правило, большие, медленные и дорогостоящие попытки получить какой-то результат к определенной дате. Вам приходится решать, насколько большой должна быть команда, и прикидывать, сколько времени займет работа. Затем нужно выбить финансирование, после чего вы неизбежно узнаете, что проект потребует больше сил, чем вы предполагали, а его выполнение превращается в настоящее испытание.
Большинство усилий уже не направлены на создание ценности, а просто призваны получить на выходе хоть какой-то продукт. Затем, когда он наконец-то внедрен, сотрудники не могут проводить циклы отладки и улучшения, потому что чаще всего разбегаются по следующим заданиям. Никто не берет ответственность за результат, и все выводы и инсайты, полученные в ходе работы, скорее всего, будут потеряны.
Здесь сразу несколько негативных явлений:
Обычно требуется несколько последовательных итераций, пока вы не добьетесь необходимых результатов, но полученного финансирования редко хватает более чем на одну попытку. А если и удается возобновить его, то, как правило, на несколько кварталов позднее.
Вам нужно, чтобы люди чувствовали реальную ответственность за технологию и результаты, но, когда сотрудников привлекают только на время проекта, они не чувствуют себя хозяевами данного участка работы и у них мало стимулов для создания чего-то значимого.
В описываемом сценарии речь идет о разработке функций и проектов, о которых просят ключевые специалисты других направлений, вместо того чтобы позволить вашей продуктовой команде, особенно разработчикам, изучить текущие технологические возможности. В результате инновации в проектах — явление крайне редкое.
Поскольку команды создают только то, что им нужно для данного проекта, никто не беспокоится о долгосрочных последствиях этой работы и об оптимизации базовой технологии, отчего быстро накапливается технический долг.
Кто берет на себя ответственность за достижение необходимого результата? Чувство ответственности обычно размазано между несколькими специалистами разных направлений, а в итоге наиболее вероятно, что все стрелки переведут на команду данного проекта и обвинят ее в плохо сделанной работе.
А вот в продуктовой модели вы фокусируетесь на продуктах и результатах.
Продуктовая команда фокусируется на бизнес-результатах, таких как снижение уровня оттока, ускорение роста или любые другие KPI, соответствующие вашей ситуации, и она же постоянно работае
ПРИНЦИП: «ОБУЧЕНИЕ ЧЕРЕЗ НЕУДАЧУ»
Во многих компаниях глубоко укоренился страх перед неудачей. Этот страх заставляет людей выстраивать процессы так, чтобы избегать риска, из-за чего теряется способность реагировать на меняющиеся потребности рынка и новые технологии.
Хотя мы ни в коем случае не прославляем ошибки и провалы, основное внимание должно быть направлено на работу с рисками и быстрое обучение. Когда вы проводите эксперимент в рамках исследования продукта, нет такого понятия, как успех или провал. Есть только вопрос: «Чему мы научились?»
Ваша цель — узнать, что в процессе поиска продукта работает, а что нет, при этом затраты и время значительно сокращаются, а риск снижается. Таким образом, когда вы начнете тратить время и средства на разработку продукта, у вас будут доказательства и уверенность в том, что продукт не окажется провальным.
ПРИНЦИП: «ИННОВАЦИИ ПРЕВЫШЕ ПРЕДСКАЗУЕМОСТИ»
Во многих компаниях первопричина отсутствия инноваций совершенно очевидна. Они построили свою организацию и методы работы на основе такой цели, как предсказуемость. Они просто сосредоточились на том, чтобы каждый квартал выпускать побольше функций.
Не то чтобы они намеренно отказывались от цели инноваций, но, как говорит бизнес-тренер Хенрик Книберг, «100% предсказуемости = 0% инноваций».
ПРИНЦИП: «ДОВЕРИЕ ПРЕВЫШЕ КОНТРОЛЯ»
Переход от командно-административной к продуктовой модели — это не только изменение компетенций и понятий, но и фундаментальное изменение культуры.
Для многих топ-менеджеров, особенно тех, кто строил свою карьеру на модели управления «сверху вниз», это большой скачок в развитии. Новая модель основана на доверии, а не на контроле.
Полезно осознать, что именно это является ключевым изменением.
Непрерывное совершенствование процессов
Еще один способ гарантии, что в вашей компании принципы, обсуждаемые здесь, будут стабильно важнее любого конкретного процесса, — это намеренная практика непрерывного совершенствования процессов.
Суть в том, чтобы постоянно размышлять о своем опыте и потребностях, чтобы совершенствовать имеющиеся процессы. Не попадайте в ловушку слепой веры в процесс, его можно и нужно менять.
ПРИНЦИП: «ПРИНЦИПЫ ПРЕВЫШЕ ПРОЦЕССА»
Многие компании, которые хотят трансформироваться, в ранний период развития неплохо справлялись с инновациями, но потом каким-то образом утратили эту способность.
К сожалению, такое случается сплошь и рядом, и успешные продуктовые компании всегда держат в уме такую перспективу.
Как предупреждает Джефф Безос, «верный процесс позволяет вам обслуживать клиентов. Но если вы невнимательны, он рискует превратиться в священную корову. В крупной организации это происходит очень легко. Помните, что процесс — это не главное. Всегда задавайте вопрос: мы владеем процессом или процесс владеет нами?»
Или, как отмечает Стив Джобс, «великие продукты создает не процесс, а содержание. Система заключается в том, что система отсутствует. Это не значит, что у нас нет процесса. Но он не главное».
ПРИНЦИП: «ИНФРАСТРУКТУРА ВНЕДРЕНИЯ»
Итак, у вас есть возможность внедрять небольшие, частые релизы, которые оснащены измерительными инструментами для получения необходимых телеметрических данных, и вы следите за дальнейшей судьбой этих обновлений.
Но чтобы обеспечить необходимую ценность для пользователя, существует еще один важный элемент, который предполагает наличие инфраструктуры, используемой для внедрения.
ПРИНЦИП: «МОНИТОРИНГ»
Измерительный аппарат, представленный в описании предыдущего принципа, имеет множество преимуществ, но одно из самых важных заключается в том, что он позволяет реализовать следующий принцип разработки: мониторинг, также известный как наблюдаемость.
Как и в случае с измерениями, мониторинг осуществляется на всех уровнях — от обеспечения правильной работы базовых вычислительных систем и сервисов до обеспечения правильной работы приложения и надлежащего обслуживания клиентов.
Благодаря тщательному мониторингу вы сможете быстро обнаруживать проблемы, причем нередко еще до того, как с ними столкнутся ваши клиенты.
ПРИНЦИП: «КОНТРОЛЬНЫЕ ИЗМЕРЕНИЯ»
Поскольку в продуктовой модели вы берете на себя обязательства по решению проблем и несете ответственность за достижение результатов, очень важно понимать, как ваши продукты используются на самом деле (либо не используются вовсе).
Это означает, что вам необходимо обеспечить такие измерения для своих продуктов, чтобы вы могли понимать, что происходит с функцией после ее внедрения. Это называется телеметрией, и она происходит на всех уровнях — от низкоуровневых сервисов, сообщающих о своем состоянии и производительности, до высокоуровневых приложений, генерирующих аналитику использования и целые информационные панели.
При отсутствии всех этих данных ваш продукт развивается вслепую.