Рубрика развивается при поддержке

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

Денис Гордиенко, руководитель 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": 0, "favorites": 14, "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 }
Облачная платформа
Основа для цифровизации бизнеса
0
{ "id": 93539, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/93539\/get","add":"\/comments\/93539\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/93539"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 235819, "last_count_and_date": null }
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 - довольно обширное понятие, и это не столько про сам продукт, сколько про подход к его разработке и выводу на рынок. Подход заключается в том, чтобы создавать продукт, ориентируясь не на свои ощущения и представления о том, каким он должен быть, а на результаты проверки основных и самых рискованных продуктовых гипотез, затрачивая на это минимально-возможное количество ресурсов. 

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }