Как построить работу с продуктовой командой

Рынок российских IT-технологий продолжает расти — к 2030 году его объем достигнет 7 триллионов рублей. На волне этого многие крупные компании создают собственные IT-департаменты, активно расширяют существующие и начинают все больше нанимать разработчиков в штат. Однако большая доля рынка по-прежнему принадлежит интеграторам — компаниям, которые работаю на заказ и помогают брендам оцифровывать бизнес.

Один из крупнейших диджитал-интеграторов в России — компания AGIMA. Ее основатель Александр Богданов рассказал, как должно быть устроено взаимодействие между интегратором и продуктовой командой бренда, чтобы оно было выгодно заказчику.

Что такое продуктовые команды и зачем они современным компаниям

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

Главное, что поменялось — это способы управления командами разработки и архитектура этих команд. Поменялись роли, поменялась ответственность, поменялись подходы. Да и сам объем интернет-проектов сильно вырос.

Как изменились подходы?

Раньше все разрабатывали по Fixed Price, то есть по фиксированной цене. Были какие-то понятные этапы, Waterfall-процесс: сначала проектирование, потом дизайн, потом верстка, разработка и запуск. Затем все дружно перешли к гибким методологиям. Стало модно делать проекты по Agile, сажать Scrum-команды. При этом и срок может быть гибким, и то, что ты получаешь за этот срок, тоже становится гибким. Бюджет тоже перестает быть фиксированным.

И к чему мы пришли сейчас?

А сейчас все стали собирать продуктовые команды. Причем собирать их начали внутри заказчика. Раньше ставка на интернет-проекты была не очень высокой. Можно было взять команду на аутсорс, пока инхаус-команда развивает бизнес в офлайне. Но со временем интернет стал значительно важнее для бизнеса. И компании начали строить у себя собственные продуктовые команды.

Что такое продуктовая команда?

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

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

С этим понятно. Какие еще особенности?

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

Выходит, продуктовая команда отличается от проектной структурой?

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

Как их приоритизируют?

Способов много. Мы используем самый, на мой взгляд, рациональный — с ориентацией на ROI (коэффициент рентабельности инвестиций). То есть мы смотрим, сколько фича будет стоить в разработке и сколько денег она, по идее, принесет. Обычно первыми берут в работу те задачи, которые дешевле в производстве, но потенциально принесут большую пользу. Польза — это либо какая-то важная техническая составляющая продукта, либо деньги.

Получается, чем быстрее ты масштабируешь команду, тем быстрее ты утилизируешь бэклог, тем быстрее ты масштабируешь продукт. Хочешь расти быстро — сфокусируйся на быстром пополнении бэклога и быстрой утилизации задач из него. Хочешь ускорить утилизацию — масштабируй команду.

Зачем компаниям диджитал-интеграторы и специалисты на аутсорсе, если у них есть свои

Продуктовые команды должны быть внутри компании? Или их лучше нанимать извне?

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

Даже несмотря на то, что у вас своя компания по заказной разработке?

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

Как вы это решаете эту проблему?

Мы рассчитали, что инхаус-команда должна быть ровно такого объема, чтобы покрывать минимальные объемы загрузки в течение года. Остальные всплески по нагрузке мы добираем внештатными специалистами, аутсорсом и партнерами. Таким образом мы добиваемся того, чтобы все риски были на внешних ресурсах, а у нас ничего не простаивало.

А как вы решаете, кто должен быть инхаус, а кто — за штатом?

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

Вы говорите про аутсорс?

Могут быть разные подходы. Во-первых, можно просто взять ресурсы на аутстафф. Во-вторых, то, что я советую нашим заказчикам, — можно брать целиком команду на стороне внешнего подрядчика. По сути, ты им платишь зарплаты и небольшую маржу агенту, а по факту это гораздо выгоднее, чем нанимать самим. Да и команды, как правило, отдают уже слаженные, там специалисты уже сработались друг с другом. Пока загрузка есть — эта команда с вами, когда нет — отпускаете ее. Мы сами как подрядчики работаем по такой модели с «М.Видео», «СберСпасибо», «Магнитом», X5 Group и многими другими.

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

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

Основатель Amazon Джефф Безос говорил, что чем быстрее компания проверяет гипотезы, тем она успешнее. Если новая фича не выстрелила, команду можно распустить. Если сработала — можно постепенно под нее собрать инхаус-команду. Мы даже ввели специальный термин — фича-тим. Чем больше таких команд, тем полезнее для продукта. Мы так, например, работаем с некоторыми заказчиками. Они приходят, рассказывают, какую функцию придумали, а наши спецы ее реализуют.

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

В этом случае от заказчика — только сама идея, правильно? Все остальное на подрядчике?

Да, это один из вариантов. Но зачастую, можно аутсорсить даже наполнение бэклога идеями. Чтобы формировать гипотезы, основанные на данных, нужны соответствующие специалисты: Data-аналитики, UX-аналитики. И их тоже можно зааутсорсить. Например, мы так помогаем одному крупном ритейлеру наполнять и приоритизировать его бэклог фичами, и далее они раздают их на реализацию нам или другим подрядчикам. Их задача — проверять как можно больше наиболее перспективных гипотез.

Зачем компаниям продуктовая стратегия и как она помогает зарабатывать деньги

Что такое продуктовая стратегия?

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

Идеальная задача продуктовой разработки выглядит так. У тебя есть описание задачи — например, хотим сделать интерфейс корзины. Дальше нужно зафиксировать, как реализация этой задачи должна повлиять на какую-то цель из продуктовой стратегии. Таким образом получается, что любая задача на проекте будет реализовываться только в рамках целей продукта. Иначе ее просто не имеет смысл брать в производство. Это, с моей точки зрения, эталон разработки.

Можно привести пример продуктовой стратегии какого-нибудь вашего клиента? 

Вот как раз сейчас мы разрабатываем продуктовую стратегию для интернет-аптек 36,6. Несколько целей из нее: 1) повысить средний чек, 2) увеличить конверсию в чекаут в магазине, 3) улучшить ситуацию с брошенными корзинами и 4) повысить эффективность фильтров поиска в каталоге. Любая задача на проекте будет обязательно ссылаться на один из пунктов стратегии.

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

Когда лучше использовать аутсорс, а когда атстафф?

Аутсорс эффективно использовать при имеющихся скачках нагрузки на инхаус-команду, когда есть необходимость проверить много гипотез за короткий срок. Еще — при разработке MVP (Minimal Viable Product, минимально жизнеспособный продукт), чтобы зафиксировать затраты на его реализацию на старте. И еще когда нужна специализация, которую сложно и дорого содержать внутри. К таким специализациям можно отнести, например, ML, чат-боты и т. п. У нас под такое даже есть отдельная компания — AGIMA.AI. Мне кажется, смысла создавать такие экспертизы внутри нет, потому что требуются редкие специалисты. Искать их сложно, а нужны они не часто.

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

Какая модель работы лично вам больше нравится?

Гибридная. Когда есть немного аутсорса и немного аутстаффинга. Это, наверное, самый популярный и самый эффективный вариант — когда у заказчика выстроено производства внутри, но что-то они добирают у подрядчиков. С нами так, например, работают «АльфаСтрахование», «Финуслуги», World Class. Главная особенность такой работы — высокая интеграция. Мы проводим совместные планирования, ежедневные встречи, вместе пополняем и приоритизируем бэклог. Даже KPI продукта планируем вместе.

А что касается оплаты, то обычно это Fixed Price или Time and Materials?

Я всегда топлю за Fixed Price, хотя большинство интеграторов на рынке за Т&М (это когда заказчик платит за время специалистов). Понимаю, почему — они таким образом снимают с себя все риски. Ты продал часы специалиста и больше не паришься. А Fixed Price тебя заставляет просчитать все риски заранее. Но для заказчика Fixed Price — самое безопасное решение. Любой большой продукт должен бюджетироваться. То есть, если я что-то хочу сделать, я выделяю на этот бюджет, планирую, сколько он принесет бизнесу, сколько нужно вложить, и так далее. И это правильно.

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

Резюмируя, в чем основная польза от партнерства с диджитал-интегратором, если компания все-таки решила растить продуктовую экспертизу внутри?

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

Могу говорить только на нашем примере. Но какую бы сферу мы сейчас ни взяли — у нас, скорее всего, есть такой опыт. Ритейл? У нас в портфеле проекты для «Магнит», «Пятерочка», «Перекресток» и др.

Страхование? Мы реализовали не один десяток проектов для «АльфаСтрахование», «Росгосстрах», «СОГАЗ»,  «Согласие», «Росно» и др.

Финтех? Проекты для МКБ, «Росбанка», «Райффайзен Банка», «Промсвязьбанка», ОТП Банка, Реннесанс Банка. Еком? «Кораблик», OSTIN, «М.Видео».

СМИ? Основной сайт «Комсомольской правды», «Российской газеты» и многих других.

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