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