Я, например, сталкивался со следующими случаями:1. когда примерно понятно что нужно делать
используется водопадный подход, то есть составляется подробный план работ с учетом работы по анализу (выявлению требований), тут экспертная оценка, например, 2 недели один человек, затем формируется детальный план работ: разработка этого, того, другого, оценивается примерное время на разработку каждой задачи, добавляется тестирование (где-то 30% от времени разработки). Вот и получается примерный план работ на известное количество участников. Нужно не забыть добавить риски, например умножить полученный срок на 0.2
из минусов: легко ошибиться в оценке, скорее всего план расползется и может пострадать чья-та репутация, время на оценку нужно как-то оплачивать.
2. когда совсем не понятно что нужно делать
используется agile подход. Весь проект делится на конкретные (небольшие!) этапы, на каждом из которых реализуются нужные функции (последовательно). После первого этапа становится примерно понятны возможности команды, то есть скорость ее работы, погрешность оценки и т.п. Остальные этапы оцениваются исходя из полученных данных.
из минусов: это последовательная работа, никто не знает конечной цифры стоимости проекта (хотя это можно перевести и в плюс).
из плюсов: заказчик часто получает результат, функционал постоянно корректируется в нужном направлении, заказчик тратит небольшие суммы за конкретно выполненную работу.
Я, например, часто использую второй вариант и в помощь привлекаю DEVPROM, который позволяет все нужные параметры работы команды посчитать и управлять списком пожеланий к функциональности продукта.
