Что такое продуктовая разработка внешней командой и почему это не просто аутстаф или аутсорс

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

Этот лонгрид написан по мотивам выступления Алексея Кулакова, CEO digital-продакшена JetStyle и CPO издательского сервиса Rideró, о том, чем отличается продуктовая разработка от аутсорса и аутстафа, зачем ей заниматься и в чем основные сложности. Опыт у Алексея двусторонний, поэтому выводов, а значит, и текста будет много.

Вот содержание — можете сразу перейти к тому, что вам особенно интересно (но мы советуем читать по порядку):

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

1. Если вы можете договориться с заказчиком продукта на ретейнер, нужно договориться на ретейнер.

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

2. Если можете вести разработку в итеративно-инкрементальном цикле, нужно ее вести в итеративно-инкрементальном цикле.

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

Можно то же самое сказать более резко и спорно: если вы вдруг делаете какой-то новый продукт и решили работать по ТЗ, то это вы решили прострелить себе коленку.

(Не надо так. Скоро вы сами поймете почему.)

Все, что написано ниже, — следствие этих аксиом.

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

Ретейнер — это схема, при которой мы с клиентом договариваемся, что один спринт команды стоит фиксированных денег, например полмиллиона рублей, а в команде постоянный состав специалистов, согласованный с заказчиком.

За каждый спринт заказчик платит по факту того, что этот спринт закончен. Для координации разработки обычно используется road map, но обязательства по тому, какие задачи будут сделаны в ближайший спринт, проговариваются непосредственно перед ним. Очень важно, что это делается всей командой, состоящей из разработчиков и команды со стороны заказчика, совместно. В отличие от time & material, деньги, которые платятся, и состав команды, которую мы отгружаем, от недели к неделе не меняются. В результате у продукта появляется стабильная команда, которая сосредоточена на его развитии.

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

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

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

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

Почему этот подход хорош для для новых продуктов?

Когда мы собираемся создать какую-нибудь новую штуку, которой будут пользоваться люди, нам, скорее всего, заранее неизвестно, какая гипотеза подтвердится и какой именно функциональный портрет продукта в комплексе с бизнес-процессами на стороне владельца системы действительно будет работать. Мы это узнаем позже — и только во взаимодействии с людьми. Мы говорим: «Сейчас сделаем что-то одно небольшое, посмотрим, как оно сработало, и после этого примем решение, что делать дальше». Мы движемся в будущее маленькими быстрыми шажочками и каждый раз предъявляем, что сделали. И не просто показываем, а вместе с заказчиком и его клиентами пытаемся этим пользоваться.

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

Что такое техническое задание, пояснять, наверное, не нужно. А вот почему работать над новым продуктом по ТЗ вредно для обеих сторон, давайте объясню.

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

Во-вторых, техническое задание создает давление со стороны заказчика на разработчика совершенно не в тех местах, которые приведут заказчика к успеху. Но от этого давления меньше не становится. Это геморрой, из-за которого стратегия выживания разработчика в проекте минимизирует шансы на то, что результат будет полезным. Заказываете по ТЗ — получаете «как в ТЗ». Чтобы получать выгоду от продукта, надо говорить c разработчиком про выгоду от продукта, делать ее предметом работы.

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

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

Итак, ретейнер + итеративно-инкрементальная разработка – ТЗ = лучшая схема работы.

Но это еще не делает разработку продуктовой.

Если вы запомните из этой статьи что-то одно, то запоминайте это:

Когда вы разрабатываете продукт, у вас другой предмет работы. Вы разрабатываете не программу. В разработке продукта предмет работы — доставка ценности и проверка гипотез.

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

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

Кому надоели слова ценность и гипотезы еще до этой статьи? Придется немного потерпеть.

Что мы имеем в виду, когда говорим заказчику: «Мы хотим, чтобы в конце каждого спринта была доставлена ценность» (как нас учит святой agile)?

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

1. Фичи — на проде

Как это было в заказной разработке? Мы — поработали, фичи — на проде. Всё, ура, ценность доставлена! Нам платят за фичи, мы доставили фичи — и радуемся. И хотя софт, вполне вероятно, ведет себя не совсем так, чтобы заказчик был счастлив, а бизнес рос, мы все равно молодцы. Мы доставили то, что обещали. Если нам повезло, оно еще и не сильно глючит!

Фичи на проде — это вообще не про продукт, но это самая частая ценность, которая продается на нашем рынке. Это предмет работы аутсорса и аутстафа.

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

2. Процесс — в эксплуатации

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

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

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

Другой пример. К нам пришел стартап. К моменту, когда они к нам обратились, они уже потратили несколько миллионов и год работы. В результате проверили ноль гипотез и не создали никаких регулярных процессов. Зато они разработали весьма развесистый UI и даже напилили немаленькое количество фич. Только это никак не приближало заказчика к следующему раунду. Почему? Ну, потому что ребята работали по ТЗ и доставляли фичи. Заказчик сейчас чувствует себя обманутым и ругает предыдущую команду. Я, кстати, думаю, что зря — парни сделали ровно то, что обещали. Только вот эту работу вообще не надо было делать в такой логике. Надо было делать продукт.

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

В следующих слоях продуктовости станет еще больше.

3. Клиенты заказчика получили ценность

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

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

4. Гипотезы подтверждаются

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

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

5. Экономическая модель сходится

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

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

Если мы дошли до этой ступени и всё, что выше, сделали — мы на пороге завоевания мира.

Последним слоем занимается уже не команда продукта, а команда бизнеса.

6. Прибыль растет

Это в ответственности CEO.

7. Бизнес дорожает

А это в ответственности владельца бизнеса.

Эти два пункта я перечислил просто для того, чтобы сказать, что продукт отвечает не за все на свете.

С ценностями разобрались, теперь — про гипотезы. На мой взгляд, когда мы говорим про новый бизнес или изменения в бизнесе, гипотез бывает всего четыре. Точнее, четыре кучи:

1. Гипотеза о рынке / объем, что растет, какой драйвер

2. Маркетинговая гипотеза / СРА, канал, конверсия

3. Продуктовая гипотеза / LTV

4. Гипотеза о команде / есть источники компетенции

Бизнес проверяет их самостоятельно или с нашей помощью.

Собираем все, что мы смогли узнать о рынке:

— насколько рынок большой,

— как он нарезан

— и, самое главное, что в нем растет и за счет какого фактора.

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

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

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

Конверсия тут — ключевая метрика, потому что влияет на то:

— сколько нам будет стоить клиент,

— какую долю клиентов в этом канале мы получим.

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

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

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

Чаще всего в JetStyle люди приходят за проверкой продуктовой гипотезы, правда они не всегда это так формулируют. Но задачи, которые они нам ставят, часто лежат именно в этой плоскости. Хотя так же часто у них ни про рынок, ни про маркетинг ясности никакой нет, и мы помогаем им и с этим.

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

Что это значит для нас?
Что мы можем быть для заказчика источником компетенций.

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

Вот и всё, больше никаких гипотез в продуктовой разработке нет.

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

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

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

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

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

Разберем каждый столбик таблицы и каждый кирпичик в ней, чтобы синхронизировать понимание.

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

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

Часто рынок выбирает команду за опыт решения похожей задачи. Например, у JetStyle высокая экспертиза в фарме, образовательном рынке, фудтехе и VR.

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

Разработка, UX/UI, маркетинг, продажи — это то, чем мы всегда пытались отстраиваться. Сейчас на рынке есть тренд на аутстаф, у которого ведущим способом конкурировать является кадровая технология — то, насколько быстро они нанимают и адаптируют сотрудников и какой у них в результате размер базы трудовых ресурсов. Т.е. сколько экспертизы, которую можно купить, они аккумулировали.

Time-to-market — то, с какой скоростью мы доставляем фичи на прод.

То, как быстро мы отвечаем на вопросы о рынке, маркетинге, продукте и команде.

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

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

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

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

Мы в JetStyle приняли решение, что крупных контрактов вот с такой ответственностью мы брать не хотим.

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

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

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

Про нее мы поговорили в самом начале, но повторить невредно. Это схема, при которой мы с заказчиком договариваемся, что один спринт команды стоит фиксированных денег, а в команде постоянный состав специалистов.

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

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

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

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

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

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

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

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

Осталось собрать из кирпичиков популярные сборки и посмотреть на разницу. Если кратко, то выходит вот такая таблица (а ниже я всё прокомментирую):

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

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

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

А вот сейчас будет мой самый провокационный тезис:

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

То, что слова продукт и проект похоже звучат, сыграло со всеми нами злую шутку: проект вообще не надо совать в продуктовую разработку. На вопрос «Где место проектного менеджера в продуктовой разработке?» ответ простой: «Его нет».

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

Аутсорса — за доставку фич и бэклог. Аутстафа — за доступ к дефицитной компетенции. Продуктовой разработки — за проверку гипотез.

У аутсорса — фикс и/или T&M. У аутстафа — T&M или ретейнер. У продуктовой разработки — ретейнер. Во всяком случае, у нас)

В аутсорсе строят Великую Китайскую стену между заказчиком и командой. В случае с аутстафом разработчик фактически под прямым управлением заказчика. А продуктовая разработка возможна только в том случае, если мы уничтожили стену между разработчиком и заказчиком, потому что без этого петля обратной связи в эксперименте будет такой длинной, что ТТМ (time-to-market) будет очень большой, и вся эта история не будет иметь смысла.

Традиционный аутсорс заинтересован в крупных контрактах и часто берет под свою ответственность огромные риски. Аутстаф стремится продать свои ресурсы на максимально возможный срок. А продуктовая разработка стремится ускорить и удешевить первую работу.

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

В аутсорсе — процент багов и насколько красивые у нас кейсы в портфолио. Потому что как проверяют качество проектов при внешнем осмотре? Правильно, смотрят на дизайн в кейсах. В случае с аутстафом — квалификация кадров и их доступность. А для продуктовой разработки — достижение целей бизнеса.

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

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

Вы можете посмотреть, из каких кирпичиков построен ваш бизнес, и понять, какие у вас преимущества на рынке.

Итак, мы детально посмотрели на аутсорс, аутстаф и продуктовую разработку. Но штука в том, что разработка продукта бывает внешней или внутренней. По традиции, вот сравнительная табличка:

А теперь прокомментирую.

В целом продуктовая разработка внешней и внутренней командой друг другу близки. И те и другие проверяют гипотезы и помогают изменить процессы.

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

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

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

Внешняя команда стремится уменьшить стоимость входного билета и увеличить штат. А внутренняя — увеличить аккумулированную компетенцию (и, конечно, штат).

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

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

А теперь самое интересное. В каких ситуациях нужно отдавать продукт внешней команде? И зачем, особенно если есть свои разработчики? Давайте порассуждаем.

Итак, глядите. Мы находимся в ситуации «Фрукт — фрукт, сиська — сиська»:

Какой из этого важный вывод для нас?
Правильно, что внешняя команда ничем не хуже.

На что внутренние ребята нам отвечают: «Нельзя аутсорсить core!». Переводится это так: «Если то, что вы делаете, это ядровая компетенция, то мы ее вам аутсорсить не будем, потому что лучше сделаем ее внутри, даже если это медленнее и дороже».

Дальше возникает вопрос: «Зачем бизнесу отдавать управление продуктом?». И тут давайте подробнее.

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

Тут мне, конечно, придется добавить: «Не, подождите, мы говорили не про рабочие руки. Мы же говорили про источники экспертизы!» И тогда…

То есть не хватает не людей, которые работают, а людей, которые умеют делать работу полезной.

Когда нет компетенции разработки — можно аутсорсить CTO. Нет компетенции UX/UI — можно аутсорсить арт-директора. Нет компетенции маркетинга — можно аутсорсить директора по маркетингу. Но, елки-палки, это все еще аутстаф!

Но бывает еще вот так:

4. Компетенция продаж — нет коммерческого директора с нужным опытом.

5. Компетенция разработки продукта — нет директора по продукту.

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

1. Бизнес получает доступ к источнику продуктовой компетенции

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

2. Команда заинтересована быстро реагировать и быть гибкой

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

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

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

3. Вместо локальной оптимизации расшивается узкое звено

Про разницу между локальной оптимизацией и узким звеном нужно пару книжек пересказать, чтобы стало понятно («Цель. Процесс непрерывного совершенствования», «Цель-2. Дело не в везении» и «Критическая цепь» Элияху Голдратта). Но это эффективный подход.

4. В конечном итоге гипотезы проверяются быстрее

И не просто в разы, а на порядки раз.

Почему это выгодно заказчику, я рассказал. Теперь о том, почему это выгодно нам как команде. Схема простая:

Конечных выгоды две.

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

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

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

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

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

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

Я хочу, чтобы JetStyle как digital-продакшен взял все лучшее из обоих миров. Чтобы каждый из нас имел возможность работать над продуктом в тот момент, когда работа над ним наиболее интересная — это когда продукт становится собой, когда он меняется. Потому что именно в этот момент ценность труда инженера наибольшая, а рутины пока мало.

Я имею наглость думать, что моя продуктовая компетенция достаточно глубокая. Она глубже, чем если бы я работал только в Rideró. И она глубже, чем если бы я работал только в JetStyle. Эта комбинация глубокого погружения в продукт и смены продуктов быстрее растит продуктовую компетенцию.

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

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

Что делать? Становиться консультантами? Это совсем другая модель. А чтобы становиться совладельцами, нужно отрастить у себя венчурную компетенцию. Только она должна быть лучше, чем у венчурного бизнеса, потому что они ставят только бабки, а мы ставим свое узкое звено на это дело. Рисков у нас больше, а венчурной компетенции у нас нет.

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

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

Этот предмет мы сейчас активно исследуем. И знаете что? За последние два года стало понятно: от того, что команды внутри продуктов заказчиков увеличились, работы на нашем рынке заказной разработки стало больше, а не меньше. Потому что если вы начали разрабатывать цифровой продукт, его нельзя перестать разрабатывать. ИТ будет дефицитом еще много лет. Сколько бы в компании ни было ИТ, его всегда придется дозаказывать снаружи.

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

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

Итак, давайте повторим главное.

Вот мои размышления о продуктовой разработке, и мне очень хочется поговорить о ней с вами. И не только про неразрешенные вопросы, а вообще про всё. Давайте рассуждать вместе? Жду ваши вопросы и комментарии здесь, или в почте kulakov@jet.style, или в моем фейсбуке. Спасибо, что осилили до конца)