Инхаус или Аутсорс — как действовать стартапу после пилота

Рассуждения руководителя команды продуктовой разработки WB—Tech Кирилла Гришанина о стартапах на стадии MVP.

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

С другой стороны к нам иногда обращаются те, кому аутсорс вовсе не подходит, так как это не то что будет выгодно проекту.

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

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

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

В немецком исследовании в качестве одного из выводов говорится о том, что фаундер с бизнесовыми навыками должны очень внимательно выбирать коллег, которые будут делать продукт. Основная проблема для таких фаундеров заключается в том, что у них нет критериев выбора. Люди делают 2 типичные ошибки:

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

Остановимся на втором тезисе немного подробнее, рассмотрев его с другого аспекта. В том же немецком исследовании указывается, что сотрудники, также как и фаундеры, вносят большой вклад в базу знаний компании и слаженность их работы не менее важна. Я вижу огромную разницу между наймом персонала в свой штат и передачей ответственности сторонней компании. Разница заключается в том, что у персонала нет никакой ответственности за результат. Многие возмутятся «Как же так?! Я нанимаю специалиста — он будет отвечать за результат». Проблема заключается в том, что создавая новый бизнес, у вас нет прозрачных для обеих сторон (работодатель / исполнитель) регламентированных бизнес-процессов. Если бы они были, то стартапер уже бы не был начинающим. Если нет регламентированных бизнес-процессов, то у основателя и нет критериев, по которым он сможет принимать решение – справляется нанятый сотрудник или нет. Следовательно, нет и ответственности на сотруднике — по сути он может делать все, что хочет. Фаундер инвестирует в новый бизнес, а не покупаете франшизу, поэтому чем больше выстроенных бизнес процессов будет в стартапе — тем лучше. Аутсорс может дать такое преимущество.

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

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

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

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

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

• измерение бизнес метрик, например:

  – Правильно: «Мы хотим измерить средний чек» после 50 первых продаж

  – Правильно: «Мы хотим измерить конверсию в клиента после пуш-сообщения от телеграм канала с офером с хорошим дисконтом, но очень ограниченным по времени»

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

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

• proof of concept: то есть вообще возможно ли это технологически? Уверен, что фаундеры технологических стартапов не читают эту колонку, так как они по умолчанию более опытны в стартапах. Скорее всего те, кто разрабатывает распознавание эмоций собеседника в ходе беседы с ним в скайпе или делают еще какую-то технологию, которая еще нигде не внедрена, и так обладают навыком руководства программистами. Аутсорс им не нужен, возможно только аустафф. Разумеется, аутсорс однозначно не подходит, если инновация основана на технологии, так как одну из ключевых компетенций нельзя отдавать на аутсорс.

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

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

• пилот прошел успешно — потребности проверены и пора измерять ключевые-бизнес метрики
• у вас есть хотя бы $50k , про которые вы готовы забыть

• инновация основана не на технологии и гипотеза, которую вы проверяете очень конкретна

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

Если же ситуация такова, что и/или:

• требуется переделка продукта, который не справляется с текущими задачами бизнеса и тренд не в пользу продукта
• количество ресурсов достаточно, чтобы быстро поменять весь софт

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

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

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