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

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

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

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

Введение. Аксиомы

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

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

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

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

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

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

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

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

I. Разбираемся с терминологией

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

Что такое ретейнер

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

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

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

Что такое итеративно-инкрементальная разработка

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

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

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

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

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

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

Почему ТЗ — зло

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

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

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

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

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

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

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

II. Разработка софта ≠ разработка продукта

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

Разработка продукта — это вообще не разработка софта.

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

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

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

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

Какие такие ценности доставляет разработка?

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

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

Слой первый. Создание софта

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

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

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

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

Слой второй. Создание продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слой третий. Руководство бизнесом

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

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

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

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

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

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

Какие такие гипотезы мы помогаем проверять заказчику?

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

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

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

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

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

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

1. Гипотеза о рынке

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

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

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

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

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

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

2. Маркетинговая гипотеза

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

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

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

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

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

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

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

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

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

4. Гипотеза о команде

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

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

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

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

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

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

А кто формулирует гипотезы?

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

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

Итого: разработка продукта = изменение процессов + доставка ценности + проверка гипотез + улучшение окупаемости.

Без этого мы просто пилим софт. Кроме этого надо управлять бизнесом.

III. Кирпичики рыночных предложений

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

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

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

1. Чем конкурировать

Стоимость контракта

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

Стоимость эффективного часа

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

Уровень экспертизы в предметной области

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

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

Экспертиза в технологии

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

TTM

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

Скорость проверки гипотез

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

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

2. За что отвечать

Сроки и соответствие ТЗ

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

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

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

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

Доставка фич

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

Проверка гипотез

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

Изменение процессов и метрик

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

3. Какую схему оплаты использовать

Ретейнер

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

Фикс прайс

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

Time & material

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

Лицензия

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

Доля владения

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

Премия за метрики

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

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

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

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

IV. Аутсорс, аутстаф, продуктовая разработка: в разрезе

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

1. Что заказывает бизнес

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

2. Результат в случае успеха

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

3. Управление проектом

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

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

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

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

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

4. Управление продуктом

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

5. Ответственность

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

6. Ценообразование

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

7. Степень изоляции

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

8. К чему стремится

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

9. Чем конкурирует

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

10. Что понимает под словом качество

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

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

Конструктор готов!

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

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

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

V. Продуктовая разработка: внутри vs снаружи

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

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

Ответственность

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

Ценообразование

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

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

Изоляция

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

К чему стремится

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

Чем конкурирует

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

Что понимает под словом качество

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

VI. Зачем отдавать управление продуктом наружу?

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

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

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

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

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

Во-первых, потому что не хватает рабочих рук

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

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

Во-вторых, потому что не хватает компетенции

  1. Компетенция разработки — нет своего СТО.
  2. Компетенция UX/UI — нет своего арт-директора.
  3. Компетенция маркетинга — нет своего СМО.

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

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

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

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

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

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

В-третьих, это ускоряет развитие бизнеса

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

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

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

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

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

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

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

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

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

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

А зачем все это самой команде продуктовой разработки?

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

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

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

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

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

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

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

VII. Неразрешенные вопросы продуктовой разработки

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

— Те, кто понимает в продуктах, уходят в продукты.

— Так, и что? Чем удерживать кадры?

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

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

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

— У внешней команды нет права решать важные вопросы.

— Так, и что? Становиться консультантами или совладельцами?

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

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

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

— Наружу отдают все менее ответственную работу.

— Так, и что? Ниша сужается?

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

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

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

— Команда — это больше чем кадры.

— Так, и что? Это удерживает кадры или подготавливает команду к увольнению?

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

Выводы

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

  • Если вы работаете над новым продуктом, то вы заинтересованы в стабильной команде, сосредоточенной на достижении целей продукта, а не на доставке фич. С фиксированными затратами в месяц, работающей в итеративно-инкрементальной логике. ТЗ для новых продуктов — зло.
  • Разработка продукта — это не разработка софта. У нее другой предмет работы — не доставка фич, а проверка гипотез роста.
  • Если вы не ставите целью спринта изменение поведения людей (сотрудников заказчика или его клиентов), то вы не разрабатываете продукт.
  • Если вы все-таки разрабатываете продукт и у вас есть общая с заказчиком система целей, то и вам и заказчику так сильно лучше — предсказуемее, выгоднее и интереснее.
  • Ну и наконец, как это ни странно, нет большой разницы между внутренней и внешней командой продуктовой разработки. А вот разница с аутстафом и заказной разработкой по ТЗ есть — и большая.

Поговорите со мной об этом!

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

CEO digital-продакшена JetStyle, CPO издательского сервиса Rideró
0
27 комментариев
Написать комментарий...
Константин Солодянников

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

Ответить
Развернуть ветку
Aleksey Kulakov

Это сложный вопрос. Я думаю что это временный тренд, который продлится еще 2-4 года. Аутстафф по факту кадровая технология и попер вверх на том что упала платина между Москвой и регионами.

Дальше есть два противотренда: дефицит на квалифицированные кадры и дефицит на источники компетенций (СТО, СМО, CPO и т.п.). Я думаю что второй в конечном итоге острее, и поэтому заказ на "мозги и руки" будет расти быстрее чем заказ на "только руки, мозги у нас свои".

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

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

Ответить
Развернуть ветку
Светлана Исаченко

Просто вагон инфы, спасибо авторы!

Ответить
Развернуть ветку
Game Topia

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

Ответить
Развернуть ветку
Aleksey Kulakov

Вообще за 20 лет студии стали сильно разными. И вообще-то некоторые изрядно отличаются от "остаются web-студией")

Ответить
Развернуть ветку
Game Topia

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

Ответить
Развернуть ветку
Aleksey Kulakov

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

Ответить
Развернуть ветку
Game Topia

Как аргументы? Кроме как о том, что некоторые изрядно отличаются вы ни о чем и не сказали. Ну да, не все пишут под ВордПресс, но тем не менее не перестают оставаться все теме же вэб студиями. У них тот же рабский ритм, они все так же пляшут под дудку заказчика. А опция, когда заказчик просто говорит, что хочет абстрактное приложение, реализация которая полностью на вас, такое было всегда. Собирались целые команды, в которые входили бизнес аналитики, дизайнеры, архитекторы и разработчики и проводили мозговые штурмы, которые определяли вектор работ. Сейчас это называют разработкой продукта. Блин, но в начале, когда речь шла о продуктовой разработке, всегда имелись ввиду компании разрабатывающие свой продукт. Это и было отличие. А сейчас, в погоне за маркетинговой привлекательностью все размыли.

Ответить
Развернуть ветку
Aleksey Kulakov

Отличие описано в статье )
Вы спорите с какой-то позицией, которая к описанному в статье подходу не относится

Ответить
Развернуть ветку
Game Topia

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

Ответить
Развернуть ветку
Denis Beskov

Алексей всё-таки руководит развитием продукта в Ridero, а не просто хозяин шараги, так что он прекрасно знает, о чём пишет.

Ответить
Развернуть ветку
Aleksey Kulakov

Спасибо, Денис ) Вообще у меня да, есть в анамнезе некоторое количество продуктовых историй.

Ответить
Развернуть ветку
Константин Балакин

о, Денис) приятно увидеть комментарий от знакомого человека.
Я примерно тоже самое хотел ответить.

Ответить
Развернуть ветку
Константин Балакин

Алексей, спасибо огромное за статью! Очень сильно откликаются многие пункты. Всё четко разложено по полочкам.
Лет 5-7 назад, когда не так была хайпова тема продакт менеджмента, я себе формулировал цель "построить компанию заказной разработки, которая будет не просто повторять их ТЗ а реально доставлять ценность бизнесу". Так вот сейчас понимаю, что Ваша статья именно об этом)

Ответить
Развернуть ветку
Двадцать Один

Хорошая статья, спасибо за материал.
Алексей, вы работаете только по такой схеме? или все же беретесь за ТЗ ради прибыли?

Ответить
Развернуть ветку
Aleksey Kulakov

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

Ответить
Развернуть ветку
Sophico Patarakina

На сколько этот подход будет отличаться, когда твой заказчик=инвестор ( у которого ты далеко не один)?

Ответить
Развернуть ветку
Aleksey Kulakov

Конечно. Я бы сказал "особенно, если заказчик инвестор". Если у вас есть какие-то более конкретные вопросы — не стесняйтесь.

Ответить
Развернуть ветку
Sophico Patarakina

Спасибо, Алексей, правильно ли понимаю, что в этом случае мы идем тем же маршрутом (делаем как для себя, т.к. именно так и есть)? Но, т.к. пока не вышли на достаточные обороты, в операционных процессах сильно зависимы от инвестора и тут сложнее договариваться с ним о границах и методах оплаты, т.к. мы в роли просящего (нафиг уж совсем он нас не пошлет, т.к. уже вбухал нас много и бросить жалко). Например, нам сложнее ему (инвестору) сказать, что тестирование гипотезы и эксперименты, причем постоянные и на потоке - это признак зрелости, а не фигового планирования продукта (нового сервиса) на рынок. Плюс, покупкой клиентом нашего продукта+ПО не заканчивается же жизнь, надо поддерживать интерес пользователя (саппорт+маркетинг+SMM), реагировать на обратную связь от пользователей и даже негативная реакция (пока он не делает возврат) это всё равно результат, потому тчо с этим работать можно, на это можно реагировать и делать лучше. Где место этих процессов в Вашей системе, это у Вас в формировании кадров?

Ответить
Развернуть ветку
Aleksey Kulakov

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

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

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

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

т.е. общий подход такой:
1. есть иерархия целей
2. внутри нее есть последовательность проверки гипотез
3. ей подчинены отдельные задачи внутри спринта. задачи не только на разработку — маркетинг, pr, биздев, работа юристов — что требуется.
4. важно убедиться что у этого процесса есть владелец (CPO, продакт или как угодно еще называный). Иногда он с нашей стороны, иногда со стороны клиента.
5. кроме развития есть эксплуатация. в больших продуктах это разумно разделять на разные команды. в маленьких — приоритезировать от влияния на цель.

примерно так.
ответил?

Ответить
Развернуть ветку
Родион Аристов

Зачем нужна итеративно-инкрементальная модель, когда есть agile?

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

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

Выходит, что при работе над продуктом по Time&Material команда будет постоянной, это разумные ожидания обеих сторон.

Ответить
Развернуть ветку
Aleksey Kulakov

Про постоянную команду согласен (так и написано в статье)

Остальные соображения — как мне кажется — не относится к этому тексту. Т.е. — ок, это ваша позиция, но статья про другое )

Ответить
Развернуть ветку
Родион Аристов

Если быть точным, в статье сказано, что при time & material состав команды от недели к неделе может меняться, и только ретейнер дает возможность не менять команду. Я просто указал, что здесь нет зависимости именно при работе над продуктом, и при time&material должно быть также - выделенная команда. Возможно, если вы осуществляете какие-то небольшие работы при схеме работы с заказчиком time & material, может быть замена исполнителей и в этом случае нет рисков. Просто статья про работу над продуктом же.

Не понял, почему остальные комментарии не относятся к теме статьи, то есть я дал комментарий к содержимому статьи, к конкретным измышлениям:

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

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

Ответить
Развернуть ветку
tass neposeda

Мне кажется, что вы правильно подметили - и в t&m и в ретейнере на протяжении продолжительного времени набор исполнителей может не меняться. отличие только в юридических деталях - в t&m договорились, что оплатят время и "материалы", а в ретейнере обычно договариваются о цене за команду и за её состав. Различия могут проявляться тогда, когда поток задач от заказчика становится неоднородным. Такое бывает. То в бэкенде масштабные работы, то на фронт навалится, то дизайнерам перепало. В этом смысле разница между типами контракта скорее не в возможности заменить исполнителей одного типа между собой, а в балансировке компетенций в команде под текущие нужды заказчика. Хотя на практике изменения всегда приносят боль управленцам :)

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

Ну и про ТЗ - лично я согласен! :) Вижен является важной точкой синхронизации. Если ТЗ отвечает на вопрос "как будут жить счастливые пользователи будущего продукта / ПО / ИС - вотэва" - пусть будет ТЗ!

Ответить
Развернуть ветку
Родион Аристов

По t&m и ретейнеру - верно именно так, как вы написали, но только набор исполнителей не то, что может не меняться в обоих случаях, а разумно не менять в интересах обеих сторон этих исполнителей при любом подходе к работе над продуктом. Это просто странно, если вы в работе над продуктом заказчика вдолгую проговариваете, что вот, мол, мы можем поменять исполнителей, если вы будете нам платить по t&m, вы даже заказчику это не объясните, что вот при этой схеме вот так работаем, а при этой вот так, для него адекватно, что команда на его продукт - выделенная и постоянная, т.к. погружение требуется. Собственно, в статье и следовало сообщить эту разницу, но было сказано другое: ретейнер обеспечивает выделенную команду, а t&m нет. Просто ретейнер - это новомодно, поэтому о нем статьи писать тоже модно :)

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

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

то вы беретесь делать фичу с ягодами сразу же быстро все пересогласовав оставив нюансы. Вы не говорите заказчику (или не делаете преград из этого для старта новой фичи): "так сейчас доку сделаем, переподпишем наше соглашение, переоценим фичу и т.д." В итерационной модели это будет новый спринт со всеми пересогласованиями, оплатами за уже выполненную работу итд, а в agile вы просто делаете согласно философии, понимаете? Атмосфера, в которой работают команды при этих подходах, сильно разная: в степени готовности команд к изменениями, в отношениях к изменениям, к условиям оплаты, в отношении к клиенту, в самих границах между клиентом и вами. То есть в agile лучше поймут скорые изменения и примут их в команде.

С ТЗ вы вместо автора согласились, это не зло, и я очень рад :)

Ответить
Развернуть ветку
tass neposeda

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

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

Ответить
Развернуть ветку
tass neposeda

—-

Ответить
Развернуть ветку
24 комментария
Раскрывать всегда