Разработка стартапов с командой разработки на аутсорсе

Денис Гордиенко, руководитель Bright Mobile, о подходе к работе с командой разработки в стартапах на аутсорсе.

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

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

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

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

Идея аутсорсинга в следующем. Есть несколько участников всего проекта:

Опционально основатель и инвестор могут быть одни лицом - это когда человек запускается на свои. Обычно взаимодействие основателя и команды разработки сводится к формированию ТЗ с проработкой от 5 до 200 страниц и чёткому или не очень выполнению этой задачи. Не очень - это когда в процессе обе стороны понимают что нужно поменять требования и оценку и переподписывают договор.

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

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

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

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

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

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

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

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

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

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

Главная метрика успешности приложения - количество пользователей. Чем лучше приложение решает проблему пользователя, тем больше им будут пользоваться.

Проблема в том, что узнать, что нужно пользователям, заранее невозможно. Все идеи, что говорит основатель, это непроверенные гипотезы. Задача команды разработки - найти дешёвый механизм для проверки, а если идея подтвердится, то качественное решение для "боевого" внедрения. Многие основатели хотят перепрыгнуть проверку, считая, что идея в проверке не нуждается. У кого-то даже есть причины так полагать, однако, более половины стартапов по статистике Y Combnator закрываются из-за невостребованности идеи. Это уже факт с которым сложно спорить.

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

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

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

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

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

В этой части статьи мы плавно подошли ко второй крупной ошибке в подобном подходе. Очень часто первые пользователи, как и основатель, отвечая на вопрос "что бы вы хотели улучшить?" рисуют некий идеальный конечный результат, в стиле, чтоб был коммунизм и всё было бесплатно. Это конечно хорошо, но эконопика продукта тогда не сойдётся.

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

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

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

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