6 инсайтов о том, как выстроить команду при продуктовом подходе

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

За годы работы интегратором и разработчиком собственного продукта у нас сложился «золотой стандарт» продуктовой команды. Цифровой актив в нём составляют: CPO, CIO, CDO, CTO (chief information, data и technical officers), отвечающие за все платформы и обеспечение технической и инфраструктурной стороны процесса трансформации.

Ключевые роли в команде такие:

Главный по продукту – CPO (Chief Product Officer) – разрабатывает бизнес-модель, создаёт условия взаимодействия команд разработки, маркетинга и продаж, обеспечивает успех продукта на рынке.

За корпоративную культуру отвечает директор по персоналу – HRD. Он нанимает людей с нужными компетенциями, которые создают продуктовую культуру в коллективе.

Если бизнес решается не только на создание отдельных цифровых продуктов, но и на полную цифровую трансформацию, то компании необходима роль CDTO (Chief Digital Transformation Officer). Его ключевая компетенция – находить для компании способы зарабатывать деньги путём внедрения новых процессов и технологий, а также трансформации продуктовой культуры.

Идеальный состав не всегда удаётся собрать в рамках собственной компании, но digital-интеграторы помогают заместить необходимые функции.

Ниже я собрал несколько инсайтов.

Инсайт 1: управлять продуктом должна зрелая команда (в том числе со стороны заказчика)

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

Простой пример: некая компания предложила работать по agile – объединить свою и нашу команды в одну, а все вопросы решать на митингах. Мы предостерегли:

• На вас работает 25 человек из нашей команды. Вы точно хотите, чтобы все сидели на митингах?
• Да, разумеется.
• Вы понимаете, сколько стоит час работы специалиста?
• Да, безусловно.

Результат? Всё быстро закончилось, когда в конце заказчик увидел, что от 25 до 50 часов всей работы за месяц уходило только на митинги! При том, что организованы они были плохо и оказывались неэффективными. В итоге заказчику пришлось согласиться с тем, что daily-митинги необходимо трансформировать.

Как интегратор, мы часто сталкиваемся с ситуациями, когда компании пытаются закупить продуктовую команду, внедряют agile, но делают это, к сожалению, не всегда осознанно и корректно. Базовые вещи понятны всем, но дьявол, как обычно, скрыт в деталях: в понимании бизнес и продуктовых метрик, мэтче бэклога, приоритизации, выделении MVP и других. Всё это становится камнем преткновения, и фича делается ради фичи, а ключевой результат достигается медленно.

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

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

Инсайт 2: CPO или PO – это мини-CEO?

В нише актуальна дискуссия: а кто вообще такой product owner? Если говорить «по учебнику», то это такой мини-CEO. Прежде всего, product owner отвечает за P&L: доходы, расходы, продукт. То есть, по сути, за экономику: он должен убедиться, что его продукт приносит деньги, либо идёт по правильному треку, который эти деньги принесёт, либо сэкономит.

На практике product owner часто становятся условные вчерашние проджект-менеджеры, на которых возложена те же функции: управление задачами, управление командами и процессами. И здесь идёт разрыв в понимании, функционале и конечном результате, который мы хотим получить для бизнеса.

Инсайт 3: ключевую экспертизу не аутсорсят

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

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

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

Инсайт 4: покупать agile по «водопаду» не получится

Типовой запрос к нам звучит примерно так (особенно от госов): «А давайте мы сыграем тендер по ФЗ-223 или по ФЗ-44, где мы зафиксируем с вами объём работ, деньги и сроки, зафиксируем конкретную ответственность за их невыполнение или неисполнение». Но при первой же встрече слышим: «А давайте мы будем работать по agile (ведь мы же современные ребята). Давайте построим продуктовую команду на full-time, они будут сидеть у нас в офисе, работать, что-то анализировать. Мы будем придумывать, работать с фичами, управлять изменениями. А ещё мы сходим во все подразделения, они нам расскажут, что они хотели (в функциональном задании мы же расписали только общее направление мысли). А вообще-то, ТЗ было написано два года назад, оно вообще устарело».

Если вы действительно хотите строить у себя agile, то первое, что нужно сделать, – это осознать и понять, что он несёт риски с точки зрения увеличения бюджетов и при неправильном управлении можно вылететь в трубу, особенно если не управлять изменениями и дать всем возможность влиять на бэклог. А если вы хотите закрыть страхи, то, покупая что-то по классической модели, вы будете получать соответствующий результат. Будьте готовы к множеству вопросов и возражений, например, это не входило в стоимость работ, надо увеличивать сроки, деньги и так далее.

Фиксированные проекты дают возможность закрыть риски со стороны команды заказчика, так как результат уже описан, деньги и сроки зафиксированы. Но не даёт возможности тестировать гипотезы, изменять продукт и делать дополнительные фичи, которые могут столь быстро в изменяемом мире рождаться у вашего конкурента.

Инсайт 5: спрос на data driven подход, дашборды и данные

Когда мы говорим о цифровизации, мы подразумеваем, что она обязательно основывается на скорости обращения знаний, то есть данных. Сейчас этому уделяется много внимания: управлению функциями и компаниями на основе данных, повышению эффективности с помощью управления знаниями, а также потенциалу людей – разработке корпоративных порталов, систем управления знаниями или microlearning-систем. И чем лучше и качественнее управление ими, тем лучше и качественнее получается делать прогнозы, строить продуктовые метрики. В этом процессе на первый план выходит роль CDO (Chief Data Officer), главного по управлению данными.

В любой компании есть 20–30 стейкхолдеров, и каждый пытается повлиять на изменение или продвижение каких-то своих пожеланий в бэклог. Не все они коррелируют друг с другом, и не все влекут повышение или уменьшение метрик – за этим важно следить. Например, мы стараемся в каждом проекте строить подход таким образом, что у клиента появляется матрица, где сверху метрики, на которые он хочет влиять (например, на лояльность, повышение маржи или сокращение расходов, увеличение доходов, повышение конверсии и т. д.), а по вертикали – набор функций. И когда мы говорим о том, что мы берём или не берём функцию в следующий спринт, мы должны всегда ответить на вопросы: «А на какую метрику она влияет?», «А сейчас зачем она нужна, что мы хотим сделать?». Такой дашборд помогает наглядно увидеть, как тестирование гипотез и внедрение фич влияют на ключевые метрики продукта.

Инсайт 6: сначала надо перестроить культуру, а потом структуру

Прежде чем перестраивать структуру компании, надо сначала выстроить продуктовую культуру, научить команды правильным подходам к разработке. К сожалению, в этом случае просто нанять CDTO, или CDO, или CPO на практике не работает.

Простой пример на применение больших данных в компании. Есть классная поговорка: «Если Excel долго мучить, то он покажет то, что вы хотите». Особенно это проявляется, когда речь идёт о принятии решений.

Здесь на помощь приходит дашборд и показывает: смотрите, у нас здесь есть проблема, которая приводит к существенным потерям, а здесь мы можем оптимизировать и сэкономить ресурсы и т.д.

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

Если акционеры, собственники компании или СЕО не вовлечены и не заинтересованы в преобразовании продуктовой культуры – сборке продуктовых команд, процессов, подходов, внедрения agile-практик и т.д., то вряд ли что-то получится. Либо придётся сильно усердствовать и добиваться того, что приведёт к результату.