Читать книгу: «Управление продуктом. Российская практика», страница 3

Первая схема хорошо работает, когда потребность в ресурсе носит временный характер по проектному типу: например, у бизнес-подразделения возникает задача доработать систему под новые требования законодательства. Тогда претендентам на ИТ-ресурс нужно как минимум договориться о правилах его использования. В случае общего ресурса договориться всегда сложнее, поскольку претенденты имеют разные, а иногда и противоречащие друг другу цели.

Вторая схема эффективна, когда потребность в ресурсе постоянна, происходит постоянное улучшение продукта. Тогда создается кросс-функциональная команда. Внутри нее есть полностью выделенные роли: маркетологи, разработчики, тестировщики, дизайнеры, аналитики.

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

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

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

Вот другой пример. Предположим, что мы хотим создать продукт с нуля на новом рынке. Мы можем не знать многого о рынке и о том, что должен делать продукт, поэтому наличие большой команды приведет к большой путанице в отношении того, что делать и кто должен этим заняться. Типичная команда стартапа – пять человек, два из которых основатели. Понятно, что введение еще одной точки коммуникации в виде владельца продукта добавляет больше проблем и простоев: и так всем все понятно, разработка не требует сложного планирования, встреч и согласований. Все сидят в одной «съемной квартире». Проблемы начинаются, когда менеджер сильно перебарщивает с планированием, замыкает процессы на себе: ни одна работа не выполняется без его разрешения.

Таким образом, размер команды и компании имеет значение: чем крупнее организация, тем больше зависимостей и коммуникационных барьеров в ней образуется. Это неизбежно приводит к увеличению сложности. Организации (особенно в корпорациях) склонны начинать новые проекты с большими командами и долгим согласованием выделения ресурсов, годовыми бюджетными циклами, которые часто подменяют собой стратегию. Бремя координации ложится на владельцев продуктов и менеджеров проектов. В этой ситуации под прицел критики очень часто попадает именно владелец продукта. Ему «припоминают» большое количество непродуктивных встреч, отсутствие ясных и согласованных приоритетов, недостаточную проработку пользовательских историй, прототипов интерфейсов, функциональных требований, «поехавшие» релизные сроки и т. д. Вот только он не может устранить те ограничения, которые не находятся в зоне его влияния.

Применение принципов Agile, внедрение Scrum-ритуалов еще не означает, что команда приносит ценность клиенту и бизнесу, а не является фабрикой функций. Конечно, важно, чтобы к началу планирования спринта были проработаны все пользовательские истории, прототипы интерфейсов, функциональные требования и т. д. Но, даже несмотря на это, часто владелец продукта не понимает, как оценить влияние задачи на бизнес, а также уверенность в достижении оного. Ему приходится снова и снова встречаться с руководителями коммерческого блока для уточнения требований и оценок. Последние, в свою очередь, воспринимают это общение как обузу, отвлекающую их от главных задач. При этом все, конечно, понимают, что постановка внутри спринтов не может меняться, но тут и там возникают дополнительные задачи в формате «мы потеряем клиента, если не сделаем этого», «Иван Петрович позвонил и сказал…» и др.

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

LEAN STARTUP И ЕГО ВЛИЯНИЕ НА УПРАВЛЕНИЕ ПРОДУКТОМ В КОМПАНИЯХ

Многие стали задаваться вопросом: почему компания не может работать как стартап, который, как мы знаем по Стиву Бланку, «не уменьшенная версия большой компании»?

В XX веке инвесторы, по сути, говорили стартапам, что они уменьшенные версии крупных компаний. Но потом в США лопнул «пузырь доткомов»: новые бизнес-модели оказались неэффективными, а средства, потраченные в основном на рекламу, и большие кредиты привели к волне банкротств, сильному падению индекса NASDAQ. Выжили только те компании, у которых имелись устойчивые бизнес-модели. Внезапно инвесторы стали избегать риска и искать доказательства соответствия продукта рынку.

В это время появились методология Lean Startup и концепция Customer Development, книги Стива Бланка, Дэна Олсена, Марти Кагана, Эрика Риса. Ключевая идея их такова: необходимо сначала создать гипотезы относительно бизнес-модели, протестировать в экспериментах и только потом принимать решение о разработке.

В то время как крупные компании реализуют бизнес-модели, стартапы фактически ищут бизнес-модели, тестируя основные предположения (в этом суть Customer Development). В таблице 1.1 приведены ключевые отличия стартапа от зрелой компании.

Таблица 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).

Таблица 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), но кажется, что на их основе мы не предпринимаем никаких действий».

• «Мы провели замечательное исследование рынка в прошлом году, но не могу вспомнить ни одного стратегического изменения, которое последовало бы за этим».

• «Мы провели детальное исследование конкурентной среды и выявили новые рыночные ниши. Однако отдел продаж продолжает следовать старым стратегиям, так как новое руководство не предоставило четких инструкций по использованию полученных данных».

Что здесь не так? Почему компании тратят ресурсы на качественные исследования, но не используют их результаты?

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

Это лечится, если создать систему, в которой данные исследований приходят тогда, когда они могут быть использованы командой. Тут есть очень хороший вопрос для проверки: «Что бы мы сделали по-другому, основываясь на результатах исследования?»

Удобно представить весь процесс в виде четырех ромбов, как показано на рис. 2.1.

Рис. 2.1. Процесс разработки продукта

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

Разработка продуктовой стратегии

По словам Стива Джобса, люди думают, что сосредоточиться – значит сказать «да» тому, на чем нужно сфокусироваться. Но это совсем не так. Это значит сказать «нет» сотне других хороших идей. Выбирайте тщательно. Гордиться можно и тем, что сделано, и тем, что не сделано. А при внедрении инноваций приходится отказаться от тысячи идей. Во-первых, для любой заданной проблемы довольно легко угадать множество возможных решений. Например, низкое удержание продукта может быть связано с плохим UX, плохим маркетингом, плохими функциями или производительностью и т. д. Поскольку тестирование каждого решения требует времени и усилий, как вы определяете приоритеты? В этом заключается вторая задача. Мы часто выбираем решения, которые поддерживают наши уже сложившиеся взгляды. Разработчики стремятся создавать больше фич, дизайнеры – делать визуально привлекательный интерфейс, а маркетологи – привлекать больше лидов. Это отражает проблему узкой специализации.

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

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

Продуктовая стратегия отвечает на ряд вопросов.

• На каких рынках, в каких сегментах компания будет конкурировать?

• Как компания собирается побеждать в выбранных сегментах рынка?

• Почему клиенты выберут нас?

• Какая бизнес-модель нам необходима для успеха?

Продуктовая стратегия должна задавать направление исследованиям. Когда вы изучаете продукт без стратегического видения (сознательный выбор того, где вы будете играть на рынке и какую ценность можете предложить), вам будет сложно затем определить приоритеты в проблемах и собрать информацию о том, что сильнее всего повлияет на бизнес-результат.

Например, если банк планирует разработать стратегию, чтобы завоевать рынок поколения Z в течение следующих трех лет, продакт-менеджер должен сосредоточить усилия на изучении их уникальных привычек управления финансами. Видение и стратегия создают фокус. Если у команды есть цели (OKR/KPI), она проводит исследования, чтобы выявить ключевые пользовательские или технические проблемы, становящиеся барьерами в достижении этих целей.

Запараллеливание исследований и разработки

Хотя процессы исследований и разработки происходят параллельно, они тесно интегрированы за счет постоянного общения и общих целей, описанных в дорожной карте (подробнее об этом инструменте рассказано в главе 16). Полученная в рамках исследований информация влияет на дорожную карту продукта и приоритизацию бэклога (рис. 2.2).

Рис. 2.2. Параллельные спринты исследований и разработки

Такой подход требует новых компетенций, выделяется роль менеджера продукта (уже не владельца). От него ожидают, что он будет тратить время не только на глубокий анализ требований в пространстве решений и задавать вопросы «Что?», «Когда?», «Как?», но и оспаривать статус-кво для проверки проблемного пространства и ставить вопрос «Почему?».

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

После проверки предположений вы можете захотеть реализовать полноценное решение. Проводите более надежные эксперименты, чтобы понять, что работает, а что нет. Как только вы нашли решение, которое стоит создать, пришло время сосредоточиться на его правильной доставке и приоритизировать бэклог. Целью разработки будет не добавление новых функций в продукт, а повышение ценности для клиентов и бизнеса. Многие люди неправильно понимают разработку как просто исполнение. Сначала сделайте решение доступным для небольшой части вашей клиентской базы. Постоянно измеряйте результаты и адаптируйтесь для достижения желаемых результатов.

Таким образом, исследования обнаруживают то, что создает ценность, а разработка продукта создает то, что приносит ценность.

Для исследований и дизайна требуется время, поэтому исследователи и дизайнеры идут со своими задачами на несколько спринтов впереди разработчиков, чтобы успевать исследовать, проверять и уточнять идеи до того, как они перейдут на стадию разработки. Цель в том, чтобы гарантировать, что команда создает правильный продукт, отвечающий потребностям пользователей и бизнес-целям. Такой подход еще называют Dual Track Agile, он представляет два параллельных потока работы: исследования и разработку.

РОЛИ В ПРОДУКТОВОЙ КОМАНДЕ

Для поддержания процессов открытия и реализации и балансирования ресурсов создаются команды, которые могут относительно автономно выводить продукты на рынок. Это позволяет им быстро выполнять поставленные задачи, а поскольку они трудятся параллельно с другими командами, организация может легко масштабироваться, если хочет увеличить производительность. Полный список ролей продуктовой команды сводится к следующим (адаптируется под потребности конкретной команды).

• Продуктовый менеджер – формирует видение продукта, управляет исследованиями, приоритизирует гипотезы и бэклог.

• Исследователь – проводит качественные и количественные исследования для поддержки стратегических решений.

• Продуктовый аналитик – анализирует данные пользовательского поведения и проводит количественные исследования для принятия обоснованных продуктовых решений.

• UX/UI-дизайнер – создает прототипы и дизайн пользовательского интерфейса для обеспечения удобства использования и визуальной привлекательности.

• Технический руководитель – определяет техническую стратегию, контролирует техническую осуществимость решений и координирует разработку.

• Архитектор ПО – разрабатывает архитектуру системы, устанавливает технические стандарты и руководит архитектурными решениями.

• Менеджер проекта – управляет проектными процессами, планирует работы и обеспечивает командную координацию.

• Бизнес-аналитик / системный аналитик – анализирует бизнес-требования, переводит их на технический язык и помогает выстраивать стратегические направления разработки.

• Разработчик – создает функциональность продукта в соответствии с техническими требованиями.

• QA-инженер – проверяет качество и функциональность продукта, обеспечивает высокий уровень исправности и надежности.

• Технический писатель – разрабатывает техническую документацию и обучающие материалы для пользователей и разработчиков.

• DevOps-специалист – обеспечивает непрерывную интеграцию и доставку продукта (CI/CD, Continuous Integration / Continuous Delivery), автоматизирует процессы развертывания и мониторинга.

• Scrum-мастер и Agile-коуч – поддерживают и сопровождают команду в применении принципов Agile и методологий разработки.

• Специалист по маркетингу продукта – разрабатывает стратегии маркетинга, продвижения и анализа рынка для успешного внедрения продукта.

• Контент-менеджер – управляет контентом продукта, обеспечивает его актуальность и соответствие бизнес-задачам.

• Специалист по поддержке пользователей – обеспечивает качественную поддержку пользователей, помогает в решении проблем и собирает обратную связь для улучшения продукта.

Нетрудно заметить, что количество членов команды увеличивается, а фонд оплаты труда растет процентов на тридцать, не включая дополнительные расходы на обучение, административные издержки и необходимость внедрения дополнительных систем управления. Насколько это оправданно?

Я много раз встречалась с ситуацией защиты бюджета на расширение команды. Первоочередной задачей является объяснение того, как расширение команды соответствует стратегическим целям компании и продукта. Это включает в себя обсуждение планов на будущее, направленных на укрепление рыночных позиций, введение новых продуктов или услуг, улучшение обслуживания клиентов и так далее, со списком конкретных стратегических инициатив, которые требуют дополнительных ресурсов и расширения команды. Важно представить анализ текущих вызовов: это может быть недостаточная скорость разработки, недостаточное качество продуктов или услуг, необходимость ввода новых технологий, а также метрики, которые демонстрируют ожидаемые результаты от расширения команды.

Запомните, расширение команды – это следствие стратегической необходимости, а не произвольное увеличение численности, потому что «много работы».

ПРЕОДОЛЕНИЕ БЮРОКРАТИИ И КАРГО-КУЛЬТА: РЕАЛЬНЫЕ ШАГИ К ПРОДУКТОВОЙ ТРАНСФОРМАЦИИ

Самая большая опасность в периоды турбулентности – не сама турбулентность, а действие с логикой вчерашнего дня.

Питер Друкер

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