Ну у Заказчика на ПО свои задачи завязаны, это раз.
Пожалуй, самое главное, что в процессе разработки используется время программистов и других специалистов, которое нужно оплачивать. И это время денег стоит. Вот смотрите, программист за месяц может поучаствовать в 1,2,3… проектах (не только разработкой, но и поддержкой, и так далее). Как разносить затраты по проектам? По часам.
Оценки «по аналогии» (разработка такого продукта может стоить «столько-то») неточны. Нет базы для совершенствования разработки и управления проектами в компании. Неизвестно, окупится ли мероприятие, или нет. А когда есть детальная разбивка по задачам, заметно снижаются и риски. Известно, что суммарная ошибка оценки падает при детализации как корень из N.
ИМХО, ИТ уже не та отрасль, в которой сверхдоходы крутятся. Всё больше становится, гм, промышленной что ли. Поэтому и подход к выполнению заказов — проектный, а в проектном деле оценка снизу-вверх (сроков, затрат, рисков, качества и др.) давно уже оправдывает себя.
Если совсем кратко, то оценка сроков нужна чтобы не облажаться по деньгам.
Оценки нужны для составления бюджета проекта. Если заказчик готов оплачивать потраченные часы по факту — его дело, тогда есть еще о чем поспорить. Да и то, команду синхронизировать надо в рамках задач каждого, одна фича быстрее вырастет, чем другая например. Самое паршивое в проектах — это удивляться.
И более того. Если внимательно посмотреть на диаграмму Гантта (это там, где оценки), иногда можно ускорить проект раза так в два. Но agile диаграмма Гантта не нужна, я знаю.
Какое может быть сходство в разработке, если языки разные. А то что элементы называются похоже, ну так они на то и одинаковые, чтобы не называться по-разному.
Пишут про гудвил, но это не совсем про бренд. Конечно да, бренд — нематериальный актив, однако его действие можно оценить. Насчет достоверности данных — для ранжирования важно чтобы методика ко всем одинаковая была применена.
Для работы с данными он по-моему не очень годится, если только в нём не сделать расширение по типу Linq. Правда я его (JS) не очень хорошо знаю, поэтому наверняка утверждать не буду. Чего по наблюдениям не хватает во фреймворках/GUI-programming, так это вкусных конструкций по типу «покажи мне все с/ф в диапазоне дат, введенном оператором» для простейшего вывода грида с с/ф и эдитбоксами дат (ну или отдельным запросом дат, в зависимости от плагина). В JS это бы выглядело, подозреваю, иначе.
Есть опыт разработки платформы с собственным языком. Под *nix правда. Если проект стартанет, готов подключиться к группе проектировщиков языка и/или библиотек.
Ну и сразу хочу сказать, что язык — это ключевой момент. 1С-программисты обходятся компании не так, как Java-разработчики например. Сложный язык никто не захочет изучать, простой же — должен быть расширяемым и гибким, и содержать в себе логику как GUI, так и СУБД. При склейке этого — можно родить монстра.
Но зато, при своём движке, можно прикручивать любые морды, что веб, что что угодно, любые базы, по системе плагинов.
Пожалуй, самое главное, что в процессе разработки используется время программистов и других специалистов, которое нужно оплачивать. И это время денег стоит. Вот смотрите, программист за месяц может поучаствовать в 1,2,3… проектах (не только разработкой, но и поддержкой, и так далее). Как разносить затраты по проектам? По часам.
Оценки «по аналогии» (разработка такого продукта может стоить «столько-то») неточны. Нет базы для совершенствования разработки и управления проектами в компании. Неизвестно, окупится ли мероприятие, или нет. А когда есть детальная разбивка по задачам, заметно снижаются и риски. Известно, что суммарная ошибка оценки падает при детализации как корень из N.
ИМХО, ИТ уже не та отрасль, в которой сверхдоходы крутятся. Всё больше становится, гм, промышленной что ли. Поэтому и подход к выполнению заказов — проектный, а в проектном деле оценка снизу-вверх (сроков, затрат, рисков, качества и др.) давно уже оправдывает себя.
Если совсем кратко, то оценка сроков нужна чтобы не облажаться по деньгам.
P.S. А тэг канбан к чему тут?
И более того. Если внимательно посмотреть на диаграмму Гантта (это там, где оценки), иногда можно ускорить проект раза так в два. Но agile диаграмма Гантта не нужна, я знаю.
Ну и сразу хочу сказать, что язык — это ключевой момент. 1С-программисты обходятся компании не так, как Java-разработчики например. Сложный язык никто не захочет изучать, простой же — должен быть расширяемым и гибким, и содержать в себе логику как GUI, так и СУБД. При склейке этого — можно родить монстра.
Но зато, при своём движке, можно прикручивать любые морды, что веб, что что угодно, любые базы, по системе плагинов.