Разработка мобильных приложений: как формируется цена?

[AlexeyVPolunin]

Всегда интересовал вопрос как разработчики считают количество часов, необходимых для написания софта. Расскажите о своем подходе.

[R902th]

Если по уму, то 100% на основе опыт.
Например, в софте есть функционал который ранее делал. Этот функционал условно занял месяц, в среднем разработчик вырабатывает 120 часов в месяц. Вот значит на такую-то функцию нужно примерно 120 часов и т.д.

[RKTV]

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

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

Проблемы могут начаться, когда клиент будет усердно требовать определённую технологию, на которой у вас нет опыта разработки. Например, Flutter. «Потому что сейчас все так пишут», «Потому что прочитал много статей на эту тему», «Потому что у Медузы вон Флаттер и всё хорошо».

В этом случае придётся закладывать «коэффициент неизвестности». Либо обучаться новым технологиям за счёт средств компании.

[AlexeyVPolunin]

Понятно, примерно я так и думал, цифры зависят от толщины кошелька клиента :)
Мой знакомый рассказывал, что раньше был гост на разработку ПО, в котором были прописаны нормы выработки программиста. Думал вы используете какой-то документ типа упомянутого госта.

[RKTV]

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

Ещё одни отличием является расчёт на в человеко-часах, а в человеко-месяцах.

[appbuilding]

Если вы про сроки — то исключительно опыт. Мы используем это dequery.com, как минимум не заморчаиваешься с экселем и с каждым проектом все точнее оценка получается, потому как знаешь где пролетел по часам ранее.

[Bakyt480]

"3. Оптимизация. Чем больше экранов в приложении, тем оно дороже – и наоборот. Поэтому если продумать расположение инструментов на минимальном количестве экранов, это удешевит результат. Например, приложение такси можно сделать так, что для ввода адресов будет происходить переключение на отдельные экраны. А можно разместить всё на одном экране: и кнопку вызова, и ввод адресов, и карту."

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

[RKTV]

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

Тем не менее, есть частные случае, когда количество страниц следует уменьшить для экономии затрат. Особенно для приложений с небольшим количеством функционалов. Меньше отрисовываешь, меньше верстаешь, меньше тратишь.

[Dudechka]

Заказчику показываете коридор (min — max)? Если да то как потом обосновываете что для какой-то задачи потребовался максимум затрат?

— невозможна работа приложения оффлайн.

Это в какой кроссплатформенной технологии?

[RKTV]

Заказчику показываем смету min/max. Это помогает сформировать у клиента понимание о возможном удорожание. В договоре прописываем одну цену и пункт, в котором указываем, что при увеличение объема работ новая стоимость оформляется приложением к договору.

Про оффлайн режим — это некорректная формулировка. Согласен. Речь скорее о том, что есть особенности при работе в оффлайне. И некоторые кроссплатформенные технологии справляются с этими особенностями хуже.