Денис Гордиенко, руководитель Bright Mobile, о подходе к работе с командой разработки в стартапах на аутсорсе.
В прошлой статье я писал о том, что из-за проблемы поиска сотрудников и сложности постановки технических задач, многие стартапы так и не преодолевают даже рубеж создания MVP.
То дизайнер уволится, то программист завалит задачу. Создание даже минимальной заготовки будущего продукта растягивается на полгода, а то и год. Некоторые основатели обращаются в студии, как в сколоченные команды, но встречаются с проблемой заинтересованности. Студии важно сдать проект и получить деньги, что дальше будет с приложением особо не интересно, стартапы - это не про длинный LTV.
В этой статье хочу рассказать про идею аутсорсинга разработки стартапа. Пример буду приводить из своей профессиональной области - разработка маркетплейсов услуг, но принципы работают и в других отраслях.
Идея придумана не мной, но был опыт такого сотрудничества. К слову, он закончился печально, но тем ценнее опыт. Буду писать в формате "как должно быть по учебнику" / "как получилось в реальности" / "какие были совершены ошибки".
Общая суть аутсорсинга разработки
Идея аутсорсинга в следующем. Есть несколько участников всего проекта:
- Инвестор. Вкладывает деньги в проект, отправляя транши раз в 2 - 3 месяца. Рассчитывает перед каждым траншем увидеть достижение определённых результатов и через 3 - 5 лет продать свою долю с мультиплекатором х5 - х10.
- Основатель. Занимается развитием проекта, курирует разработку, занимается маркетингом и экономикой. Рассчитывает, как и инвестор продать свою долю через несколько лет, либо превратить стартап в бизнес с устойчивой прибылью.
- Команда разработки. Выполняет реализацию приложения и/или сайта (в нашем случае маркетплейса услуг), Получает деньги траншами за сданные этапы работ. Чаще всего фигурирует оценка в часах умноженная ставку часа команды.
Опционально основатель и инвестор могут быть одни лицом - это когда человек запускается на свои. Обычно взаимодействие основателя и команды разработки сводится к формированию ТЗ с проработкой от 5 до 200 страниц и чёткому или не очень выполнению этой задачи. Не очень - это когда в процессе обе стороны понимают что нужно поменять требования и оценку и переподписывают договор.
Но есть другой тип заказчиков, которым не хочется заниматься управлением разработкой, вникать в технические моменты, искать общий язык с дизайнерами, разработчиками и т.п. Это, как минимум, серьёзная потеря времени, которую можно потратить на тестирование тех или иных гипотез в маркетинге (например, привлекая трафик и тестируя конверсию на лендинг будущего продукта).
В студию и обращаются, чтобы минимизировать свое участие в создании продукта, опираясь на профессионализм команды. Но всё равно, вместо того, чтобы заниматься продвижением приложения, искать инвестиции, общаться с потенциальными пользователями, заказчик тратит огромное количество времени на проверку и согласование различных этапов разработки.
Идея аутсорсинга разработки сводится к тому, чтобы основатель требовал не следования бумажному описанию, а достижения критического показателя для стартапа на текущем этапе. Возвратимся к нашему примеру с маркетплейсом услуг. Какая главная функция такого проекта? Чтобы заказчик услуги и исполнитель смогли получить контакты друг друга и сделка состоялась, а сервис получил комиссию. Значит всё ТЗ на первый этап будет состоять только из этой фразы. Как именно это произойдёт - команда разработки решает на своё усмотрение. Как будет развиваться продукт дальше - расскажу через несколько абзацев.
Как сейчас происходит заказная разработка
Итак, вернёмся чуть назад и детальнее разберём чем же плоха текущая схема, по которой работает большинство студий заказной разработки.
- Основатель описывает идею
- Команда составляеТ техническое задание.
- Основатель проверяет. Команда вносит правки.
- Команда делает прототипы.
- Основатель проверяет. Команда вносит правки.
- Команда делает каркасы или дизайн
- Основатель проверяет. Команда вносит правки.
- Команда пишет код. Публикует приложение.
- Основатель проверяет. Команда вносит правки.
- Команда делаем доработки
- Основатель проверяет. Команда вносит правки.
И т.д... Почти каждое второе действие - это отвлечение основателя на проверку и команды на действие не приносящее прибыль. Оппоненты часто мне возражают, мол как это основатель не будет проверять что делает команда, ведь он хочет сделать продукт, который заказал?! Вот тут как раз кроется зерно сегодняшней статьи. Если основатель заказывает "под себя" и разработка идёт так, чтобы продукт понравился заказчику, то тут спору нет - нужно идти стандапртным сценарием. Если же заказчик понимает, что его мнение - это всего лишь мнение среди многих других и правду скает только агрегированное мнение всех пользователей, то тут становится очевидным бессмысленность внесения локальных правок, ведь то, что нравится основателю не обязательно понравится аудитории.
В качестве лирического отступления сразу расскажу про крайность, когда изначально договариваются работать по конкретной цели (как выше - "заказчик услуги и исполнитель смогли получить контакты друг друга и сделка состоялась, а сервис получил комиссию"), но основатель по итогу не согласен с решением команды и хочет изменить часть продукта.
Ситуация усложняется, если основатель хочет учесть всё и сразу, сделать лучшее приложение в сторах с первой версии. Но чем больше сценариев использования, чем больше экранов, тем больше нюансов и выше вероятность реализовать не то, что нужно будет конечному пользователю. А одна правка со стороны заказчика может повлечь существенные изменения в во всем приложении.
Время - ключевой ресурс в развитии стартапа. Стартап должен как можно быстрее выйти в мир и начать приносить деньги.
Вот здесь кроется первая из моих ошибок, о которых писал в начале. Вместо того, чтобы убедить основателя в том, что он не может быть истиной в последней инстанции не получив хоть какой-то пользовательский опыт приложения я считал своим долгом вносить все пожелания (у него же больше опыта в предметной области, в которой запускается маркетплейс). Из-за того, что договор был не с почасовой оплатой это привло к двукратному росту трудозатрат, когда я понял, что пора остановиться.
В общем, мораль в том, что либо основатель проверяет и принимает по ТЗ, либо доверяет решениям команды заочно, полагаясь на опыт, и не вмешивается в реализацию. Договариваться нужно на берегу.
Как происходит развитие продукта на аутсорсе
Главная метрика успешности приложения - количество пользователей. Чем лучше приложение решает проблему пользователя, тем больше им будут пользоваться.
Проблема в том, что узнать, что нужно пользователям, заранее невозможно. Все идеи, что говорит основатель, это непроверенные гипотезы. Задача команды разработки - найти дешёвый механизм для проверки, а если идея подтвердится, то качественное решение для "боевого" внедрения. Многие основатели хотят перепрыгнуть проверку, считая, что идея в проверке не нуждается. У кого-то даже есть причины так полагать, однако, более половины стартапов по статистике Y Combnator закрываются из-за невостребованности идеи. Это уже факт с которым сложно спорить.
Поэтому, постановка задачи должна исходить из контекста “что нужно сделать, чтобы получить первые скачивания, первых клиентов, первых постоянно платящих клиентов”. Не миллион, а с десяток человек.
Соответственно, вся разработка первой версии сводится к обслуживанию пары десятков пользователей. Это речь не про прибыль, а про тестирование идеи на малых цифрах.
Далее создаётся приложение на усмотрение команды разработки, запускается маркетинговая составляющая, пока не наберётся масса пользователей, которая была заявлена на старте.
После, основатель собирает обратную связь от пользователей и, уже опираясь на их мнение, ставит следующую задачу и, после её реализации приложение привлекает уже одну две сотни новых пользователей. Основной опыт учтён и можно увеличивать количество респондентов. Далее итерации повторяются.
Вот так, добавляя буквально по одной - две функции, можно развивать приложение, не тратя время на согласование прототипов, каркасов, тестирование всех возможных вариантов пользовательских сценариев.
В этой части статьи мы плавно подошли ко второй крупной ошибке в подобном подходе. Очень часто первые пользователи, как и основатель, отвечая на вопрос "что бы вы хотели улучшить?" рисуют некий идеальный конечный результат, в стиле, чтоб был коммунизм и всё было бесплатно. Это конечно хорошо, но эконопика продукта тогда не сойдётся.
Важно отличать зёрна от плевел и выделять самый важный функционал, за который пользователи будут платить дополнительные деньги. Таким образом, правильно было бы ставить вопрос так: "какой функционал можно было бы добавить в приложение и сколько Вы готовы за него заплатить?". Если ответ - "ни сколько", то рассматривать это предложение далее экономически не целесообразно. Наша же ошибка заключалась в том, что мы брали в работу произвольные пожелания пользователей без учёта здравого смысла. Вышло примерно, как в басне про лебедя, рака и щуку.
Инвестиции
Очень часто стартапы запускают не на свои средства, и обращаются к инвесторам. Для инвесторов же вкладывать свои деньги в идею - это очень рискованное мероприятие.
Можно прийти к инвестору с красивой презентацией сервиса, который когда-то в будущем будет создан и, конечно, будет лучше аналогов. А можно - с готовым приложением, в котором реализован самый минимальный функционал, есть какое-то количество пользователей и понятна монетизация. Предлагать вложиться не огромной суммой средств, а на следующие одну - две итерации. Если сумма инвестиций не большая, то для начала сотрудничества все в плюсе - основатель отдаёт не большую долю, а инвестор проверяет адекватность основателя малыми деньгами.
Такой подход будет более прозрачным для инвестора, он будет понимать, как и с какой отдачей используются его вложения, а далее легче выстраивается диалог о следующем раунде инвестиций.
Абсолютно согласен, нужно показать инвестору фактически востребованный продукт, а не то, что когда-то, по каким-то причинам может принести прибыль, и пытаться показать воздушные цифры, которые приятно радуют глаза.
1. Наличие грамматических ошибок минимум в 3х словах как не внушает доверия к материалу.
2. "Главная метрика успешности приложения - количество пользователей" - главная для кого?
Для стартапа. Это, кстати, одно из основных отличий стартапа от бизнеса. Стартап - про охват, бизнес - про прибыль
Любой стартап - это бизнес, не стоит разделять понятия
Да, я знаю многих сторонников этой идеи. Но сам не согласен с ней. Как-нибудь дойдут руки написать холиварную статью про сравнение стартапа и бизнеса и детально рассказать о своём опыте.
Если говорить кратко, то задача бизнеса, в классическом понимании - это извлечение максимальной прибыли в отчётный период. Стартап же растит капитализацию, он может быть убыточен годами, но иметь ценность, которую оценивают в энную сумму. В итоге любой стартап продаётся и становится бизнесом, вопрос на каком из этапов развития.
Если же называть бизнесом любое занятие имеющее риски и приносящее не фиксированный доход или убыток, то да, стартап туда попажает.
Есть стартапы, которые показывают хорошую прибыль в рамках своей юнит-экономики, а потом быстро масштабируются, тратясь на захват рынков, уходя при этом в глубокий прогнозируемый операционный минус, а есть стартапы, в которых экономика начнет сходиться только когда (и если) они достигнут какого-либо значительного количества пользователей, до момента достижения которого может быть такой же прогнозируемый минус, и в первом, и во втором случае - это про бизнес.
И у "обычного" бизнеса те же самые законы и задачи - любой бизнес, если он показал свою востребованность, может в моменте, ради ускорения своего роста, уходить в минус, просто стартапам, если у них новые бизнес-модели, с сильной ит-составляющей, все может даваться быстрее и легче.
На мой взгляд, стартап от "обычного" бизнеса сейчас отличают только новизна бизнес-модели и варианты финансирования, поскольку даже самые стандартные и классические офлайн-бизнесы нынче цифровизируются и масштабируются не хуже иных стартапов.
"стартапы - это не про длинный LTV." Исправьте...
Думаю, что есть нормальные студии, которые и мвп сделают и по скраму могут улучшать продукт.. и для инвестора так даже лучше будет так как надёжнее, да и основатель долю не отдаёт..
продукт улучшать то можно. Но задача основателя - проверять гипотезы в полях. Это не про команду разработки, это про управление стартапом. Продукт в этом случае только площадка для проверки гипотезы.
не совсем понятно, как "проверять гипотезы в полях", мне казалось, что как раз гипотезы в продукте реализуются и проверяются.. если речь про кастдев, то там не гипотезы проверять нужно, а выявлять действительные потребности и боли, а значит и жизнеспособность той задачи которую в принципе вы собираетесь решать..
Вы считаете, что это задача для разработчиков?
Разработчики это имхо неотделимая часть всей команды, которая также включает и основателя... Поэтому гипотезы и ставятся и реализуются всей командой, роль основателя направлять и делать так чтобы процесс не останавливался.. правда всё зависит от конкретной команды.. можно и по другому работать, как вам удобнее, главное чтобы результат был
Вообще, наверное, хорошо, что вы раз за разом пытаетесь найти свою нишу в разработке, но, как мне кажется, у вас есть две глобальные проблемы:
1. Рынок заказной разработки перенасыщен, конкуренция реально бешеная во всех нишах и ценовых сегментах. Есть и такие студии, которые за долю от стартапа, вообще без денег, работают.
2. Фокус на создании маркетплейсов. Здесь ситуация мне видится, как в начале нулевых с сотовой связью - можно где-то в регионе открыть свой салон и даже более-менее зарабатывать, но рано или поздно придут "связной" и "евросеть", так какой смысл соваться в заранее обреченное дело?
Почему вы не пилите свой проект? Нет идей? Если так сильны в маркетплейсах - почему, на волне хайпа, не маркетплейс?
1. Есть, но они быстро закрывается. А рынок разработки пустой - нормальных разработчиков днём с огнём не найти. Расскажите о конкуренции в разработке ребятам, которые делают бизнес на грузчиках, пластиковых окнах или доставке воды.
2. Фишка в непрямой конкуренции и узких нишах
Что касается попыток найти нишу, как Вы пишите, то это не попытки, а сбор аналитики для стратегических решений. Под маркетплейсом Вы наверное имеете ввиду программную часть в той или иной нише. Чтобы сделать успешный маркетплейс нужно не делать маркетплейс, а найти уникальное решение, которое будет выгодно и заказчикам и исполнителям. Выгодно - это значит выгоднее, чем при стандартных условиях на рынке.
И да, свой маркетплейс есть, он заключается в декомпозиции глобальной задачи по разработке на мелкие и подбор исполнителя на реализацию каждой из них. Попытки о которых Вы писали - это опыт внедрения тех или иных идей в клиентские проекты, либо подсмотренные у других команд. Возможно, когда-нибудь расскажу и о своём маркетплейсе по разработке приложений.
Если бы рынок был пустой, то у вас наверняка было бы достаточно крупных корпоративных клиентов и не приходилось делать ставку на стартаперов.
Хороших разработчиков очень много, но их ценник могут себе позволить не только лишь все, мало кто может это делать.
Насчет приведенных вами примеров (грузчики, доставка воды) - они работают на локальном рынке, на котором у них пусть 5, пусть даже 10-15-20 реальных конкурентов, а на вашем рынке, вследствие его глобальности - 10 000 конкурентов только в России.
И, вы пишете, что не ищете нишу, и что ваш маркетплейс заключается в декомпозиции разработки, ну ок, представим, что это не то же самое, чем занимаются все без исключения студии, но тогда в чем уникальность вашего решения, в чем выгода для заказчиков и исполнителей?
Чем Вам стартаперы то не угодили? Я во времена сайтов работал с крупными корпоративщиками - геморроя и рисков там больше. Работа со стартаперами - это осознанный выбор, а не желание заработать хоть что-то.
В СНГ около 700 студий мобильной разработки во всех ценовых сегментах, где Вы 10 000 то нашли?
Для заказчиков выгода в том, что они получают приложение по цене в 2-3 раза ниже рыночной, для исполнителей в простых, локальных, понятных задачах, а не "вот тебе ТЗ сделай что-нибудь, а там разберёмся".
Вот отсюда цитата https://vc.ru/flood/17250-web-rating
По данным РАЭК, объем такого сектора российского ИТ-рынка, как разработка интернет-проектов (мобильная и веб-разработка), в 2015 году составил около 24 млрд рублей. При этом количество его участников превышает 10 тысяч, то есть доля каждого отдельного игрока незначительна. Порядка 20 российских студий имеют более 40% всех крупных заказов на рынке — то есть возможности роста для небольших компаний крайне ограничены.Насчет ваших преимуществ - они очень спорные, потому что, во-первых, просто так цена не может быть в 2-3 раза ниже рынка, явно придется чем-то пожертвовать, а во-вторых, ценность для исполнителя совсем уж не очевидна, поскольку я даже не представляю себе, что за шарашкины должны быть конторы, где таким образом ставят задачи, разве что самые стремные. Итого, очевидных и уникальных преимуществ, можно сказать, что у вас нет, для исполнителей уж точно.