Управление продуктом. Российская практика бесплатное чтение
Введение
Существует много литературы об управлении продуктами. Ее можно разделить на четыре направления.
Первое представляет тему через призму тестирования продуктовых гипотез. Большинство таких книг были написаны консультантами из Кремниевой долины для предпринимателей, которым важно как можно быстрее найти соответствие продукта рынку, чтобы закрыть очередной раунд финансирования. В связи с этим им требуются подходы к получению ранних сигналов от рынка без необходимости траты денег на дорогостоящую разработку. Один из них, под названием Customer Development (развитие клиента), был создан и популяризирован Стивом Бланком.
Второе – обсуждение вопросов создания продуктовой функции в компании и роли продакт-менеджера в ней. Один из заметных авторов – Марти Каган, предложивший идею расширения возможностей продуктовых команд, перехода от поставки фич к созданию ценности для клиентов и достижению значимых бизнес-результатов.
Третье направление освещает различные исследования природы конкуренции и бизнес-моделей, принципов вывода прорывных инноваций на рынок. К нему можно отнести работы Клейтона Кристенсена и Майкла Портера по продуктовой стратегии, Александра Остервальдера – по моделированию бизнеса, Джеффри Мура – по распространению инноваций.
Ну и последнее, четвертое направление – методологическая литература про внедрение Agile-подходов, например методологии Scrum Джеффа Сазерленда.
Много лет я руководила программами для продакт-менеджеров в Высшей школе бизнеса Высшей школы экономики, проводила тренинги для продуктовых команд и сотрудников, а также управляла продуктовыми командами в российских компаниях.
Очень часто мне задавали вопрос: «Что нужно знать и уметь, чтобы стать успешным менеджером продукта?» По мере роста моей экспертности я по-разному на него отвечала.
Сначала мне нравился подход с матрицей компетенций, однако со временем я полностью от него отошла. Эта модель представляет собой описание навыков, оторванное от организационного контекста. С моей точки зрения, это попытка свести сложность познания к списку простых категорий, что очень активно пропагандируется в обучении специалистов начального уровня, у которых нет опыта. В итоге такой подход приводит к продаже обещаний успеха и высокой зарплаты после краткосрочных курсов и, как следствие, перегреву рынка начальных позиций.
Сейчас я все больше склоняюсь к тому, что продакт-менеджер – не роль начального уровня. Управлять продуктом сложно. Чтобы развить продуктовое мышление и понять, как функционирует бизнес, нужны время и опыт. Большинство известных мне успешных руководителей имели многолетний опыт работы в других ролях в компании, прежде чем получить роль менеджера по продукту.
В разных компаниях по-своему понимают роль продакт-менеджера в зависимости от зрелости продуктовой культуры. На одном конце спектра зрелости находятся команды, которые ориентированы на разработку (так называемые проектные команды / фабрики функций, feature team или delivery team), на другом – на создание ценности для клиентов и бизнеса (empowered – уполномоченные продуктовые команды).
«Фабрика функций» – это термин, который описывает процесс, направленный на быстрое создание и доставку функций без стратегического рассмотрения влияния, которое они оказывают на пользователей и бизнес. В командах, ориентированных на разработку, продакт-менеджеры становятся владельцами бэклога и координаторами взаимодействия между заинтересованными сторонами в компании (например, между ИТ, маркетингом и продажами) и отвечают за сроки и бюджеты; лишь небольшая часть времени посвящается исследованию рынка.
Альтернативой фабрике функций становится культура, в которой команды хвалят за то, что они помогают компании понять, что создавать, решать проблемы клиентов, повышать удовлетворенность клиентов, совершенствовать ключевые показатели продукта и способствовать достижению целей компании. Такие продуктовые команды имеют автономию в определении приоритетов работы без длительных согласований бюджетов, в них выделяются время и ресурсы на регулярные исследования рынка, происходит постоянное улучшение соответствия продуктов рынку путем тестирования гипотез. В этом случае менеджер должен хорошо понимать, как продукт создает и монетизирует ценность, каковы бизнес-модель, целевой сегмент, ценностное предложение, как оно разбивается на клиентские пути и поддерживается функциями продукта. Все это необходимо, потому что продуктовая команда отвечает не только за разработку, но и за достижение целей, напрямую связанных с получением выручки и прибыли.
Большинство команд в российских компаниях находятся где-то посередине этого спектра, при этом очень хотят стать более уполномоченными, однако это стремление сдерживается спецификой работы, недостатком компетенций и барьерами в оргструктуре. Стоит отметить, что нет ничего плохого в работе в проектных командах, однако важно понимать три момента.
• Для этой работы в первую очередь требуются навыки управления доставкой, то есть разработки функций в соответствии со спецификацией в сроки, а не управления продуктом.
• Роль владельца продукта более уязвима, так как многие считают, что ее вклад в успех сильно переоценен.
• Даже зная такие системные фреймворки, как анализ бизнес-модели, построение юнит-экономики и др., менеджеры не могут их эффективно применять в работе, потому что у них нет для этого полномочий. Через мои курсы прошло около тысячи менеджеров, и у каждого был один и тот же запрос: как одному бороться с системными проблемами, стремясь изменить ситуацию не в зоне своей ответственности.
Задачи, которые решает продакт-менеджер, различаются в зависимости от стадии жизненного цикла продукта. Если речь о стартапе, то эту роль чаще всего выполняет основатель. Обычно нужно достичь соответствия рынку, определенного масштаба и расширения штата разработчиков, до того как потребуется создавать продуктовые команды.
Как только продукт переходит в стадию роста, встает задача усиления соответствия рынку. В этот момент происходят разграничение зон ответственности и наем продакт-менеджеров для каждой зоны, которые должны заниматься оптимизацией через улучшение ключевых показателей, влияющих на прибыль, проводить множество экспериментов с относительно небольшим уровнем риска.
Когда продукт достигает зрелости, дальнейший рост возможен через выход на новые рынки с новым продуктом или слияния и поглощения. Тут требуется продакт-менеджер с мышлением предпринимателя, готовый к неопределенности, которая связана с созданием новой бизнес-модели. Интересно, что при найме эти нюансы не сильно учитываются, хотя в зависимости от стадии жизненного цикла меняется взгляд на роль менеджера. В итоге вас могут нанять на должность, которая обычно помогает внедрять инновации, но у вас нет для этого структурного мандата и полномочий, а как следствие – и ресурсов.
На курсах и в книгах много рассказывается об идеальном управлении продуктами на примерах высокотехнологичных компаний Кремниевой долины, прежде всего стартапов. В реальности множество специалистов, вооружившись современными продуктовыми практиками, советами Стива Бланка и Марти Кагана, приходят работать в команды, которые застряли в фабрике функций со сложными процессами принятия решений и низким риск-аппетитом. В этот момент часто возникают разочарование в продуктовом подходе и выгорание после нескольких неудачных попыток бросить вызов статус-кво, и в итоге люди увольняются из компании.
Нередко руководство недостаточно осведомлено о том, как управление продуктами действительно создает ценность в организациях. Это приводит к нереалистичным ожиданиям от этой роли, а впоследствии к разочарованию и вопросу окупаемости инвестиций в продуктовую трансформацию. С одной стороны, от менеджеров ожидают, что те будут действовать как внутренние предприниматели – строить масштабируемый бизнес, а не управлять фабрикой функций. С другой стороны, продуктовая трансформация требует системных изменений в самой компании, прежде всего в оргструктуре и процессах принятия решений, к которым руководство не всегда готово. Хорошая новость в том, что продакт-менеджеры могут стать лидерами этих изменений при определенных условиях.
Ну и последнее. Наличие навыков, опыта, продуктовой культуры все еще не гарантирует карьерного успеха. Кроме всего вышеперечисленного, необходимы лидерские качества, способность брать на себя ответственность и демонстрация значимых для бизнеса результатов.
Книга разделена на пять частей, каждая из которых обращается к различным аспектам управления продуктом в современных компаниях.
Часть I начинается с обзора различных подходов к созданию продуктов, начиная с традиционного водопадного метода и переходя к гибким Agile-методикам, таким как Scrum. Особое внимание уделяется влиянию Lean Startup на современные стратегии управления продуктом. В этой части также рассматривается эволюция от функциональных к продуктовым командам, стратегическое управление продуктами, роли в продуктовых командах и культурные аспекты внедрения продуктового подхода. В заключении акцент делается на роли продакт-менеджера и его взаимодействии с командами, а также на различиях между ролями владельца продукта и менеджера проектов и продуктов.
Часть II фокусируется на стратегиях управления продуктом с акцентом на создание ценности как для клиентов, так и для бизнеса. Включены разделы о бизнес-модели, ценностном предложении, монетизации, привлечении клиентов, анализе рынка и конкурентных преимуществах. Эта часть охватывает ключевые аспекты управления продуктом на различных стадиях его жизненного цикла – от стартапа до его масштабирования и роста, включая поиск Product-Market Fit.
Часть III представляет глубокое введение в основные концепции и методологии успешного управления продуктом, включая юнит-экономику, анализ пользовательского опыта и другие ключевые аспекты разработки и улучшения продуктов.
Часть IV посвящена дорожной карте и планированию работы продуктовых команд. Здесь подробно рассматриваются методологии и стратегии, необходимые для эффективного контроля и координации работ, включая разработку дорожных карт, применение методологии OKR, сравнение высокоуровневого планирования и детализированного исполнения, а также методы Kanban и Scrum.
Часть V описывает методы достижения влияния в организации без формальных полномочий. Здесь рассматриваются стратегии – от понимания ожиданий окружающих и построения доверительных отношений до разработки эффективной коммуникационной стратегии и укрепления связей с ключевыми заинтересованными сторонами. Особое внимание уделяется значимости доверия в команде и методам конструктивной обратной связи.
Несмотря на то что я писала эту книгу в первую очередь для продакт-менеджеров и руководителей, она будет полезна широкой аудитории, включая:
• продакт-менеджеров и тех, кто занимается управлением продуктами, независимо от уровня опыта, так как книга дает глубокое понимание различных методологий и стратегий управления продуктом, помогая совершенствовать их навыки;
• руководителей и менеджеров, ответственных за разработку продуктов и стратегическое планирование в компании, так как книга предлагает инсайты в ключевые аспекты управления продуктами, которые помогут оптимизировать процессы и повысить эффективность команды;
• специалистов по маркетингу и продажам, так как она освещает важность ценностного предложения, монетизации продукта и привлечения клиентов;
• стартапы и предпринимателей, интересующихся методами поиска соответствия продукта рынку и стратегиями масштабирования продукта;
• консультантов и тренеров, которые специализируются на Agile, Scrum и других методологиях управления продуктом и которым нужны рекомендации для работы с клиентами;
• всех, кто заинтересован в современных тенденциях и инновациях в управлении продуктом, в том числе академическое сообщество и исследователей.
Книга сочетает в себе теоретические знания с практическими примерами и советами, что делает ее полезной для разнообразных профессионалов, стремящихся совершенствовать свои навыки в управлении продуктом и разработке стратегий.
В последние годы профессия менеджера по продукту становится все более популярной и востребованной в России. С развитием технологических компаний и цифровизации спрос на продакт-менеджеров продолжает расти. Количество вакансий увеличивается, а средняя зарплата повышается. Считается, что вход в эту профессию не требует специфического бэкграунда, что делает ее доступной для людей из различных сфер – разработки, аналитики, продаж, дизайна и др. По данным зарплатного калькулятора «Хабр карьеры», средняя зарплата продакт-менеджера в России в начале 2024 года составляет 241 000 руб.[1], что в целом очень перспективно для рынка труда. По моим наблюдениям, средняя заработная плата колеблется от 150 000 до 300 000 руб. Размер компенсации зависит от численности продуктовой команды, масштаба компании, стадии развития продукта и других факторов. Зарплата директора по продукту (Chief Product Officer, CPO) отдельного направления или всех продуктов в компании может составлять от 300 000 до 800 000 руб.
Далее я расскажу о том, как вижу эту ситуацию, а также развею некоторые мифы, созданные часто в маркетинговых целях.
Становление профессии продакт-менеджера в России прошло несколько ключевых этапов, отражающих развитие технологической и бизнес-среды в стране. С начала 2000-х стало формироваться понимание роли продакт-менеджера. Интернет-компании, такие как «Яндекс», VK и др., активно перенимали западные практики управления продуктами. С начала 2010-х стали появляться специализированные образовательные программы, курсы и тренинги по продакт-менеджменту. В 2013 году был создан Фонд развития интернет-инициатив (ФРИИ) для поддержки стартапов, который в том числе занимался популяризацией методологий Кремниевой долины.
Успех цифровых бизнес-моделей компаний, которые стали лидерами в своих отраслях, вдохновляет. «Яндекс», который начинался как поисковая система, превратился в многоотраслевую экосистему сервисов; Т-банк, Сбер стали финансово-технологическими экосистемами; «Авито» – одной из крупнейших платформ объявлений; Ozon – крупнейшим маркетплейсом; VK – экосистемой цифровых сервисов и др. Все это впечатляет, многие специалисты хотят «ворваться в ИТ» именно в эти компании и именно продактами. Эта профессия стала модной, достаточно хорошо оплачиваемой, на нее есть стабильный спрос. Кажется, что в ней нет ничего сложного. Продакт-менеджеры требуются в самых известных компаниях, услугами которых пользуются миллионы людей каждый день. Работа там часто ассоциируется с высоким социальным статусом и престижем.
Мы знаем, что у всего есть обратная, темная сторона медали. В данном случае это приток на рынок труда неквалифицированных кадров, которые не обладают необходимыми компетенциями или стремятся воспользоваться популярностью профессии для быстрого карьерного роста. Во многом это связано с тем, что компании, стараясь удовлетворить высокий спрос и сами не обладая нужными компетенциями, могут снижать требования к кандидатам. Ситуацию усложняют многочисленные краткосрочные курсы и сертификаты, создающие иллюзию, будто можно за полгода стать профессионалом. Это усугубляется агрессивным маркетингом, который привлекает людей, далеких от сферы IT, без технического образования и нужной системной подготовки, обещаниями быстрого успеха и легкого заработка. В итоге мы наблюдаем перегрев на рынке начальных позиций.
Если убрать в сторону специфические методологии, в основе работы продакт-менеджера лежит системное мышление. Россия исторически обладает сильной математической школой, что создало базу для высококвалифицированных специалистов в области ИТ. Эта подготовка позволяет генерировать на выходе из ключевых вузов много системно мыслящих людей, которые обладают способностью к аналитическому и структурированному подходу к решению проблем. Краткосрочные курсы не могут сравниться с глубиной и качеством такой подготовки. В 2024 году исследование показало, что для большинства позиция продакт-менеджера – далеко не первая работа в ИТ, около 55 % уже трудились в отрасли несколько лет. Конкуренция высока, и для достижения успеха требуются желание учиться, узнавать новое, справляться с трудностями и увлеченность профессией, а не просто сертификат и стремление зарабатывать удаленно.
В итоге можно часто заметить дискуссии на тему, что «продакты не нужны». Обычно их ведут «потерпевшие»: либо члены продуктовой команды, столкнувшиеся с низкой квалификацией менеджеров, из-за которой последние не справлялись с задачами, либо сами менеджеры, чьи ожидания от профессии не оправдались.
Еще одной проблемой является то, что часто команда или руководство не понимают, чем конкретно должен заниматься продакт-менеджер. В крупных компаниях финансовые возможности позволяют разделить управление продуктом между различными специалистами, тогда как в небольших компаниях ценится способность закрывать большой объем работ ограниченными ресурсами. В условиях ограниченного бюджета обязанности продакта могут пересекаться с функциями других ролей, таких как проектные менеджеры, бизнес-аналитики или даже разработчики. По мере успешного роста компании разделение обязанностей становится нормальной практикой.
Таким образом, на данный момент рынок продакт-менеджеров находится в состоянии фрагментации. Если говорить о крупных технологических компаниях, то во многих есть сформулированные ожидания относительно этой роли и понятный карьерный трек. Иначе говоря, они знают, чего они хотят. Что касается остальных, чаще всего вы их встретите в компании в состоянии продуктовой трансформации. Скажу пару слов о том, что это такое.
Обычно под продуктовой трансформацией понимают обучение сотрудников продуктовому мышлению, работу над системной проверкой гипотез, выстраивание процессов и формирование команд. В первых двух главах книги мы подробно коснемся аспектов продуктовой трансформации, культуры продуктовых команд в России и трудностей эволюции и взаимодействия на этом нелегком пути.
Эта книга также адресована людям, которые работают в таких компаниях и находятся в поиске ответов на вопросы, кто такой успешный продакт-менеджер и какими навыками он должен обладать.
Выше я написала, что сама редко использую матрицы компетенций в работе. Но это мое субъективное мнение. Все-таки в большинстве крупных компаний их можно встретить. Обычно каждые полгода-год проводятся перформанс-ревью на основе этих матриц: руководители и сотрудники ставят оценки, обсуждают результаты и готовят план роста.
Итак, обычно в матрице выделяются следующие уровни: начальный, средний, опытный и экспертный. Собственно, и вакансии вы увидите с указанием этих уровней.
1. Начальный (Junior).
• Описание. Продакт-менеджер обладает базовыми знаниями и пониманием своего дела, ориентирован на освоение основных процессов и методологий, выполняет задачи под присмотром опытного менеджера.
• Пример. Может заниматься анализом данных о поведении пользователей на сайте или в приложении и подготовкой рекомендаций по улучшению пользовательского опыта, проведением интервью для получения обратной связи и др.
2. Средний (Middle).
• Описание. Продакт-менеджер обладает более широкими знаниями и опытом, отвечает за улучшение показателей продукта, планирование дорожной карты, эффективное взаимодействие с командой.
• Пример. Обычно отвечает за конкретные метрики, может самостоятельно формировать ключевые гипотезы и приоритизировать дорожную карту и бэклог для достижения продуктовых целей и др.
3. Опытный (Senior).
• Описание. Продакт-менеджер со значительным опытом и карьерными достижениями, принимает стратегические решения, управляет продуктами на протяжении всего их жизненного цикла, понимает рынок, эффективно коммуницирует с ключевыми заинтересованными сторонами.
• Пример. Может разрабатывать стратегию развития новых продуктов, проводить анализ и синтез рыночных трендов, конкурентов и потребностей клиентов, координировать работу нескольких кросс-функциональных команд. Например, определять ключевые цели для продукта, искать новые возможности монетизации и модели продаж и др.
4. Экспертный (C–Level).
• Описание. Обладает глубокими знаниями и опытом, разрабатывает инновационные стратегии, проводит сложный анализ рынка, прогнозирует тренды и успешно управляет продуктами высокой сложности.
• Пример. Разрабатывает долгосрочную стратегию компании и продукта, внедряет инновационные подходы в управление, руководит несколькими направлениями продуктов одновременно и обеспечивает их конкурентоспособность на рынке. Отвечает за бизнес-цели портфеля продуктов, координацию усилий нескольких продуктовых команд.
Далее я привожу универсальную шкалу компетенций по следующим базовым направлениям.
1. Стратегическое мышление – способность видеть и понимать долгосрочные цели и направления развития продукта, принимать решения на основе анализа внутренних и внешних факторов. Про стратегическое мышление мы будем говорить исходя из понимания бизнес-модели и конкуренции на рынке в части II.
2. Проектирование клиентского опыта – создание и оптимизация взаимодействий клиентов с продуктом, направленных на повышение их удовлетворенности и лояльности. О проектировании клиентского опыта мы будем говорить в главах 12, 13 и 14.
3. Управление командой – способность эффективно руководить и координировать группу людей, работающих над продуктом. Об эффективном управлении командой мы поговорим подробно в главе 19.
4. Маркетинг и продвижение продукта – процесс вывода продукта на рынок, увеличение его узнаваемости и удовлетворение потребностей пользователей. О маркетинге мы поговорим в главах 5 и 12.
5. Аналитические навыки – способность собирать, анализировать и интерпретировать данные, связанные с продуктом, пользователями и рынком, понимать ключевые метрики продукта. Об аналитике мы поговорим в главах 11 и 15.
Вы можете адаптировать эти компетенции и уровни под свою компанию (если нужно); я также брала их за основу при формировании программ обучения для продакт-менеджеров в российских компаниях.
Честно говоря, я отрицательно отношусь к матрицам компетенций в работе и оценке менеджеров. И вот почему. Они часто предлагают стандартизированный подход, который может не учитывать такие важные, но трудноизмеримые навыки, как эмпатия, креативность и способность к импровизации.
Кроме того, разработка и поддержание актуальности матриц компетенций требуют значительных затрат времени и ресурсов руководителей. Матрицы компетенций также могут быть слишком жесткими и не учитывать быстро меняющиеся требования рынка и бизнеса. Отсутствие учета контекстных факторов, таких как организационная культура, может еще больше усложнить процесс оценки.
Еще одной проблемой можно назвать субъективность оценок компетенций. Руководители порой оценивают сотрудников на основе личных предпочтений или предвзятостей, что снижает объективность и может вызвать недовольство у подчиненных.
Чем-то эти матрицы напоминают мне должностные инструкции, которые в креативных отраслях никто не читает: они воспринимаются как формальность и не находят активного применения в повседневной практике. Сотрудники больше ценят свободу действий и возможность экспериментировать, чем строго регламентированные процессы и требования.
Тем не менее правильно разработанные и гибко применяемые матрицы компетенций могут приносить пользу младшим менеджерам по продукту, которым нужно учить «матчасть». Роль младшего (начинающего) менеджера сводится к управлению отдельной функцией в продукте – разделом сайта, функцией в приложении или отдельной посадочной страницей, частью клиентского пути в продукте и т. д. Это тот самый легендарный «менеджер одной кнопки». Несмотря на сарказм, это важная роль для компании, которая позволяет войти в профессию. Основные навыки сводятся к конкретным методикам, фреймворкам, исследованию поведения пользователей, проведению интервью и пр.
Очевидно, что специалистов, которые обладают экспертным уровнем для всех вышеперечисленных компетенций, днем с огнем не сыщешь на рынке. Но, чтобы быть хорошим продакт-менеджером, вам не обязательно быть экспертом во всем.
Повышение сотрудников действительно можно сделать более эффективным, если ориентироваться на ключевые факторы, которые напрямую влияют на результативность и вклад сотрудника в компанию. Рассмотрим подробнее каждый из предложенных факторов. Подобный подход я встречала у многих знакомых руководителей в крупных компаниях.
1. Выполнение задач следующего уровня на текущем грейде еще до официального повышения: демонстрирует готовность к новым вызовам и большей ответственности, показывает, что сотрудник активно работает над своими навыками и знаниями. Одним словом, инициатива ценится вопреки известной пословице.
2. Умение достигать целей, несмотря на изменения обстоятельств; гибкость и способность адаптироваться к изменениям. Появление новых потребностей или предпочтений пользователей, новых конкурентов, технологий, внутренние изменения в команде, изменения в доступности ресурсов (финансовых, временных, людских), изменение приоритетов проекта, изменения бюджета или сроков выполнения проекта, новые законы и регуляции – все это может повлиять на продукт и не должно вызывать паники или выгорания.
3. Автономность. «Ждуны» – это сотрудники, которые не проявляют инициативы и пассивно ждут указаний от руководства или других коллег, чтобы приступить к выполнению своей работы. Наоборот, автономные менеджеры обладают следующими качествами:
• для начинающих специалистов это умение самостоятельно прорабатывать требования к задачам и решать проблемы без постоянной поддержки;
• для специалистов среднего уровня это способность замечать точки роста и продумывать продуктовые решения, аргументировать свою новую точку зрения перед заинтересованными сторонами;
• для старших специалистов это самостоятельная проработка и защита стратегии, что требует видения и способности прогнозировать развитие продукта и компании.
4. Умение смотреть шире своей зоны ответственности. Это может быть участие в смежных проектах, предложения по улучшению процессов или работа с межфункциональными командами.
5. Запуск продуктов, которые успешно улучшают ключевые метрики, демонстрируя способность не только разрабатывать решения, но и понимать их бизнес-ценность.
6. Эмоциональный интеллект: способность понимать свои эмоции и эмоции других людей, управлять ими. Высокий эмоциональный интеллект помогает в построении эффективных рабочих отношений, управлении конфликтами и поддержании позитивного климата в команде.
7. Управление временем и приоритетами. Умение эффективно организовать свое время и задачи, определять приоритеты, координировать работу команды, управлять рисками и решать возникающие проблемы. Это особенно важно в условиях многозадачности и ограниченных ресурсов.
Я могу разделить российские компании на четыре категории с точки зрения преимуществ для продакт-менеджеров.
Первая категория: корпорации и крупные компании, перешедшие к цифровым продуктам.
К первой категории относятся интернет-корпорации, такие как «Яндекс», VK и Ozon. В эту категорию также входят компании из традиционных отраслей экономики, которые адаптировали свои бизнес-модели через цифровизацию клиентского опыта и внедрение новых технологий, например МТС и Сбербанк. Почти все эти компании приняли экосистемный подход, который позволяет им открывать новые источники дохода, монетизировать данные и предлагать дополнительные услуги на базе существующей инфраструктуры. Усиление конкуренции в области цифровых экосистем требует постоянных инвестиций в инновации, улучшение клиентского опыта и расширение партнерской сети.
Вторая категория: крупные высокотехнологичные компании с цифровой бизнес-моделью.
В эту категорию входят высокотехнологичные компании, которые изначально имели цифровую бизнес-модель, такие как «Авито», Lamoda, Skyeng, «Циан», «Точка», Headhunter, «Контур» и другие. Высокий уровень обслуживания клиентов и персонализация услуг являются ключевыми элементами их стратегии, что помогает удерживать клиентов и привлекать новых.
Третья категория: компании из традиционного сектора экономики, переходящие к цифровизации.
Третья категория охватывает компании традиционного сектора экономики, включая нефтегазовые, производственные и транспортные предприятия, которые лишь начинают свой путь к цифровой трансформации.
Четвертая категория: стартапы.
Четвертая категория – стартапы. В России венчурный рынок развивается медленно. Основной проблемой является недостаток капитала, доступного для венчурных инвестиций. Российские инвесторы часто предпочитают более консервативные вложения с меньшим уровнем риска.
Наиболее зрелый продуктовый подход наблюдается в первых двух категориях. Корпорации и крупные высокотехнологичные компании активно инвестируют в развитие своих цифровых экосистем и платформ, создавая благоприятные условия для работы продакт-менеджеров. Эти компании имеют разветвленную корпоративную культуру, развитую систему наставничества, формальные программы обучения и сертификации, что способствует профессиональному росту специалистов.
Компании из третьей категории только начинают осваивать продуктовый подход, что создает определенные трудности, но и предоставляет уникальные возможности для продакт-менеджеров, способных вести трансформационные проекты.
Стартапы, несмотря на все сложности и вызовы, являются площадкой для быстрых экспериментов в условиях ограниченных ресурсов и высокой неопределенности. В стартапах команды обычно компактные, каждый сотрудник выполняет множество различных задач. Это приводит к ситуации, когда функции продакт-менеджера распределяются между другими членами команды: основателями, разработчиками или дизайнерами. Нанимать отдельного продакт-менеджера слишком дорого, особенно на ранних стадиях развития компании. Когда стартап начинает расти, команда расширяется, координация и управление продуктом становятся сложнее, тогда фаундер задумывается о создании продуктовых команд и найме продакт-менеджера. Но это, конечно, не всегда так. Скорее это тенденция, но не правило.
Есть несколько особенностей в работе менеджеров продуктов, которые я встречаю в российских компаниях.
Сначала поговорим про широкий и часто нефиксированный спектр задач. Продакт-менеджер отвечает за исследования, планирование, определение приоритетов, управление ресурсами, взаимодействие с командой и др. Это требует объединения навыков из разных областей. Как следствие, происходит слияние продуктового и проектного управления. Чем сложнее бизнес-процессы и процессы согласования в компании, тем больше координационных задач выполняет продакт-менеджер, который берет на себя еще и роль руководителя проектов, и тем меньше времени у него остается на стратегический анализ и исследования. Если вы когда-нибудь видели календарь продакт-менеджеров в таких командах, то он состоит из бесконечных встреч и беготни. Часто на мероприятиях обсуждаются одни и те же вопросы, что приводит к потере времени. Менеджеры часто попадают в эту ловушку, создавая иллюзию активности, но не достигая реальных результатов.
Я нередко встречала продакт-менеджеров, которые просили в штат еще и руководителей проектов, бизнес-аналитиков, владельцев продуктов, так как «не успевали со всеми задачами». Проблема в том, что эту просьбу часто не одобряет руководство, которое придерживается подхода «сначала покажи результат, потом проси людей». Замкнутый круг.
С одной стороны, правы продакт-менеджеры. Во-первых, ожидание результатов без предоставления дополнительных ресурсов затрудняет достижение поставленных целей. Во-вторых, отсутствие поддержки и ресурсов вызывает демотивацию и стресс. Когда руководство требует результатов, но не предоставляет необходимых инструментов для их достижения, возникают напряжение и чувство беспомощности. Чтобы разорвать этот порочный круг, необходимы изменение подхода к управлению и понимание важности инвестиций в команду на ранних этапах. С другой стороны, правы руководители. Для них важны последствия действий через влияние на бизнес-результат. Об этом подробно мы будем говорить в главе 2.
В сложных коммуникациях неизбежно возникают конфликты интересов, которые могут быть как здоровыми, так и токсичными. Опасность токсичных конфликтов заключается в том, что люди начинают избегать друг друга, стремясь достичь своих целей через подрыв авторитета или использование «культуры отмены». Я убеждена, что программа российских школ должна включать развитие эффективных коммуникаций. Для продуктовых менеджеров особое значение имеют навыки влияния без формальных полномочий, стрессоустойчивость и мягкие навыки (soft skills). Командные конфликты часто возникают из-за несоответствия ожиданий, о которых не говорят. Про понимание ожиданий и проактивную позицию мы поговорим в главах 3, 4 и 18.
Многие российские компании начинают задумываться над своей долгосрочной стратегией и поиском значительных возможностей и приходят к необходимости продуктовой трансформации. Традиционные методы стимулирования роста через продажи, маркетинг или конкурентное ценообразование больше не работают. Компании, ориентированные на продажи, часто испытывают трудности с привлечением клиентов, которые не видят их ценность. Маркетинговые расходы постоянно растут, а конкуренция (в первую очередь по цене) приводит к бесконечной гонке, медленно снижающей прибыль. Крупные экосистемы концентрируют вокруг себя рынок, формируя барьеры для входа. Конкурентная борьба за платежеспособные сегменты становится жесткой.
Новая стратегия предполагает изменения не только в продукте, но и в подходах к работе. Самый большой риск заключается в том, что компании не подготовлены к этим изменениям ни с точки зрения компетенций, ни с точки зрения процессов, ни с точки зрения организационной структуры.
В ряде случаев продуктовая трансформация превращается в пустой лозунг. Формально создаются продуктовые команды, но фактически трансформация не получает поддержки. На собраниях декларируется приверженность продуктовому подходу, однако руководство и ключевые заинтересованные лица не оказывают продакт-менеджерам необходимую помощь, не выделяют ресурсы, продолжают придерживаться старых практик и не стремятся к реальным изменениям, способным пошатнуть их статус-кво.
В российских компаниях очень развита асимметрия во властных полномочиях: существуют ключевые люди, которые могут существенно повлиять на успех вашего продукта, используя свои возможности. Они обладают полномочиями одобрять бюджеты, блокировать изменения, принимать единоличные решения или, наоборот, игнорировать те изменения, которые не в зоне их интересов. В такой ситуации продакт-менеджер чувствует фрустрацию: его решения и усилия часто обесцениваются, поэтому он подстраивается под культуру и становится владельцем продукта или проектным менеджером. Эти вопросы мы подробнее рассмотрим в главе 2.
Одной из причин, по которым я начала писать, было желание выкристаллизовать многое из того, что я узнала за последнее десятилетие или около того. Для этого я создала телеграм-канал Strategic Move, но посты там не всегда представляют собой структурное освещение проблемы, хотя я считаю, что это отличный формат для саморефлексии, которая очень важна для менеджера продукта.
Во-первых, я признаю, что постоянно учусь и, как говорил Эйнштейн, «по мере того, как расширяется круг наших знаний, расширяется и окружающая его тьма». Рефлексия позволяет структурировать знания и задавать себе новые вопросы.
Во-вторых, я рекомендую читать эту книгу, не отвлекаясь на мессенджеры и тому подобные вещи. Концентрация – ключевой момент. Я обычно читаю рано утром, еще до начала работы, когда никто мне не мешает.
В-третьих, я уважительно отношусь к точке зрения другого человека, даже если с ней не согласна, но при этом она не нарушает моих границ. Конструктивная критика – способ учиться и становиться лучше, но тут ключевое слово «конструктивная», она должна быть аргументирована не на уровне чувств, а на уровне логики. Любую обратную связь по этой книге вы можете направить мне на почту: [email protected].
Эта книга будет полезна продакт-менеджерам, которые хотят стать лидерами изменений в компаниях в состоянии продуктовой трансформации и адаптировать лучшие практики к их текущему контексту. Материал основан на моем опыте работы и консультирования, а также исследованиях и опыте российского сообщества. После множества часов консультаций и обучения я постаралась выделить паттерны поведения продакт-менеджеров в переходный период.
Итак, приступим.
Юлия Билинкис, спикер и консультант по продуктовой стратегии, https://t.me/strategic_move
Часть I. Зоны влияния продакт-менеджера, продуктовый подход и создание продуктовых команд
Глава 1. Подходы к управлению продуктом
Что труднее всего на свете видеть своими глазами? То, что лежит перед ними.
Иоганн Вольфганг фон Гете
Шестнадцать лет назад я работала в компании, которая занималась внедрением программного обеспечения. В какой-то момент у акционеров возникло желание создать стартап и сделать облачный Service Desk. Я играла роль бизнес-аналитика. У меня были диплом по направлению «информационные системы и сети» одного из ведущих вузов страны, опыт написания множества технических заданий и оценки требований.
В то время никто еще не слышал про продакт-менеджеров, такой роли просто не было. Я, как бизнес-аналитик, должна была переводить видение заказчиков в требования для разработчиков. Как вы думаете, что мы тогда делали? Наверное, вы уже догадались: «пилили фичи». И мы даже не осознавали, что нам нужно заняться тестированием бизнес-модели продукта и первыми продажами.
Прошлый опыт определяет, как мы принимаем решения, наши действия и предпочтения. Как-то Абрахам Маслоу сказал: «Если единственный инструмент, который вы имеете, – молоток, то заманчиво рассматривать все как гвозди». Люди могут по умолчанию использовать знакомые им методы, которые срабатывали в прошлом. Нам постоянно казалось, что продукт еще не готов; в итоге полтора года мы работали на фабрике функций без обратной связи от рынка, мыслей о модели продаж и монетизации. Главное ограничение роста всегда смещается в зону некомпетентности команды – «слепую зону», в которой команде не хватает экспертизы.
Это было начало 2000-х, и в свое оправдание могу сказать, что тогда опыта работы в стартапе почти ни у кого не имелось. В 1990-е мы стали свидетелями быстрого расширения технологических компаний, однако в 2001 году в США лопнул «пузырь доткомов» ровно потому, что старые методы больше не работали. Закрылось огромное количество интернет-стартапов, которые не смогли оправдать ожидания инвесторов и обеспечить соответствие продукта рынку. Это простимулировало появление новых подходов к управлению продуктом: Agile (гибкую разработку программного обеспечения) и Lean Startup (бережливый стартап).
Однако обо всем по порядку. Вы можете спросить: «Если не проводить исследования рынка, то как понять, какой продукт нужно делать?» На этот счет есть две теории.
Одна заключается в том, что идея – озарение предпринимателя, а сами бизнесмены – такой особенный класс людей, которые обладают даром предвидения. Часто приводят высказывание Стива Джобса: «Очень трудно создавать продукт для конкретных людей. Чаще всего люди сами не знают, чего хотят, пока ты не покажешь им это. Вот почему я никогда не полагаюсь на исследования рынка. Наша задача – прочесть то, чего еще нет на странице». Конечно, Джобс был визионером, готовым рисковать, но было ли это свойство даром свыше или следствием его характера и прошлого опыта?
Мне очень нравится речь Стива Джобса перед выпускниками Стэнфорда, в которой он поделился еще одной важной мыслью.
Нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем. Ничего из того, что я тогда узнал, казалось бы, не могло иметь никаких практических последствий для моей жизни. Но десять лет спустя, когда мы создавали первый компьютер «макинтош», все это мне пригодилось. Мы заложили всю изученную мной премудрость в нашу машину. Это был первый компьютер, владеющий каллиграфией. Если бы я не наткнулся на тот курс в колледже, у «мака» никогда бы не было множества разных типов шрифтов. И поскольку Windows в этом отношении просто копирует «макинтош», возможно, что ничего этого не было бы ни на одном персональном компьютере. Итак, нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем.
Эта цитата наводит меня на мысль, которая была описана в концепции экономиста Израэля Кирцнера об обнаружении ошибочно нераспознанных возможностей в его книге «Конкуренция и предпринимательство»[2]. По сути, идея Кирцнера вращается вокруг предпринимательской функции выявления возможности получения прибыли, которая обусловлена асимметрией информации на рынке. Согласно ему, предприниматели, благодаря своей бдительности и дальновидности, могут распознать возможности получения прибыли, которые другие упустили из виду или недооценили. Поэтому часто бизнесмены начинают стартапы с осознания и глубокого понимания проблемы, с которой сталкиваются лично: они – эксперты в предметной области. Я много раз была свидетелем тому, как какое-то стоящее предложение возникало у экспертов из-за объединения старых знаний в новые комбинации, то есть благодаря умению создавать новые взаимосвязи.
У Питера Тиля, соучредителя PayPal, в книге «От нуля к единице. Как создать стартап, который изменит будущее» есть интересная глава о секретах, которую он открывает словами: «Каждая из самых известных и знакомых сегодня идей когда-то была неизвестной и неожиданной. Лучшие предприниматели знают: в основе любого великого бизнеса лежит секрет, скрытый от внешнего мира».
Например, всем известный продукт Miro, который сейчас обслуживает 99 % компаний из списка Fortune 100 и имеет более 50 млн пользователей, начался в 2011 году с идеи Андрея Хусида и Олега Шардина[3] перенести интерактивную доску в браузер для «визуального сотрудничества». На эту идею их натолкнула работа в креативном агентстве. Они поняли, что люди могут общаться визуально и этот способ во многих случаях лучше закрывает задачу совместного творчества по сравнению с обычным обменом сообщениями. Картинка стоит тысячи слов – такова была первоначальная идея Miro. Однако ей потребовалось четыре года, чтобы достичь соответствия продукта рынку после разработки первой версии решения.
Могу сказать, что знание ошибочно нераспознанных возможностей, которые и становятся «секретом», отличается от простой идеи продукта или галлюцинации основателя. Это первое, что нужно понимать, когда вам приводят статистику провала стартапов (девять из десяти «умирают» и закрываются). Ключевое слово тут – «возможность»: возможность создать жизнеспособную масштабируемую бизнес-модель.
Теперь представим, что вы не основатель, а работаете в продуктовой команде, не общаетесь с клиентами, не пользователь своего продукта или не имеете опыта в своей предметной области. Какова вероятность обнаружения и реализации вами стоящей возможности?
В итоге ложное убеждение в том, что проблема понятна, приводит к тому, что создаются ненужные решения, а попытка угнаться за большим рынком – к детищу Франкенштейна, собранному из кусочков разных пользовательских сценариев для разных сегментов рынка. Однако даже если вы понимаете нежизнеспособность такого подхода, не факт, что это ясно вашему руководителю, который «надел шляпу предпринимателя».
В корпорациях часто этап анализа рынка, сегментации и выявления потребностей пропускается или выполняется для галочки через заполнение бесполезных шаблонов. Ведь ставка уже сделана, бюджеты защищены, ресурсы выделены, дано обещание выпустить продукт до конца года и получить первую прибыль в краткосрочной перспективе. Начинается этап «пиления фич». Что делать в этой ситуации менеджеру продукта?
Вернемся к нашему стартапу. Итак, как можно описать «пиление фич»?
Во-первых, тогда у меня не было ни знаний, ни ресурсов, чтобы проводить качественные исследования рынка. Основное, что приходило в голову, – сравнить продукты конкурентов, почитать о них отзывы в интернете и скопировать то, что казалось удачным решением. Более того, так же казалось и моему руководителю, а значит, соответствовало его ожиданиям от моей работы.
Во-вторых, мы были под постоянным давлением требований как можно быстрее выпустить готовую версию на рынок и начать продажи. Однако сроки запуска постоянно сдвигались. Как перфекционист, я винила себя в том, что недостаточно хорошо выявляла и описывала требования, ведь они постоянно менялись под натиском новых идей. В течение года мы несколько раз «переобувались» и делали то Service Desk, то систему для поддержки командной работы, то корпоративную электронную почту. Получив выгорание на рабочем месте, я уволилась. Нужно ли говорить, что проект в итоге закрылся примерно через два года после того, как я оттуда ушла.
Процесс работы в описанной мной компании показан на рис. 1.1.
Рис. 1.1. Процесс разработки продукта, пример
В то время многие еще применяли водопадную модель с длинными циклами разработки. Ключевым ограничением была низкая скорость разработки и вывода готового продукта на рынок (time to market). Быстро что-то изменить было не только сложно, но и дорого. Водопадная модель подходит для ситуаций с очень предсказуемыми требованиями или долгосрочными горизонтами планирования, однако для проекта с меняющимися требованиями нужны более гибкие подходы. Надо отдать должное: во всех командах, в которых я работала, мы шли в ногу со временем от водопада навстречу Agile.
В 2001 году появился «Agile-манифест»[4]. Этот подход базируется на четырех ключевых ценностях, которые помогают компаниям стать гибкими.
1. Люди и их взаимодействие важнее, чем рабочие процессы и инструменты.
2. Функционирующий продукт важнее, чем регламенты, написание инструкций, задания.
3. Сотрудничество с заказчиком важнее, чем просто подписание договора.
4. Адаптивность и оперативная реакция важнее, чем слепое следование плану.
Agile подразумевает итеративный процесс, в котором сначала создается базовое решение, которое затем со временем расширяется. Допустим, вы хотите сделать сайт для электронной торговли. В Agile вы не будете тратить месяцы на создание ресурса, вместо этого вы разработаете базовую первую версию – MVP (Minimum Viable Product – минимально жизнеспособный продукт). Возможно, просто страницу, чтобы начать продавать. Затем вы итеративно будете ее усовершенствовать, добавляя все больше разделов и функций. Эти итеративные улучшения называются инкрементами или потенциально готовыми к поставке приращениями продукта (PSPI, Potentially Shippable Product Increment) – ценностью, предоставляемой клиенту через элементы бэклога продукта, которые были выполнены во время спринта.
Agile-манифест на самом деле не описывает выполнение работы, то есть сам процесс. Когда компании решают использовать эти принципы, они должны выбрать его самостоятельно. Можно расценивать Agile как зонтик, под которым находятся процессные фреймворки, соответствующие его принципам и ценностям: Scrum, Kanban, LeSS, SAFe и др. Большинство технологических компаний не следуют ни одному из них буквально, а используют гибридные подходы, ориентированные на практические результаты, в виде набора практик (рис. 1.2).
Рис. 1.2. Agile как образ мышления и набор практик[5]
Мне нравится визуализация Ахмеда Сидки – основателя Международного Agile-консорциума, который изобразил континуум от образа мышления, ценностей Agile-манифеста к принципам и практикам.
Например, существует множество компаний, которые рассматривают гибкую разработку как серию «небольших водопадов». А есть компании с сильной функцией DevOps и микросервисной архитектурой, в которых частота релизов очень высока. В последнем случае начинает размываться смысл самого спринта, и процесс разработки эволюционирует от Scrum к линейному бэклогу и работе с использованием канбан-досок. Я всегда восхищаюсь командами разработки, которые научились выпускать релизы часто, идеальный вариант – несколько раз в день. Это служит важным фундаментом для успешного перехода к продуктовому подходу.
Большинство продуктовых команд работает по Scrum или в гибридном подходе Scrum + Kanban. Основным артефактом для работы становится бэклог продукта – список всех желаемых работ, обычно в виде пользовательских историй (user story), отсортированных в порядке приоритета. Он развивается по мере появления новых требований (или идей в нашем случае). В начале каждого спринта происходит планирование, в результате которого пользовательские истории переносятся из бэклога продукта в бэклог спринта с оценкой объема работ. Затем команда встречается на ежедневном стендапе, где делится ходом работы. В конце спринта проводится его ретроспектива.
Самый популярный фреймворк на данный момент – Scrum Кена Швабера и Джеффа Сазерленда. В его основе лежит идея работы короткими циклами – спринтами, в которых принимают участие и бизнес, и ИТ.
Спринты – регулярные ограниченные промежутки времени, в течение которых Scrum-команда выполняет заданный объем работы. Средняя продолжительность – 2–4 недели. По итогам команда обязуется создать новую версию продукта с приростом ценности для клиента (функционала) – инкрементом. Спринты выпускаются в определенные даты. Все это приводит к упорядочиванию работы ИТ. Поскольку вы действуете итеративно и попутно создаете продукты, вы можете предоставить больше гибкости своим конечным пользователям и клиентам и вовлечь их в процесс разработки и тестирования.
Пользовательская история – короткая формулировка намерения пользователя и того, что продукт должен сделать для него, поддержанная описанием функциональных требований и прототипом интерфейса. Если что-то не добавляет ценности клиенту, то это не может считаться пользовательской историей и будет оставаться задачей, подзадачей или просто требованием.
Формат пользовательской истории выглядит следующим образом: «Как [тип пользователя]; я хочу [некая цель]; так, чтобы [некая причина]». Рассмотрим все пункты подробнее.
• Как [тип пользователя]. В этом разделе указывается, кто пользователь. Это помогает лучше понять его точку зрения и потребности.
• Я хочу [некая цель]. Эта часть описывает, чего пользователь хочет достичь или какую функцию желает видеть в продукте. Она должна быть ясной и краткой, фокусироваться на желаемой функциональности, без подробностей реализации.
• Так, чтобы [некая причина]. Тут объясняется причина цели пользователя. Так мы обеспечиваем контекст и помогаем команде понять основную мотивацию, которая может иметь решающее значение для определения приоритетов и принятия решений.
Например, для сайта интернет-магазина пользовательская история может быть такой.
ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ: ОНЛАЙН-МАГАЗИНКак клиент, я хочу иметь возможность просматривать подробную информацию о продукте, включая изображения, описание, цену и отзывы, чтобы принимать обоснованные решения о покупке.
Критерии приемки
• На странице продукта должны быть качественные изображения высокого разрешения, демонстрирующие продукт под разными углами, обеспечивающие четкое представление о его внешнем виде и функциях.
• Описание должно включать основные характеристики и быть структурировано так, чтобы включать краткую, но подробную информацию о ключевых функциях, спецификациях, размерах, материалах и любых других важных атрибутах, которые влияют на решение о покупке.
• Информация о ценах, включая базовую, любые применимые скидки, рекламные акции или пакетные предложения, должна отображаться на видном месте рядом с описанием продукта.
• Пользователи должны иметь возможность просматривать совокупные рейтинги и читать подробные отзывы тех, кто купил продукт. Система отзывов должна поддерживать материалы, отправленные проверенными пользователями, обеспечивая достоверность и подлинность.
• Клиенты должны иметь возможность фильтровать и сортировать отзывы по релевантности, дате, рейтингу или конкретным критериям.
Пользовательская история дополняется макетом интерфейса и нефункциональными требованиями к производительности, безопасности, отказоустойчивости (если применимо). Пользовательские истории могут быть сгруппированы в эпики, которые, в свою очередь, объединены в инициативы, а инициативы в темы.
Владелец продукта (Product Owner) – это ключевая роль в Scrum, отвечающая за максимизацию ценности продукта, создаваемого командой разработки. Он определяет приоритеты в бэклоге, собирает оценки трудозатрат, взаимодействует с заинтересованными сторонами для определения и удовлетворения их требований.
Все команды помешаны на планировании. Это неудивительно, ведь точные оценки позволяют прогнозировать сроки и бюджет проекта, на которые «коммитятся» владельцы продуктов. Сколько раз я участвовала во встречах, где все спрашивали: «Когда вы реализуете эту фичу?» Коммуникация статуса и сроков крайне важна, ведь по ней оценивается работа команды в фабрике функций.
Для каждой истории (либо в условных единицах – Story Points, либо в человеко-часах) выставляется оценка, которую дают разработчики. Поинты обозначают уровень сложности или трудоемкости реализации элементов бэклога продукта (пользовательской истории): один поинт – простую задачу, два – сложнее и т. д., однако для того, чтобы начать их использовать, необходим накопленный командой опыт разработки. Часто на этом этапе важно дробить истории, чтобы получить более точные оценки.
Для лучшего понимания нужно рассмотреть концепцию скорости работы (velocity). В конце каждого спринта команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены за время спринта. Эта сумма называется скоростью: это количество поинтов, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько поинтов вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество поинтов, а затем сделать вывод, что в среднем ваша команда может, например, набрать 15 поинтов за спринт. Это и есть скорость работы.
Для составления бэклога спринта команда берет пользовательские истории из бэклога продукта и обязуется доставить их за спринт. Это самый нижний уровень, на котором команды устанавливают приоритеты. В релиз (выпуск функциональности для пользователей) обычно попадают истории нескольких спринтов. Календарный план релизов представляет собой дорожную карту, которая часто выглядит как диаграмма Ганта с датами релизов.
Отдельно необходимо поднять вопрос качества планирования спринтов и релизов. Оно измеряется соблюдением сроков и соответствием требованиям пользовательской истории. При этом важно отслеживание качества не только в конце спринта, но и в процессе, а также проведение ретроспективного анализа. Этим тоже занимается владелец продукта.
Рис. 1.3. Пример Burndown Chart
Если скорость команды начинает падать, значит, она неправильно оценивает свои истории: берет на себя слишком много работы или кто-то заставляет ее это делать. Но если команда неожиданно обнаруживает, что у нее появляется много свободного времени, значит, ей следует сделать переоценку своих трудозатрат. Важный инструмент для налаживания темпа и прогнозирования скорости разработки – диаграмма сгорания задач, или Burndown Сhart.
Как следует из названия, диаграмма сгорания задач – это инструмент, показывающий, как быстро команда работает с пользовательскими историями. Они эффективны за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу спринта.
Один из популярных вопросов на собеседованиях: «Что делать, если команда отстает от графика?» Это головная боль владельца продукта и менеджера проекта. Тут можно вспомнить известный треугольник ограничений проекта, также называемый тройным ограничением, железным треугольником (рис. 1.4).
Рис. 1.4. Треугольник ограничений
Вот три основных ограничения (изменение одного из них обычно влияет на два других).
• Объем работ: определяет, что будет реализовано. Изменения объема могут повлиять как на время, так и на стоимость.
• Время: сроки и время, доступные для завершения проекта. Если временные ограничения ужесточены, может потребоваться больше ресурсов (увеличение затрат) или сокращение объема.
• Стоимость: включает бюджет, все ресурсы, необходимые для завершения задач, такие как рабочая сила, материалы, оборудование и накладные расходы. Увеличение бюджета может помочь уложиться в сжатые сроки или расширить объем работ, тогда как сокращение бюджета может потребовать уменьшения объема или продления сроков.
В центре треугольника находится качество, представляющее конечную цель: поддержание критериев приемки, несмотря на ограничения.
Итак, если команда отстает от графика, то допустимо сократить объем задач или перенести сроки запуска, однако это может плохо повлиять на бизнес-результат; добавить больше разработчиков (увеличить стоимость). Однако в последнем случае вы можете столкнуться с «мифическим человеко-месяцем» и законом Брукса – концепцией, которую описал Фред Брукс в своей книге «Мифический человеко-месяц: очерки по разработке программного обеспечения».
Идея добавления разработчиков в проект основана на предположении, что если один человек может выполнить задачу за определенное количество часов, то несколько человек могут выполнить ту же задачу за пропорционально меньшее количество часов. Однако при этом игнорируются сложности и накладные расходы, связанные с командной работой и координацией проекта.
Новым членам команды требуется время, чтобы они стали продуктивными. Это не только отнимает их собственное время, но и отвлекает время существующих членов команды, которым необходимо их обучать и интегрировать. По мере увеличения числа членов команды сложность и время, необходимое для общения и координации, растут в геометрической прогрессии. Каждый дополнительный участник увеличивает количество каналов связи и вероятность недоразумений или несогласованностей. И в целом не все задачи можно легко разделить между несколькими людьми.
Все это во многом исключает возможность реального варианта «сделать хорошо и быстро». В итоге приходится искать компромиссы, сокращать объем работ в угоду качеству, договариваться снова с заинтересованными сторонами.
Еще одним фактором, влияющим на сроки, становится задержка в работе другой команды, от результатов которой зависят ваши сроки. Часто она находится вне зоны контроля и влияния, и вопрос необходимо эскалировать.
Кто все вышеописанное будет делать и отвечать, если возникают сдвиги сроков, выпускается продукт, не отвечающий требованиям, и т. д.? Конечно, владелец продукта.
Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.
В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.
Не стоит недооценивать ценность этой роли в контексте работы в разрозненных организационных структурах, на пересечениях зон влияния и ответственности. Организация представляет собой непростую систему, в которой степень сложности прямо пропорциональна количеству точек принятия решения.
Успешные владельцы продуктов часто помогают заказчикам конкретизировать видение и воплотить его в жизнь, работая со всеми заинтересованными сторонами.
Дело в том, что ресурс ИТ может быть общим (под ресурсом я понимаю сотрудников с необходимой специализацией и опытом: разработчиков, тестировщиков и т. д.) и делиться между множеством бизнес-заказчиков, а может быть выделенным под конкретного бизнес-заказчика.
Первая схема хорошо работает, когда потребность в ресурсе носит временный характер по проектному типу: например, у бизнес-подразделения возникает задача доработать систему под новые требования законодательства. Тогда претендентам на ИТ-ресурс нужно как минимум договориться о правилах его использования. В случае общего ресурса договориться всегда сложнее, поскольку претенденты имеют разные, а иногда и противоречащие друг другу цели.
Вторая схема эффективна, когда потребность в ресурсе постоянна, происходит постоянное улучшение продукта. Тогда создается кросс-функциональная команда. Внутри нее есть полностью выделенные роли: маркетологи, разработчики, тестировщики, дизайнеры, аналитики.
Можно считать, что размер компании – компромисс между производительностью и накладными расходами. Чем больше людей, тем больше задач можно выполнить, но тем больше общения и процессов необходимо для координации.
Например, для реализации одной пользовательской истории в интернет-банке может потребоваться интеграция минимум с тремя системами, за каждую из которых отвечает своя платформенная команда; сама интеграция в худшем случае может строиться напрямую между системами без какого-либо промежуточного слоя, на ресурсы может претендовать еще множество бизнес-заказчиков из бухгалтерии, операционного департамента и т. д. В итоге у нас получается не один, а множество бэклогов, тут возникает типичный вопрос: «Кто, когда, как, зачем сможет вставить эту историю в свой релиз?»
В этом процессе владелец продукта – держатель бэклога, относящегося к конкретной предметной области. Он понимает зависимости, фасилитирует встречи, получает требования и приоритизирует их вместе с заинтересованными сторонами, оценивает трудозатраты вместе с архитекторами и разработчиками и контролирует реализацию в срок в соответствии с бюджетом и критериями приемки, доводит до бизнеса все необходимые статусы по их задачам, контролирует интеграционное тестирование и обучение пользователей и т. д. Часто при этом одной роли владельца продукта недостаточно, нужна еще и роль менеджера проектов.
Вот другой пример. Предположим, что мы хотим создать продукт с нуля на новом рынке. Мы можем не знать многого о рынке и о том, что должен делать продукт, поэтому наличие большой команды приведет к большой путанице в отношении того, что делать и кто должен этим заняться. Типичная команда стартапа – пять человек, два из которых основатели. Понятно, что введение еще одной точки коммуникации в виде владельца продукта добавляет больше проблем и простоев: и так всем все понятно, разработка не требует сложного планирования, встреч и согласований. Все сидят в одной «съемной квартире». Проблемы начинаются, когда менеджер сильно перебарщивает с планированием, замыкает процессы на себе: ни одна работа не выполняется без его разрешения.
Таким образом, размер команды и компании имеет значение: чем крупнее организация, тем больше зависимостей и коммуникационных барьеров в ней образуется. Это неизбежно приводит к увеличению сложности. Организации (особенно в корпорациях) склонны начинать новые проекты с большими командами и долгим согласованием выделения ресурсов, годовыми бюджетными циклами, которые часто подменяют собой стратегию. Бремя координации ложится на владельцев продуктов и менеджеров проектов. В этой ситуации под прицел критики очень часто попадает именно владелец продукта. Ему «припоминают» большое количество непродуктивных встреч, отсутствие ясных и согласованных приоритетов, недостаточную проработку пользовательских историй, прототипов интерфейсов, функциональных требований, «поехавшие» релизные сроки и т. д. Вот только он не может устранить те ограничения, которые не находятся в зоне его влияния.
Применение принципов Agile, внедрение Scrum-ритуалов еще не означает, что команда приносит ценность клиенту и бизнесу, а не является фабрикой функций. Конечно, важно, чтобы к началу планирования спринта были проработаны все пользовательские истории, прототипы интерфейсов, функциональные требования и т. д. Но, даже несмотря на это, часто владелец продукта не понимает, как оценить влияние задачи на бизнес, а также уверенность в достижении оного. Ему приходится снова и снова встречаться с руководителями коммерческого блока для уточнения требований и оценок. Последние, в свою очередь, воспринимают это общение как обузу, отвлекающую их от главных задач. При этом все, конечно, понимают, что постановка внутри спринтов не может меняться, но тут и там возникают дополнительные задачи в формате «мы потеряем клиента, если не сделаем этого», «Иван Петрович позвонил и сказал…» и др.
Неорганизованный подход и «заваливание» ИТ разрозненными задачами долго воспринимались как приемлемая модель взаимодействия. Однако происходит то, что становится катализатором перемен, когда перед коммерческим блоком стоит задача сформулировать амбициозную стратегию и реализовать ее. Это, например, рыночные изменения, натиск конкурентов, стагнация доходов или их отсутствие, смена топ-менеджмента. В этот момент происходит поиск нового формата кросс-функционального взаимодействия для быстрого достижения бизнес-результатов, который учтет ключевые области бизнеса, такие как стратегия, бизнес-модель, рыночная конкуренция, а не только разработку. В этот момент появляется запрос на роль менеджера продукта.
Многие стали задаваться вопросом: почему компания не может работать как стартап, который, как мы знаем по Стиву Бланку, «не уменьшенная версия большой компании»?
В XX веке инвесторы, по сути, говорили стартапам, что они уменьшенные версии крупных компаний. Но потом в США лопнул «пузырь доткомов»: новые бизнес-модели оказались неэффективными, а средства, потраченные в основном на рекламу, и большие кредиты привели к волне банкротств, сильному падению индекса NASDAQ. Выжили только те компании, у которых имелись устойчивые бизнес-модели. Внезапно инвесторы стали избегать риска и искать доказательства соответствия продукта рынку.
В это время появились методология Lean Startup и концепция Customer Development, книги Стива Бланка, Дэна Олсена, Марти Кагана, Эрика Риса. Ключевая идея их такова: необходимо сначала создать гипотезы относительно бизнес-модели, протестировать в экспериментах и только потом принимать решение о разработке.
В то время как крупные компании реализуют бизнес-модели, стартапы фактически ищут бизнес-модели, тестируя основные предположения (в этом суть Customer Development). В таблице 1.1 приведены ключевые отличия стартапа от зрелой компании.
Стартапы и те, кто занимается разработкой новых продуктов, уделяют большое внимание концепции Product-Market Fit. Если задача стартапа состоит в том, чтобы найти жизнеспособную бизнес-модель, то поиск соответствия продукта рынку считается результатом этих изысканий. В стартапах это часто означает, что до PMF вы направляете инвестиции в первую очередь на фазу поиска и развития клиентов.
После того как вы достигли PMF, вы переходите к этапу, который влечет за собой создание и построение компании. Этот сдвиг для стартапов часто может быть связан с новым инвестиционным раундом, когда новое вливание капитала будет использовано для масштабирования продаж и маркетинговых усилий бизнеса.
Для поиска PMF используется итеративный подход Learn, Build, Measure (научиться, создать, измерить). Это цикл, который делает упор на скорость как на важнейшую составляющую развития продукта (рис. 1.5).
Рис. 1.5. Цикл Learn, Build, Measure
Продуктовый менеджмент не рассматривается как линейный путь от точки А до точки Б. Он представляет собой непрерывный цикл тестирования гипотез.
Результативность в поиске PMF определяется способностью генерировать идеи, создавать эксперименты, измерять ее эффективность на рынке и извлекать уроки из этого эксперимента. Другими словами, это цикл обучения превращению идей в продукты, измерения реакции клиентов на созданные продукты и их поведения, а затем принятия решения о том, продолжать ли воплощать идею или изменить ее; этот процесс повторяется столько раз, сколько необходимо.
В цикле присутствует понятие гипотезы и MVP (Minimum Viable Product) – минимально жизнеспособного продукта. Разберемся, что это такое.
О чем-то мы точно знаем, что это правда; что-то можем только предполагать. Перед проведением эксперимента важно иметь четкую проблему, которую вы пытаетесь решить. Это может быть что угодно: от улучшения пользовательского опыта до повышения коэффициента конверсии или снижения оттока. Как только вы определили проблему, пришло время сформировать гипотезу. Гипотеза – предположение, сделанное на основе ограниченных доказательств в качестве отправной точки для дальнейшего исследования и принятия решения. Она должна быть конкретной, измеримой и поддающейся проверке.
Каждый раз, когда вы выпускаете новую функцию, запускаете маркетинговую кампанию или пробуете новый метод продаж, вы проводите эксперимент. Это ключевая деятельность для непрерывных инноваций.
Для проверки продуктовых гипотез доступен широкий спектр методов. Исследования пользователей делятся на два подмножества: качественные, которые помогут вам глубже понять, почему пользователи ведут себя определенным образом, и количественные, которые валидируют предположения, выработанные на основе качественных исследований, используя аналитические методы, такие как опросы или измерение определенных метрик (табл. 1.2).
Люди, которые не до конца понимают разницу между качественными и количественными исследованиями, часто считают, что первые из-за маленького размера выборки могут исказить результаты и привести к неправильным выводам.
Качественные данные предоставляют богатое, детальное понимание сложных явлений и процессов. Они стремятся не к статистической значимости, а скорее к концептуальному пониманию. Количественные данные предоставляют статистические выводы, которые можно обобщить на более широкую популяцию. Качественные исследования играют ключевую роль в разработке новых гипотез, которые затем могут быть проверены количественными методами.
Мы также можем выделить два подхода к исследованию пользователей.
• Исследования отношения (Attitudinal) – путем задавания вопросов пользователям об их мыслях, чувствах и мнениях о продукте (например, интервью, фокус-группы).
• Исследования поведения (Behavioral) – непосредственное наблюдение за взаимодействием пользователей с продуктом и получение данных об их поведении. Наиболее часто используемые: юзабилити-исследования, Eye Tracking (где и как долго пользователь смотрит на различные области экрана), продуктовая аналитика (оценка активности пользователей внутри продукта), A/B-тестирование (сравнивает две версии веб-страницы или функции приложения, чтобы определить, какая работает лучше с точки зрения вовлеченности пользователей, коэффициентов конверсии или других поведенческих показателей).
В совокупности эти подходы предлагают целостное представление о пользовательском опыте, сочетая то, что пользователи говорят, с тем, что они делают.
Проведение исследований приводит к тому, что команда начинает аргументировать свои действия, основываясь на данных. Понятно, что это требует дополнительных ресурсов. Когда они ограниченны, вы не можете позволить себе роскошь детально изучить все, что можно, поэтому возникает задача приоритизации гипотез, оценки потенциального влияния на бизнес-результат и быстрой проверки на небольшой группе целевых клиентов. Это нужно, чтобы получить обратную связь как можно быстрее, доказать, что команда идет в верном направлении, увеличить свои шансы на успех.
Один из способов проверки гипотезы о жизнеспособности продукта – создание MVP. Кажется, что сам термин выбран неверно, поэтому появилось множество статей на тему того, что стоит использовать – MLP (Minimum Loveble Product) или Minimum Viable Process и т. п. Видимо, неоднозначность термина рождает широкий набор интерпретаций. А поскольку нет одной универсальной интерпретации, дискуссии о том, что это такое, не останавливаются.
Существует каноническое определение MVP по Эрику Рису.
MVP – любое предложение или возможность, которые требуют наименьших усилий для создания, но при этом дают организации наибольшую возможность узнать о клиентах.
MVP предназначен не для продажи или получения дохода, а для быстрого обучения. Соответственно, product в этой аббревиатуре – вовсе не конечный пользовательский продукт. Тут все зависит от стадии работы. На этапе проектирования это может быть интерактивный прототип для показа потенциальному клиенту. Многое зависит от ключевых гипотез и уровня достоверности, который нужно получить, ресурсов, которые вы готовы потратить на проверку, скорости получения обратной связи от рынка.
MVP должен в первую очередь сосредоточиться на проверке самых рискованных предположений. Пример, который всегда вдохновляет меня: MVP DropBox Video Explainer. В то время у DropBox не было продукта. Вместо этого они создали простое видео для сообщества первых пользователей, чтобы продемонстрировать, как должно работать решение. В результате их список ожидания бета-тестирования увеличился с 5000 до 75 000 человек за одну ночь.
Еще один вариант MVP – лендинг с описанием ценностного предложения, затем запуск рекламы на небольшой объем целевого рынка и отслеживание конверсии в целевые действия на лендинге, чтобы ответить на вопрос, сколько пользователей можно конвертировать в заявку и оплату. Так когда-то давно поступил Джефф Безос. Он рассказывал, что ключевое рискованное предположение, которое он хотел проверить в самом начале, заключалось в том, сможет ли Amazon конкурировать с книжными магазинами. Вместо того чтобы купить гору книг и арендовать склад, он создал сайт и выставил на нем книги, которых у него не было. Когда клиенты заказывали товар, он покупал книги в магазине и отправлял их по почте.
Важная цель Lean Startup – проверить фундаментальные бизнес-гипотезы для создания жизнеспособной бизнес-модели еще до начала полномасштабной разработки. Но как этот подход внедряется в компаниях, которые уже не стартапы?
Глава 2. Продуктовый подход в компаниях
Традиционные компании были сгруппированы в функциональные бункеры: разработчики находятся в одном месте, менеджеры проектов – в другом, продавцы – в третьем. То же касается всех остальных подразделений. Коммуникация и передача данных между каждым бункером требует времени: бизнес-аналитики должны общаться и объяснять требования разработчикам; тем необходимо задокументировать функции для отдела тестирования и получить одобрение системных архитекторов; менеджеры проектов должны опрашивать людей, чтобы обновить статус проекта, и т. д. Когда вы принимаете ежедневные решения о продукте, вся эта координация подразумевает огромные накладные расходы.
ПРИТЧА О СЛОНЕЗнаменитая индийская притча описывает пятерых слепых, впервые встретивших слона. Каждый из них ощупывает разную часть животного и приходит к разным выводам о том, что такое слон, основываясь на своем ограниченном опыте.
Первый слепой человек трогает бок слона и говорит: «Слон похож на стену».
Второй слепой чувствует бивень и заявляет: «Нет, слон похож на копье».
Третий слепой, держа хобот, настаивает: «Вы все неправы. Слон похож на змею».
Четвертый слепой трогает ногу и говорит: «Очевидно, что слон похож на дерево».
Пятый слепой, ощупывая ухо, заключает: «Слон похож на веер».
Каждый из слепых людей прав на основе своего ограниченного опыта, но никто из них не имеет полного представления о том, что такое слон. Притча иллюстрирует идею о том, что наши восприятия и убеждения могут быть ограниченными, а для понимания полной истины необходимо учитывать разные точки зрения. Я вижу, что эту историю часто используют для описания дисфункции организации. Функциональные бункеры поощряют локальную оптимизацию: каждое подразделение сосредоточено на выполнении своей части работы, а не на обеспечении успешного общего результата, поэтому лучшей практикой будет создание кросс-функциональных продуктовых команд.
Вместо того чтобы распределять ответственность между множеством разных групп, все роли, необходимые для «владения» продуктом, возлагаются на одну команду. Она полностью посвящает себя продукту и получает доверие и полномочия принимать решения о продукте. В свою очередь, они несут ответственность за запуск продукта и его бизнес-результаты.
Продуктовая команда – это группа специалистов, объединенных для работы над созданием и развитием конкретного продукта. Такие команды, как правило, включают представителей различных функций, таких как разработка, маркетинг, дизайн, аналитика и управление продуктом, что позволяет им эффективно и комплексно подходить к решению задач, связанных с продуктом.
Основные характеристики продуктовых команд следующие.
Долгосрочность и стабильность
Продуктовые команды обычно существуют длительное время, не меняются постоянно по объему и/или составу. Это позволяет им развивать глубокие знания в области технологий, клиентов и отрасли.
Назначение бизнес-проблем и клиентов
Каждой продуктовой команде нужен фокус на предметной области – зоне влияния, за которую команды несут ответственность (за достижение определенных результатов). Команды могут фокусироваться на определенных сегментах клиентов, что позволяет лучше понимать их потребности и ожидания.
Мультифункциональность
Команда состоит из специалистов разных областей (разработчики, дизайнеры, маркетологи, менеджеры продукта и т. д.), что обеспечивает комплексный подход к разработке и улучшению продукта. Они тесно сотрудничают, чтобы определить и реализовать наилучшее решение для достижения целей продукта.
Фокус на клиентов и продукт
Основная цель команды – создание, развитие и поддержка конкретного продукта. Это означает, что все усилия и ресурсы направлены на улучшение продукта и удовлетворение потребностей пользователей. Менеджеры по продукту глубоко понимают, как клиенты выбирают и используют продукт, знают рынок, конкурентов и современные технологии, что позволяет им формулировать стратегию и приоритеты для достижения успеха.
Разработка не передается на аутсорсинг
Разработка не передается на аутсорсинг, так как это ключевая способность, обеспечивающая конкурентное преимущество. Собственные разработчики лучше понимают требования, могут быстрее реагировать на их изменения, хорошо понимают продукт, его архитектуру и технические особенности.
Ни один план не выдерживает первого контакта с клиентами.
Стив Бланк
Работа в продуктовых командах представляет собой процесс, который часто делят на два этапа: исследования (Discovery) и разработка (Delivery). Это так называемый двойной ромб или алмаз. Нередко команды хотят внедрить этап исследований из-за усталости от разработки большого количества функций, которые никому не нужны и не способствуют достижению бизнес-целей. Этот подход фокусируется на изучении рынка, быстром тестировании гипотез, проверке концепций продуктов (как минимум с помощью интервью, создания прототипов и юзабилити-тестов с реальными пользователями). Процесс заранее отфильтровывает менее жизнеспособные решения, позволяя сосредоточиться на наиболее ценных функциях, которые нужны клиентам и бизнесу. А вот процесс разработки концентрируется на воплощении проверенных идей в продуктах.
На самом деле процесс еще сложнее. Без системных продуктовых исследований нельзя создать стратегию, которая бы не напоминала галлюцинацию команды. Исследования встраиваются в стратегический цикл.
Вы когда-нибудь сталкивались с подобными ситуациями?
• «Да, мы проводим ежеквартальные опросы удовлетворенности клиентов (CSAT) и Net Promoter Score (NPS), но кажется, что на их основе мы не предпринимаем никаких действий».