Разработка
Денис Гордиенко
448

Как перейти от разработки приложения в студии к фрилансеру

Денис Гордиенко, руководитель Bright Mobile, о поиске и найме программистов для стартапов, и ситуации, когда проект начинает делать студия, а далее выгоднее перейти к собственному программисту.

В закладки

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

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

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

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

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

Сложности поиска сотрудников - довольно популярная история, среди тех, кто хочет запускать свой стартап.

Заказная разработка

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

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

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

Системность запроса

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

Уверен, у коллег по разработке приложений и сайтов эти же вопросы встречаются постоянно. Получается, что к стандартным схемам работы (фрилансер / студия / штатник), добавляется ещё и некое гибридное сочетание. Оно выглядит так:

  1. На начальном этапе заказывается базовая архитектура в студии
  2. Студия делает только самое необходимое, где нужна синергия разных специалистов
  3. Студия пишет документацию по проекту
  4. Студия подбирает программиста для развития проекта на условиях фриланса или клиенту в штат
  5. Студия осуществляет внедрение и техническую помощь программисту 1-2 месяца
  6. Клиент с программистом продолжают развитие проекта без участия студии

Давайте попробуем определить требования, при которых будет такая схема интересна. Для этого сперва отсечём типы клиентов, которым она очевидно не подходит:

  • Крупные корпоративные заказчики. Для таких компаний юридический вопрос крайне важен и ответственность за любые действия должна быть на юрлице. Газпром не будет нанимать физлицо на развитие приложения
  • Заказчики с бюджетом до 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р, которые можно вложить в маркетинг, либо реализовать большее количество функционала, при этом, как показывает практика программист в команде более управляем и гибок, чем студия.

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

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 12, "likes": 1, "favorites": 17, "is_advertisement": false, "subsite_label": "dev", "id": 93539, "is_wide": true, "is_ugc": true, "date": "Wed, 20 Nov 2019 17:04:54 +0300", "is_special": false }
Объявление на vc.ru Отключить рекламу
0
12 комментариев
Популярные
По порядку
Написать комментарий...
1

 Зачем для MVP приложение сразу пилить, не правильнее будет для начала ограничиться адаптивным сайтом?

Ответить
0

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

Почтовик и СМС к адаптивному сайту - дешевле, но клиент видит MVP не в формате сделал/проверил/выкинул, а как основу для будущей платформы. Чем больше общаюсь с основателями, тем больше вижу задачу сразу заложить правильную архитектуру, чтоб не переделывать

Ответить
0

А что, пуши разве пользователю сайта нельзя слать ? Представив на минуту, что нальзя могу за 1-3тр. предложить обложку для сайта, которая решает эту проблему.

Ответить
0

можно слать web-push в браузер. 

риски и преимущества webview приложений - это тема отдельной статьи

Ответить
0

 можно слать web-push в браузер. 

 > чтобы мастера оперативно уведомлять о назначенных заявках через push. С адаптивным сайтом так не получится - 

Так получится или или не получится ?

Ответить
0

Не получится, мастер работает в полях, а не сидит за компьютером в браузере

Ответить
0

В поле нет интернета ? А как же он пуши в мобилке получает без интернета ? Или почему еще в поле в браузере нельзя работать. Никак не пойму.

Ответить
1

"хорошие спецы будут смотреть на черную зп с негодованием". Ну-ну. Когда хорошие спецы платят с белой зп 50 т.р. в месяц и более в виде налогов, они начинают иначе смотреть на белую зп;)

Ответить
0

Может и так, писал по опыту общения с одногруппниками и коллегами

Ответить
0

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

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

Ответить
0

А как Вы видите правильный mvp?

Ответить
0

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

Ответить

Комментарии

null