Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

Автономные команды

В компании Marquetly продакт-менеджеры очень переживали из-за отсутствия самостоятельности. Один опытный сотрудник сказал мне: «Мне постоянно говорят, что я должен сам определять концепцию продукта, но мне не разрешают. Мой руководитель продолжает снабжать меня решениями. Каждый раз, когда я пытаюсь предложить что-то другое, мне отказывают. Когда мы переходили на Agile, нам сказали, что Scrum-команды должны быть автономными. Но это – определенно не автономия».

Общаясь с руководителями Marquetly, я услышала другую историю: «Наши менеджеры не хотят брать на себя ответственность за продукт. Мне приходится постоянно что-то им предлагать. И все потому, что они не проявляют инициативы». Это интересная дихотомия, и тем не менее она часто встречается в компаниях, застрявших в ловушке разработки. Все это симптомы отсутствия хорошей стратегической основы, которая позволяет действовать. Когда команды не имеют четкого направления и целей, они не могут принимать эффективные решения. А если они осмеливаются пробовать, то чаще всего руководитель вмешивается и говорит: «Нет, так неправильно».

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

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

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

Глава 12

Создание хорошей стратегии

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

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

«Я обошла всех менеджеров в организации и спросила их, почему они работают над определенными вещами. Никто из них не смог мне ответить, – заметила Джен. – У них нет ни целей, ни направления. Они просто реагируют на запросы клиентов. Затем я обратилась к своим коллегам из руководящего состава и спросила их, что самое важное мы можем сделать как компания, – продолжила Джен. – Они все дали мне разные ответы. Совершенно очевидно, что мы не согласны с тем, какова наша стратегия и кем мы хотим стать как компания».

Бум. Она попала в точку – и всего через неделю Marquetly застряла в реактивном режиме. Она определяла приоритеты крупных проектов на основе запросов клиентов или контрактов. Она не думала стратегически, как развивать продукт.

К счастью, руководство компании Marquetly решило добиться единства взглядов, чтобы стать более мощной организацией. «Мы хотим лидировать на рынке, мы не хотим играть в догонялки», – сказал мне Крис, генеральный директор. Изначально он думал, что проблемы связаны с командами разработчиков. «Они медленно работают. Они халтурят». Крис был большим поклонником целей и ключевых результатов (OKR) и внедрил их во всей компании, но они были слишком ориентированы на показатели, а не на результат. «Разработать первую версию новой платформы для учителей» считалось его целью. А «выпустить к июню 2018 года» рассматривалось как ключевой результат. Они не были привязаны к какому-либо результату – ни в интересах бизнеса, ни в интересах клиента.