Денис Гордиенко, руководитель Bright Mobile, о поиске и найме программистов для стартапов, и ситуации, когда проект начинает делать студия, а далее выгоднее перейти к собственному программисту.
Недавно разговаривал со клиентом, который хочет запустить стартап. Он рассказывал о том, что собрать команду - задача очень непростая. Ниже практически прямая речь:
Идти к фрилансерам не хочется, велик риск, что кинут, а это критично, особенно на этапе MVP, когда денег мало. Плюс хочется, чтобы первая версия была создана как можно скорее - т.е. программист занимался бы только этим проектом.
В In-House разработке свои трудности. Стартап - это всегда про веру в идею, сильную вовлеченность. И хочется, чтобы сотрудника тоже зажигала идея проекта.
В найме еще есть риск взять на работу человека недостаточной квалификации, если устраивать сразу официально, то будет тяжело избавиться, если нет - хорошие спецы на чёрную зарплату будут смотреть с негодованием. Про любителей имитировать бурную деятельность говорить нечего: где оклад, а не сдельная, всегда найдутся такие сотрудники.
В итоге человек рассказал, что за 3 месяца нашел программиста, но пока искал дизайнера, программист уже нашел другое место, устав ждать. Хоть он и был замотивирован идеей, но кушать хочется в любом случае, сложно его за это осуждать.
Сложности поиска сотрудников - довольно популярная история, среди тех, кто хочет запускать свой стартап.
Заказная разработка
Обращаться в студию мобильной разработки, где, в среднем, оценили его проект в 1,5 млн.р. - это дорого, да и студии заинтересованы максимально долго растягивать проект (почему могу написать отдельной статьёй, если в комментариях будет интерес к этой теме). Такой подход так же противоречит идее, что первую версию стартапа нужно запускать быстро и дёшево.
В разговоре пришли к такой идее: мы делаем MVP-версию, закладываем архитектуру проекта, а потом он нанимает менее квалифицированного программиста, для технической поддержки и планомерного развития приложения в штат. Причём наш объём работы назвать даже MVP вряд ли язык повернётся. Мы закладываем архитектуру серверной части, базы данных, админки и экранов, чтобы в будущем не потребовалось кардинальных изменений. Вместе с тем, когда архитектура проработана, мы подбираем программиста и плавно его внедряем в проект, чтобы у человека был адаптационный период и наша поддержка, если с чем-то не разберётся.
Получается, что если основатель принимает решение развивать дальше проект - у него есть программист по цене наёмного сотрудника, а не студии. Не нужно тратить деньги и время на подбор, и нет риска, что программист не разберётся в первичном коде приложения.
Системность запроса
После разговора, я задумался, ведь с подобным запросом обращался уже не один человек, просто вопрос был сформулирован по разному. Кто-то просил помочь найти программиста, Кто-то интересовался вопросами дальнейшей поддержки, кому-то был принципиален момент прямого контакта с программистом.
Уверен, у коллег по разработке приложений и сайтов эти же вопросы встречаются постоянно. Получается, что к стандартным схемам работы (фрилансер / студия / штатник), добавляется ещё и некое гибридное сочетание. Оно выглядит так:
- На начальном этапе заказывается базовая архитектура в студии
- Студия делает только самое необходимое, где нужна синергия разных специалистов
- Студия пишет документацию по проекту
- Студия подбирает программиста для развития проекта на условиях фриланса или клиенту в штат
- Студия осуществляет внедрение и техническую помощь программисту 1-2 месяца
- Клиент с программистом продолжают развитие проекта без участия студии
Давайте попробуем определить требования, при которых будет такая схема интересна. Для этого сперва отсечём типы клиентов, которым она очевидно не подходит:
- Крупные корпоративные заказчики. Для таких компаний юридический вопрос крайне важен и ответственность за любые действия должна быть на юрлице. Газпром не будет нанимать физлицо на развитие приложения
- Заказчики с бюджетом до 200 тыс. К сожалению, даже минимальную архитектуру за такие деньги продумать нельзя по студийной ставке часа и здесь придётся сразу работать с фрилансерами
- Заказчики с группой проекта со своей стороны. Программист просто не сможет грамотно вести проект получая задания от разных лиц.
Остаётся вот такой портрет основателя, которому будет выгоден симбиоз студии и частного программиста:
- На первую версию выделяется 200-800 тыс
- Единое лицо ведущее проект
- Готов работать с физлицом, оформив в штат, либо оплачивая услуги фрилансера.
Расчёт по бюджету
Моя команда специализируется на разработке приложений сервисов заказа услуг, товарных маркетплейсов и досок объявлений, поэтому пример будет из области, где понимаю порядок бюджетов.
В среднем первая версия маркетплейса услуг - это 400-500 тыс.р. за год развития она вырастает примерно в 2 раза до 800-1000 тыс.р. Для удобства буду оперировать цифрами 450 и 900 тыс.
Разработка архитектуры, серверной части и каркасов приложения - это примерно 70% от первоначальной суммы, сборка приложения по готовым каркасам и API - 30% (её то как раз и можно отдать программисту в режиме внедрения в проект).
Затраты на адаптацию программиста в проект примерно 50 тыс.р.
Программист на фрилансе или в штате получает в среднем в два раза меньше, чем берут студии. Получается вот такая математика в срезе первой версии и годовой поддержки:
Первая версия:
- Затраты на разработку каркасов, архитектуры, серверной части 70% х 450 000р = 315 000р
- Затраты на подбор и адаптацию 50 000р.
- Затраты на реализацию сборки подготовленным программистом 135 000р / 2 = 67 500р.
Всего первая версия выходит за 432 500р. Разница в 17 500р выглядит на уровне погрешности. Настоящая экономия начинается при развитии проекта, за год она составляет 225 000р, которые можно вложить в маркетинг, либо реализовать большее количество функционала, при этом, как показывает практика программист в команде более управляем и гибок, чем студия.
Самое важное в этой связке - это плавное внедрение программиста в проект, иначе можно получить стандартный ответ, что в чужом коде работать не буду, давайте делать с нуля.
Зачем для MVP приложение сразу пилить, не правильнее будет для начала ограничиться адаптивным сайтом?
Это зависит от целей приложения. Сейчас, например, работаем над таким MVP и там приложение нужно, чтобы мастера оперативно уведомлять о назначенных заявках через push. С адаптивным сайтом так не получится - нужно будет либо рассылать СМС, либо слать письма на почту и ставить мастеру почтовик.
Почтовик и СМС к адаптивному сайту - дешевле, но клиент видит MVP не в формате сделал/проверил/выкинул, а как основу для будущей платформы. Чем больше общаюсь с основателями, тем больше вижу задачу сразу заложить правильную архитектуру, чтоб не переделывать
А что, пуши разве пользователю сайта нельзя слать ? Представив на минуту, что нальзя могу за 1-3тр. предложить обложку для сайта, которая решает эту проблему.
можно слать web-push в браузер.
риски и преимущества webview приложений - это тема отдельной статьи
> чтобы мастера оперативно уведомлять о назначенных заявках через push. С адаптивным сайтом так не получится -
Так получится или или не получится ?
Не получится, мастер работает в полях, а не сидит за компьютером в браузере
В поле нет интернета ? А как же он пуши в мобилке получает без интернета ? Или почему еще в поле в браузере нельзя работать. Никак не пойму.
"хорошие спецы будут смотреть на черную зп с негодованием". Ну-ну. Когда хорошие спецы платят с белой зп 50 т.р. в месяц и более в виде налогов, они начинают иначе смотреть на белую зп;)
Может и так, писал по опыту общения с одногруппниками и коллегами
Это оттого, что большинство основателей неправильно понимают, что такое MVP и почему нужно делать именно так, а не иначе. Это непонимание, в свою очередь, выгодно студиям, которым (и это, в принципе, естественно) всегда хочется продать меньше работ за бОльшие деньги, поэтому они и создают для заказчиков такие противопоставления, как "сделал/проверил/выкинул" против "заложить сразу правильную архитектуру, основа для будущей платформы".
А как Вы видите правильный mvp?
Правильный MVP - довольно обширное понятие, и это не столько про сам продукт, сколько про подход к его разработке и выводу на рынок. Подход заключается в том, чтобы создавать продукт, ориентируясь не на свои ощущения и представления о том, каким он должен быть, а на результаты проверки основных и самых рискованных продуктовых гипотез, затрачивая на это минимально-возможное количество ресурсов.