Да, вы правы, есть и такие заказчики. И вопрос в том, насколько меньше их бюджет, обозначенной суммы и что им нужно за эту сумму сделать. Если функциональные требования и бюджет соотносимы, то студия может работать с таким клиентом. Если же не соотносимы: то есть требований на 1.5 млн, а бюджета 500 тыс., то тут каши не сварить и скорее всего заказчику придется искать фрилансера, который не обременен всеми ценообразующими факторами студии.
Если в сотрудничестве у кого-то есть цель размазать другую сторону по стенке — это плохое сотрудничество. Крупность той или иной стороны лишь усиливает бюрократизацию всего процесса, но в то же время бюрократизация может быть гарантом. С фрилансерами меньше бюрократии и меньше гарантий, со студиями больше, но это не говорит о том, что не надо работать с фрилансерами, надо работать со студиями. Вовсе нет, все индивидуально. Есть крутые студии и плохие фрилансеры, но есть и плохие студии и крутые фрилансеры. Тем не менее, заключая договор со студией вы минимизируете свои риски, а договариваясь с фрилансером зачастую увеличиваете их.
Аутентификацию частично тоже приходится писать заново, как минимум потому что у каждого приложения свой сервер, а вообще аутентификация бывает разной:
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
Если коротко, сломаться может все что угодно. Где-то может верстка поплыть, где-то картинки в принципе не отобразятся, собьются настройки приложения по умолчанию и т.д. Влияет не только обновление ОС, но еще и обновление API сторонних сервисов, которые используем.
Например: не захотел заказчик свой кастомный чат — дорого. Интегрировались с API готового чата. Всем все нравится, все работает. Чат обновляет API и перестает поддерживать старое — фиксим. Интегрируемся с новым API. К чести сторонних чатов сказать, они всегда предупреждают сильно заранее о таких обновлениях. И даже с фиксом стороннее API будет дешевле, чем кастомное решение.
Интересная, кстати, идея — собрать список наиболее распространенных проблем и оформить их в статью. Как-нибудь займусь этим, спасибо.
Если описывать конкретный пример, то можно засветить очень много ндашной информации, но в следующий раз попробую написать конкретнее, спасибо за комментарий. :)
Добрый день, в основном это диаграмма Гантта. И таблица статусов готовности функционала — по сути бёрндаун в табличном виде. Ну и плюс мы постоянно показываем, что мы сделали, то есть заказчик в любой момент может зайти на dev окружение, посмотреть как дела на вебе или запросить у нас промежуточный билд приложения: iOS передадим через TestFlight, Android — через Firebase.
Конечно, заказчик требует сроки, да и это в наших интересах в них уложиться: мы не получим деньги, пока не достигнем оговоренного майлстоуна. :)
Разные бывают фрилансеры и разные бывают студии. Тут сложно сказать «все фрилансеры делают хорошо и в 10 раз дешевле», а «все студии сильно завышают цены», но в чем вы абсолютно правы, так это в том, что студии действительно стоят дороже. Да и юридически с ними куда проще, чем с фрилансерами, в случае чего.
К сожалению, студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
Кроме приложений есть еще сервер и админка, поэтому в полтора раза дешевле, да и нативку поддерживать выходит дешевле. Гибрид, как показывает практика, ломается чаще, и не потому что мы плохо сделали, а потому что среда меняется постоянно. Обновился iOS — обязательно что-нибудь фиксим. То же самое с Android.
Все рассматриваем, на всем делаем. Просто к нам обычно не приходят с запросами «сделайте так же, как вы сделали там», все очень индивидуально. Мы редко повторяемся и беремся за совершенно разные приложения. Но, конечно, у нас есть большая кодовая база и что-то мы обязательно переиспользуем.
Интересно посмотреть, можете ссылку на ваш гитхаб дать?
Зависит от договоренностей с предыдущим заказчиком и контракта, по которому работали. В целом, будет дешевле, потому что какая-то логика будет переиспользована, но весь код мы переиспользовать не сможем и технически это будет не просто поменять цвет и лого.
imater Спасибо за статью, очень информативно, и все же вопросы возникают. Основной вот в чем: вы пишите, что даете точную оценку вместо «от» и «до». Хотел бы уточнить, фиксируете ли вы для себя эти от до или совсем без них работаете. И если без них, то как идентифицируете и предотвращаете риски?
Здесь спорить не буду. Бывают такие ситуации, но возникают они далеко не каждый день. И внеплановые митинги, иногда собирать приходится, но до отмены спринта дело еще ни разу не доходило.
Виктория, спасибо за комментарий. В этом посте описываю опыт работы на конкретном проекте, на нем тестирование не страдает, возможно, на каком-то другом проекте так бы не получилось: там бы думал над другим решением.
Не буду спорить с тем, что присутствует басфактор, однако стараюсь его минимизировать — не отпускаю работу на самотек, проверяю сделанное и полностью погружаюсь в него, иногда прошу переделывать. Конечно, если вдруг он уйдет, будет грустно и сложно — все опять свалится на меня, а я, ввиду занятости на других проектах, буду делать эту работу некачественно, либо перестану спать вообще.
Насчет заменить не знаю — у него не будет времени на процессы, и на другие проекты, но если он в будущем станет пмом, я буду только рад.
— по email
— по номеру телефона
— через соц. сети
— и т.д.
Конечно, какую-то часть можно переиспользовать, но абсолютно точно могу сказать, что часть логики будет отличаться и часть кода все равно придется переписать, либо вообще написать с 0 даже для аутентификации.
Например: не захотел заказчик свой кастомный чат — дорого. Интегрировались с API готового чата. Всем все нравится, все работает. Чат обновляет API и перестает поддерживать старое — фиксим. Интегрируемся с новым API. К чести сторонних чатов сказать, они всегда предупреждают сильно заранее о таких обновлениях. И даже с фиксом стороннее API будет дешевле, чем кастомное решение.
Интересная, кстати, идея — собрать список наиболее распространенных проблем и оформить их в статью. Как-нибудь займусь этим, спасибо.
Конечно, заказчик требует сроки, да и это в наших интересах в них уложиться: мы не получим деньги, пока не достигнем оговоренного майлстоуна. :)
К сожалению, студии, которые «кормят завтраками» действительно есть, но это не повсеместная практика.
Все рассматриваем, на всем делаем. Просто к нам обычно не приходят с запросами «сделайте так же, как вы сделали там», все очень индивидуально. Мы редко повторяемся и беремся за совершенно разные приложения. Но, конечно, у нас есть большая кодовая база и что-то мы обязательно переиспользуем.
Интересно посмотреть, можете ссылку на ваш гитхаб дать?
А вообще да, согласен, всякое бывает.
Не буду спорить с тем, что присутствует басфактор, однако стараюсь его минимизировать — не отпускаю работу на самотек, проверяю сделанное и полностью погружаюсь в него, иногда прошу переделывать. Конечно, если вдруг он уйдет, будет грустно и сложно — все опять свалится на меня, а я, ввиду занятости на других проектах, буду делать эту работу некачественно, либо перестану спать вообще.
Насчет заменить не знаю — у него не будет времени на процессы, и на другие проекты, но если он в будущем станет пмом, я буду только рад.