я вынужден не согласиться, в EPAM так делают на потоке

а почему вы думаете, что не работает?

1. Оценки по ресурсам работают только для очень простых и знакомых задач. Даже на уровне user story/use case обычно сложно прикинуть реальные трудозатраты, так как прилетают неожиданные требования, которые по базе не учтены (в приведенном примере - добавь пожелание в transacions к полнотекстовому поиску по всем полям - и трудозатраты сразу резко изменятся)
2. В модели вообще нигде нет рисков по ресурсам (отпуск и т.п.)
3. В модели вообще нет не производительных ресурсов (тех же hr-менеджеров, уборщиц, админов инфраструктуры и т.п.).
Их можно упаковать в мультипликаторы или в рейт, но это не совсем корректно.
4. Какой смысл считать часовой рейт до второго знака, если мультипликаторы взяты фактически из головы.
5. Рисков вообще не видно, хотя и обещали.

Т.е. я верю, что в EPAM (и много где еще) так делают. Я не верю, что оно работает (т.е. дает реальные числа, не сильно отличающиеся от реальности для конкретного проекта).

Вообще, все известные модели оценок работают на знакомых одинаковых задач и для одной и той же команды и при наличии большой истории. Т.е. или на поддержке или на конвеере.

Вспомнилось: "Британский статистик Джордж Бокс как-то сказал: «В сущности, все модели неправильны, но некоторые полезны»"

1. Это правда, но это не означает, что теперт не надо ничего оценивать. Делаются предположения(что не нужен полнотекстовый поиск). Если оно потом не оправдывается, оценка должна быть учтена. Это ок, если до всех доведено

2. Согласен, это не учтено

3. Такие вещи включены в рэйт

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

5. Про риски я упустил, угу =((

Это правда. Но разработка ПО может быть относительным конвеером, что доказывает опыт больших сервисных компаний

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

Очень странно это включать в рейт, честно говоря. И надо бы указать, что рейт - это не про зарплаты, это некоторая абстрактная величина

Поэтому про ассампшаны написано в главе 1 про необходимый инпут :)

Да, это стоимость для клиента

Так реально рейт почти не отличается, так как он на 90% состоит из офиса, дохода, менеджмента, рисков и т.п.
Зарплаты там почти нет

Тогда это не про оценку проекта, а про выставление ценника, это вообще другой процесс )

:))

Фил, похоже, что "выставить ценник" сильно связано с "оценить проект" через "норму прибыли".

И да, если на этапе проработки концепта продукта получилось оценить затраты с точностью в 2-3 раза плюс минус - это хорошая оценка.