Comments 37
А если приходит клиент со словами вот вы делали приложение кушайпиццу, мне тоже самое только лого поменяйте и цвет. Тоже будет стоить так же?
Зависит от договоренностей с предыдущим заказчиком и контракта, по которому работали. В целом, будет дешевле, потому что какая-то логика будет переиспользована, но весь код мы переиспользовать не сможем и технически это будет не просто поменять цвет и лого.
Мне кажется тут стоит подумать о коробочных решениях с кастомизацией, нет смысла делать просто копию 1 в 1.
Разве с мобилками такое есть? Мне кажется это противоречит маркетплейсам — насыщение копипастой.
Именно, по сути это уже продажа продукта, нежели разработка приложения под заказ. Есть компании, которые живут на этом: Loyalty Plant, например.
Например, решение для пиццерий. Работайте по нашей бизнес модели. И фигачить общую кодовую базу, с ветками для компиляции только разных переменных цвета и логотипов.
Ага выше увидел про Loyalty Plant.
Ага выше увидел про Loyalty Plant.
Я думал гибридное будет минимум в два раза дешевле стоить, а разница оказывается не такая большая.
Флаттер не рассматриваете? Довольно любопытная штучка. Если сейчас багу мою смогу поправить с помощью разрабов, то сложная интеграция с существующей нативной кодовой базой (наверное, самое сложное это типа OCR движока нативного) то можно считать вполне готовым продуктом для прода. Без этого и подавно.
Флаттер не рассматриваете? Довольно любопытная штучка. Если сейчас багу мою смогу поправить с помощью разрабов, то сложная интеграция с существующей нативной кодовой базой (наверное, самое сложное это типа OCR движока нативного) то можно считать вполне готовым продуктом для прода. Без этого и подавно.
Для студий стоимость состоит из оплаты работы участников команды + прибыль для самой студии. Поэтому озвученный порядок более/менее правильный.
Частные разработчики обходятся дешевле в несколько раз за аналогичный проект, т.к. оплата требуется только за их работу (прибыль уже включена в оплату). За проект средней сложности 150-250 т.р…
Аргумент студий, что «они не исчезнут» и «всё сделают до конца» в «отличие от частных разработчиков» не работает. Не исчезают, но разработка может просто затормозиться, студия начинает «кормить завтраками», в итоге готового приложения нет.
Частные разработчики обходятся дешевле в несколько раз за аналогичный проект, т.к. оплата требуется только за их работу (прибыль уже включена в оплату). За проект средней сложности 150-250 т.р…
Аргумент студий, что «они не исчезнут» и «всё сделают до конца» в «отличие от частных разработчиков» не работает. Не исчезают, но разработка может просто затормозиться, студия начинает «кормить завтраками», в итоге готового приложения нет.
Разные бывают фрилансеры и разные бывают студии. Тут сложно сказать «все фрилансеры делают хорошо и в 10 раз дешевле», а «все студии сильно завышают цены», но в чем вы абсолютно правы, так это в том, что студии действительно стоят дороже. Да и юридически с ними куда проще, чем с фрилансерами, в случае чего.
К сожалению, студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
К сожалению, студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
юридически с студиями куда проще, чем с фрилансерами, в случае чего.Это не вопрос фрилансера и студии, а вопрос размера заказчика и исполнителя. Чем больше перевес по размерам в пользу одной из сторон — тем юридически этой стороне проще, в том числе и с кормлением завтраками.
студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
Фрилансер тут играющий роль и юриста и продажника, при этом не являющийся профи ни в одной из этих областей, будет низшим звеном в этой пищевой цепочке, поэтому в целом клиенту с юридической точки зрения (продавить свои условия) и с точки зрения завтраков (динамить с выполнением своей части) и т.д. — будет проще с фрилансером, а не со студией.
В свою очередь редко какая студия сможет что-то позитивное для себя получить в юридичеком смысле в договоре, скажем, с лукойлом. Хотя обычного физика клиента она своим, хоть и небольшим, юр. штатом размажет по стенке.
вопрос размера заказчика и исполнителявесьма точное замечание, причем работающее в обе стороны. Ведь есть не только фрилансеры-исполнители, но и мелкие заказчики, для которых бюджет проекта в 1.5 млн на их текущем этапе неподъёмен.
Да, вы правы, есть и такие заказчики. И вопрос в том, насколько меньше их бюджет, обозначенной суммы и что им нужно за эту сумму сделать. Если функциональные требования и бюджет соотносимы, то студия может работать с таким клиентом. Если же не соотносимы: то есть требований на 1.5 млн, а бюджета 500 тыс., то тут каши не сварить и скорее всего заказчику придется искать фрилансера, который не обременен всеми ценообразующими факторами студии.
Если в сотрудничестве у кого-то есть цель размазать другую сторону по стенке — это плохое сотрудничество. Крупность той или иной стороны лишь усиливает бюрократизацию всего процесса, но в то же время бюрократизация может быть гарантом. С фрилансерами меньше бюрократии и меньше гарантий, со студиями больше, но это не говорит о том, что не надо работать с фрилансерами, надо работать со студиями. Вовсе нет, все индивидуально. Есть крутые студии и плохие фрилансеры, но есть и плохие студии и крутые фрилансеры. Тем не менее, заключая договор со студией вы минимизируете свои риски, а договариваясь с фрилансером зачастую увеличиваете их.
Если в сотрудничестве у кого-то есть цель размазать другую сторону по стенке — это плохое сотрудничество.Абсолютно любой бизнес составляет договор в свою пользу, с подстраховкой себя. Никто не составляет договор в пользу другой стороны.
При этом одни и те же пункты в своем договоре будут названы «защитой своих интересов», а те же в чужом договоре назовут «включенными с целью размазать по стенке»:)
меньше бюрократии и меньше гарантий,Смотря что Вы имеете ввиду. Если исполнитель предлагает заказчику свой договор, а заказчик подписывает его не глядя для «минимизации бюрократии», то у заказчика гарантий будет существенно меньше нуля.
заключая договор со студией вы минимизируете свои риски, а договариваясь с фрилансером зачастую увеличиваете их.Это не более чем маркетинговая лапша распространяемая студиями не имеющими других конкурентных преимуществ перед фрилансерами, кроме маркетинга:)
Как правило всё как раз наоборот, просто по объективным причинам — уровень юр.грамотности у фрилансера заведомо ниже уровня студии. То что придумает включить в договор студия и что она туда не пропустит — фрилансеру, в меру его непрофильности в юридической сфере и в голову не придет.
Кроме приложений есть еще сервер и админка, поэтому в полтора раза дешевле, да и нативку поддерживать выходит дешевле. Гибрид, как показывает практика, ломается чаще, и не потому что мы плохо сделали, а потому что среда меняется постоянно. Обновился iOS — обязательно что-нибудь фиксим. То же самое с Android.
Все рассматриваем, на всем делаем. Просто к нам обычно не приходят с запросами «сделайте так же, как вы сделали там», все очень индивидуально. Мы редко повторяемся и беремся за совершенно разные приложения. Но, конечно, у нас есть большая кодовая база и что-то мы обязательно переиспользуем.
Интересно посмотреть, можете ссылку на ваш гитхаб дать?
Все рассматриваем, на всем делаем. Просто к нам обычно не приходят с запросами «сделайте так же, как вы сделали там», все очень индивидуально. Мы редко повторяемся и беремся за совершенно разные приложения. Но, конечно, у нас есть большая кодовая база и что-то мы обязательно переиспользуем.
Интересно посмотреть, можете ссылку на ваш гитхаб дать?
Кстати, может, напишете статью про "обновилось — фиксим"? Очень интересно, что приходится переписывать, что чинить, что ломается обновлениями.
Если коротко, сломаться может все что угодно. Где-то может верстка поплыть, где-то картинки в принципе не отобразятся, собьются настройки приложения по умолчанию и т.д. Влияет не только обновление ОС, но еще и обновление API сторонних сервисов, которые используем.
Например: не захотел заказчик свой кастомный чат — дорого. Интегрировались с API готового чата. Всем все нравится, все работает. Чат обновляет API и перестает поддерживать старое — фиксим. Интегрируемся с новым API. К чести сторонних чатов сказать, они всегда предупреждают сильно заранее о таких обновлениях. И даже с фиксом стороннее API будет дешевле, чем кастомное решение.
Интересная, кстати, идея — собрать список наиболее распространенных проблем и оформить их в статью. Как-нибудь займусь этим, спасибо.
Например: не захотел заказчик свой кастомный чат — дорого. Интегрировались с API готового чата. Всем все нравится, все работает. Чат обновляет API и перестает поддерживать старое — фиксим. Интегрируемся с новым API. К чести сторонних чатов сказать, они всегда предупреждают сильно заранее о таких обновлениях. И даже с фиксом стороннее API будет дешевле, чем кастомное решение.
Интересная, кстати, идея — собрать список наиболее распространенных проблем и оформить их в статью. Как-нибудь займусь этим, спасибо.
Сева, добрый день.
Вы пишите: «в соответствии со всеми правилами гибкой разработки». Как я понял разработка через аутсорс.
Подскажите, как вам удается поддерживать комманду в виде единого, зрелого юнита, чтобы прогнозировать сроки проекта (например с помощью BurnDown Chart). Или заказчик не требует сроки?
Вы пишите: «в соответствии со всеми правилами гибкой разработки». Как я понял разработка через аутсорс.
Подскажите, как вам удается поддерживать комманду в виде единого, зрелого юнита, чтобы прогнозировать сроки проекта (например с помощью BurnDown Chart). Или заказчик не требует сроки?
Добрый день, в основном это диаграмма Гантта. И таблица статусов готовности функционала — по сути бёрндаун в табличном виде. Ну и плюс мы постоянно показываем, что мы сделали, то есть заказчик в любой момент может зайти на dev окружение, посмотреть как дела на вебе или запросить у нас промежуточный билд приложения: iOS передадим через TestFlight, Android — через Firebase.
Конечно, заказчик требует сроки, да и это в наших интересах в них уложиться: мы не получим деньги, пока не достигнем оговоренного майлстоуна. :)
Конечно, заказчик требует сроки, да и это в наших интересах в них уложиться: мы не получим деньги, пока не достигнем оговоренного майлстоуна. :)
Все это, имхо, надуманная величина. Это как с сайтами. На заре их делали за очень большие деньги. И дело не в сыистоперлелках, а в том, что в ту пору элкюектронная коммерция была еще неведомой… и в основном это был поиск пути. Но потом, накопился опыт. И этих ваших cms миллионы. И написано к ним миллионы миллионов модулей.
И все, как оказалось, легко стандартизируется. Тут на арену вышел маркетинг в полной красе. Ибо надо обосновать мегабюджеты на новую лого картинку.
Сегодня "стандартный сайт" со стандартным интернет магазином и т.д. Есть на любой вкус.
То же самое и с мобильной разработкой.
Чем отличается зимняя рыбалка от летней? Да ничем. Наливай и пей.
Так и тут. Всё, что дрступнл на сайте доступно и в мобилке. Весь функционал любого приложения — стандартен.
Да. Есть нюансы, кастомизации. Ео 90% всего будет остального одинаково.
Было бы очень здорово, если бы все было так просто. :)
Весь функционал любого приложения — стандартен.
Может в мире реселлеров с али-экспресса и доставок пиццы это и так, но в мире IT-бизнеса все ровно наоборот. Если у Вашего нового сервиса / приложения все тоже самое, что и у конкуретнов, то с какой стати пользователь пойдет к Вам, а не к ним?
Приложение магазин, приложение 3д вьювер редактор, приложение для биржи, приложение мессенджер, что между ними такого общего что их можно было бы из одинаковых модулей собирать?
как минимум, аутентификация пользователя.
Аутентификацию частично тоже приходится писать заново, как минимум потому что у каждого приложения свой сервер, а вообще аутентификация бывает разной:
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
Аутентификация в разных приложениях требует разной степени защиты, некоторые при каждом входе требуют аутентификацию через Google Authenticator., а приложение сканер сети — на кой ему аутентификация?
В большинстве случаев однотипные приложения можно собирать из одинаковых модулей, но и только.
В большинстве случаев однотипные приложения можно собирать из одинаковых модулей, но и только.
Однако примеры успешной "модуляризации" разработки web-приложений существуют:
Улучшите свой сайт с помощью 57 798 плагинов. Некоторые плагины имеют миллионы установок.
В каждой экосистеме свои традиции...
Вот если бы такую-же статью, но на конкретном примере, как ответы въедливому заказчику: «на что ушло время? почему это было необходимо? и сколько оно стоило?», было бы более познавательно. )
Сева, спасибо за статью. Теперь буду скидывать её моим знакомым, которые тоже задают подобные вопросы :)
Отличная статья. Благодарю.
Теперь знаю как просветиться заказчика.
Теперь знаю как просветиться заказчика.
Sign up to leave a comment.
Сколько стоит разработать мобильное приложение