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-бизнеса все ровно наоборот. Если у Вашего нового сервиса / приложения все тоже самое, что и у конкуретнов, то с какой стати пользователь пойдет к Вам, а не к ним?
как минимум, аутентификация пользователя.
Аутентификацию частично тоже приходится писать заново, как минимум потому что у каждого приложения свой сервер, а вообще аутентификация бывает разной:
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
Однако примеры успешной "модуляризации" разработки web-приложений существуют:
Улучшите свой сайт с помощью 57 798 плагинов. Некоторые плагины имеют миллионы установок.
В каждой экосистеме свои традиции...
Вот если бы такую-же статью, но на конкретном примере, как ответы въедливому заказчику: «на что ушло время? почему это было необходимо? и сколько оно стоило?», было бы более познавательно. )
Сева, спасибо за статью. Теперь буду скидывать её моим знакомым, которые тоже задают подобные вопросы :)
Отличная статья. Благодарю.
Теперь знаю как просветиться заказчика.
Теперь знаю как просветиться заказчика.
Sign up to leave a comment.
Сколько стоит разработать мобильное приложение