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