Цена разработки приложения. Отличия за 200 тыс и 2 млн

Собираясь разрабатывать приложение основатель чаще всего идёт тремя путями: на фриланс (FL, YouDo), ищет разработку в гугле или ищет студию в рейтингах (рейтинг Рунета, Теглайн). За типовые 20 экранов можно получить чеки и в 200 тыс и в 2 млн рублей, причём, это далеко не предел. Давайте разберём принципиальные моменты что можно купить за эти суммы.

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

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

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

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

Чтобы снять очевидные риски нужно проанализировать идею — собрать мнение коллег и клиентов, скажем если бы сервис был аналогичен представленному, но с дополнительными возможностями, интересно было бы таким сервисом пользоваться, было ли полезнее это в работе, стали бы его использовать?

И если 80% опрошенных говорят да, мы хотим эти дополнительные возможности в подобном сервисе, то это явный сигнал, что ваша идея достойна к воплощению в жизнь. У Олега произошла как раз такая же ситуация.

При звонке Олег описал идею софта, описал какие у него есть идеи по усовершенствованию. Ещё до нашего знакомства он начал собирать информацию о разработке подобного сервиса и КП от потенциальных разработчиков.

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

А у Олега своя цель — запустить приложение и зарабатывать на нем. И здесь есть такая тонкость, которая часто приводит к завалу проектов. У Олега, или другого заказчика, нет опыта именно в разработке IT-продукта, то есть он не знает как выстраивается этот процесс, что делается вначале, что в конце, в какой последовательности в каком порядке нужно идти, на что обращать внимание при согласованиях.

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

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

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

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

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

Последние полгода я работаю с крупными корпоративными заказчиками, где бюджет начинается от 600 тыс, в средний чек — 1,5 млн.р. При этом, требования заказчика который ориентируется на стоимость проекта в полтора миллиона сильно отличается от требований заказчика проекта стоимостью в 200 000 — 300 000 рублей. Речь само собой о примерно одинаковом количестве экранов в приложении.

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

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

Фрилансеры и мелкие студии. Можно купить разработку с нуля за такие деньги. Чаще всего это будут фрилансеры, либо маленькие студии, которые еще не наработали свой опыт и им нечем похвастаться. У них нет крупных клиентов в портфолио и они могут свой опыт доказать только по каким-то вторичным показателям.

Здесь всегда стоит вопрос рисков. Вы должны понимать что вы рискуете своими деньгами, получая цену в несколько раз ниже среднерыночной. Будте готовы к тому, что придётся доплатить. Если же вы делаете какое-то простенькое приложение, то платить за него 2 000 000 нет смысла, тут как раз вам прямая дорога к фрилансерам. Если всё просто то, скорее всего, вам сделают качественно, может чуть-чуть потянут по срокам, но это не критично, что бы за это переплачивать.

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

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

Сейчас часто езжу на встречи с крупными корпоративными клиентами и разговор чаще всего касается трёх вещей:

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

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

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

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

Чтобы такого недопустить, кроме отдела разработки требуется ещё и выстроить 24/7 отдел техподдержки, который бы реагировал на внештатные ситуации моментально.

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

Чаще всего если разработка дешевая — это проектная деятельность, написали техническое задание, подписали договор, через 2-3 месяца сдали. Иногда возможна какая-то небольшаятехническая поддержка, но суммы даже близко не похожи на те, которые были при разработке. Обычно, это не более 10% в мес от суммы основного контракта.

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

Соответственно и требования у крупного заказчика — договор на процесс. Вопрос обычно ставится: «сколько вы хотите в месяц за работы вашей команды». Клиент сам не знает, что за проект получиться, иногда даже какие-то базовые требования на первоначальном этапе неизвестны. Если вы хотите развивать крупный проект, нужно учитывать, что это вопрос не о технической поддержке и не о разовой работе, а о постоянном развитии.