В моей первой книге «Вдохновленные»[1] шла речь о том, как сильные продуктовые команды в лучших продуктовых компаниях используют современные методы исследования продукта, чтобы решать сложные проблемы так, как нравится клиентам, продолжая при этом работать на благо своего бизнеса.
Эта книга открыла мне и моим партнерам по SVPG (Silicon Valley Product Group) двери во многие организации за пределами Кремниевой долины.
И мы сделали удивительное открытие: во многих компаниях, даже там, где стремятся создавать по-настоящему технологичные продукты и услуги, продуктовым командам часто не позволяют работать так, как те считают необходимым.
Мы поняли, что дело не только в методах, которые сильные продуктовые команды используют для поиска и создания успешных продуктов. Различия между тем, как работают выдающиеся продуктовые компании и все остальные, лежат гораздо глубже.
Картина, которую мы увидели в этих компаниях, была довольно-таки неприглядной.
Многие компании до сих пор сохраняют старое IT-мышление в отношении технологий, видят в них скорее необходимые издержки, а не главный инструмент развития бизнеса, как это должно быть. Сотрудники технологической команды, согласно такому подходу, в буквальном смысле обслуживают бизнес, а менеджеры по технологиям и руководители помогают им выполнять эту задачу. Либо технологии вовсе задвигаются на задний план и передаются какому-нибудь цифровому бизнес-подразделению. Технологические команды отрезаны от реальных клиентов — по факту их вынуждают считать клиентом любого стейкхолдера.
Если компании и уделяют время обучению технологических команд и раскрытию потенциала каждого ее участника, то крайне мало. Менеджеры, если и хотят заниматься коучингом, то часто не обладают для этого необходимым опытом. Проблемы, таким образом, остаются нерешенными.
В большинстве из этих компаний признают, что имеющийся персонал не соответствует их потребностям, но придерживаются совершенно неверных представлений о том, как это исправить и чем руководствоваться в поиске специалистов по работе с продуктом. В этом случае проблемы также остаются нерешенными.
В этих компаниях редко существует вдохновляющее, привлекательное и убедительное видение продукта. Возможно, таковое у них и было на ранних этапах работы, но после ухода основателей оно потускнело. Поэтому у специалистов технологических команд создается впечатление, что они работают на «фабрике фич» (когда на первом месте количество новых, и часто бесполезных, релизов, а не реальные запросы клиентов).
Принцип распределения сотрудников технологических компаний по командам не создает у них впечатления, что они делают нечто значимое. Им кажется, что они мало что могут самостоятельно, без вмешательства со стороны других команд, что они лишь винтики в огромном механизме.
Было бы несправедливо утверждать, что у большинства таких компаний слабая стратегия продукта. Поскольку, по правде говоря, у большинства из них никакой стратегии продукта вовсе нет. Они просто стараются удовлетворить интересы и потребности едва ли не каждого стейкхолдера, используя те персонал, время и навыки, что у них есть.
В большинстве этих компаний слышали, что Google и другие используют такую методику управления, как OKR (Objectives and Key Results, то есть «цели и ключевые результаты»). Генеральные директора просмотрели соответствующее видео или прочитали книгу и решили, что все не так уж и сложно. В результате методику приняли на вооружение, наложив ее на уже существующие планы выпуска продукта и культуру производства, — и каждый квартал по несколько недель уделяют составлению дорожной карты, которую до конца квартала по сути игнорируют. Большая часть команд при этом полагают, что такая методика не приносит практически никакой пользы.
Взаимоотношения между технологическими командами и остальными звеньями бизнеса складываются не очень хорошо. У стейкхолдеров и руководства компаний мало или совсем нет доверия к технологическим командам. А члены технологических команд чувствуют себя недооцененными наемными работниками, находящимися в подчинении у бизнеса.
Хуже всего то, что команды не имеют прав и возможностей одновременно и решать проблемы теми способами, которые нравятся клиентам, и работать на благо своего бизнеса. Ситуация складывается так, что они не несут ответственности за результаты своей работы.
Менеджер по продукту (МП), в сущности, — это менеджер проекта, руководящий процессом контроля за бэклогом, то есть списком приоритетных функциональностей продукта. А задача дизайнеров и инженеров — просто разрабатывать функции, указанные в дорожной карте продукта, и писать код.
Мотивация команды в данном случае низкая, чувство сопричастности к созданию чего-то значительного — минимально, инновации появляются редко.
Легко понять, почему так много подобного рода компаний находятся на пороге краха. В их работе ничего не напоминает то, как создается продукт в сильных продуктовых компаниях[2].
Особенно поражает меня то, что методы работы более успешных компаний и секрет их финансового благополучия отнюдь не являются тайной за семью печатями. Отсюда возникает закономерный вопрос: в чем же здесь тогда дело?
Как подсказывает мой опыт, дело не в том, что компании не хотят трансформироваться, а в том, что трансформация — сложный и трудный процесс, а они просто не представляют, как ее осуществить. А может быть, даже не понимают, что вообще означает трансформация.
Что им реально нужно сделать — это перейти к модели продуктовых команд, наделенных широкими полномочиями.
Сам этот термин можно не использовать, можно даже не знать, что существуют разные типы технологических команд.
Но если вы и ваша организация узнали себя в этом описании, я должен поделиться с вами рядом соображений, которые отражают суровую правду жизни:
• Во-первых, учитывая ваши методы работы, у вас крайне мало шансов добиться в бизнесе значимых результатов, не говоря уже о создании инновационных продуктов.
• Во-вторых, ваши клиенты представляют собой заманчивую цель для вашего конкурента, который работает иначе (например, Amazon) и знает, как делать продукты, которые нравятся клиентам, при этом не забывая о своей выгоде.
• В-третьих, по большому счету вы зря тратите таланты и потенциал своего персонала, а ваши лучшие сотрудники — те, которых вам нужно удержать и обеспечить их процветание, — с немалой долей вероятности вас покинут.
• Наконец, если вы думаете, что, перейдя на «гибкую методику», методологию Agile, вы уже осуществили некую форму цифровой трансформации, увы, я должен вам сообщить, что вы еще даже не начинали.
Надеюсь, вы читаете эту книгу потому, что убеждены — должно быть более эффективное решение ваших проблем.
И оно действительно есть.