Однажды мне надо было сделать грубую оценку трудозатрат на один проект. Чтобы не вдаваться в подробности, на том этапе проект описывался в виде ервиновских файлов, в которых были расписаны процессы для каждой из подсистем. Нужно было дать клиенту ответ, примерно в какой диапазон она попадет.

Для каждого этапа жизненного цикла проекта существуют разные методики. Например, когда у вас есть набор юз-кейсов, описывающих проект, то можно воспользоваться Use Case Points (http://www.codeproject.com/gen/design/usecasepoints.asp). А что делать, когда информации мало?

Для данного проекта я воспользовался следующим подходом. Я постарался более менее детально оценить сложную (по кол-ву процессов и взаимодействий) из подсистем,  а потом просто на глаз прикинул отношение других по размеру файла    Ну есессно потом коэффициенты всякие ввел (на ПМ, на тестинг, и т.п.), но в основе суть была именно такая.

А какие методики используете вы?

Лично я стараюсь следовать рекомендациям Джоэла Спольски: максимально детализированно описываешь проект и определяешь трудозатраты для каждой атомарной составляющей (атомарность вплоть до "добавить на форму кнопку"). Суммарную величину умножаем на некоторый коэффициент для учёта различных неблагоприятных ситуаций, вроде цунами в пустыне Гоби.
Если же с информацией совсем туго, то стараюсь описать, что могу и на глазок прикинуть трудозатраты оставшихся частей. Коэффициент в этом случае, естественно, беру выше.

Неужто кроме нас двоих никто использует ничего более-менее систематического для определения трудозатрат? Или наоборот - все используют именно такие схемы? Что-то мало верится...

а как оценить трудозатраты на работу, если есть только общее описание требуемого?
 

Мы оценивали трудозатраты на наш текущий проект с помощью Use Case'ов (предварительно было составнено достаточно подробное их описание)
Расчетные значения получились примерно в 3-5 раз больше чем реальные трудозатраты на проект.



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

Ну, примерно то же самое и у Джоэла. Кстати, такая система мало подходит, если нужно выдать заказчику предварительную оценку трудозатрат. Но там, по идее, большая точность и не требуется. Главное слишком сильно не промазать в сторону занижения сроков. Да и "вверх" тоже - иначе не закажет. 


Были у меня подобные ситуации. В этом случае выбирается человек, который больше всех слышал о требуемой области и отправляется чуток разобраться, чтобы мог давать консультации вроде "можно/нельзя/возможно удастся сделать" и "легко/сложно/практически невозможно реализовать". Можно и самому - так даже лучше, но не всегда удаётся (часто проще найти или "сделать своего" эксперта). Имея хоть какие-то данные из предметной области, уже можно начинать рассчитывать трудозатраты. Главное - взять коэффициент повыше, иначе скорее всего вылетишь из сроков.

упс, извините... 


как раз этим методом мы и пользовались

Скорее всего, вы переоценили трудозатраты на юз-кейсы, или они перекрывались, или оценивали для новичков, а реально проект делали более опытные программеры.
И, то что вы называете реальными трудозатратами, включает в себя время на management, testing, integration?


На самом деле, есть несколько способов оценки на этапе pre-sale (когда о проекте известно, в лучшем случае, базовые требования)

1) Концептуальное проектирование. Строится концпетуальная архитектура системы (не путать с реальной!!!), оцениваются по отдельности ее составные части. Оценки суммируются. Главное - не проектировать глубоко, т.к. с глубиной проработки ухудшается оценка.

2) Крупномасштабная аналогия: обращаетесь к своему предыдущему опыты и ищете проекты:
    - Схожие по размерам 
    - Схожие по типу
    - Схожие по размерам компонентов
    - Схожие по типам компонентов
    - Схожие по типу и объему требований
    Для этого метода требуется система хранения исторической информации

3) Wideband Delphi (типа "повышение шансов"). Это командный метод, суть которого сводится к раздаче требований участникам, они независимо оценивают, потом оценки и предположения собираются и консолидируются, потом все опять оценивают, и т.д. пока 4 итерации не пройдет, или оценки сойдутся к приемлемо узкому диапазону, или истечет время, выделенное на проведение оценки, или все решат, что больше оценки уточнять не стоит.

4) Метод Кларка
    - Разбить на модули
    - Сделать хорошие оценки для каждого модуля
    - Определить верхнюю и нижнюю границу оценки
    - Размер оценки = Сумма((Наибольшая оценка + 4*Среднее значение + Наименьшая оценка) / 6)

При этом, есть повышающие коэффициенты:
    - X 5 для обеспечения безопасности ПО
    - X 5 для внедренных систем
    - X 1.5 для повторно используемого кода (reusable code)
    - X 2.5 для распределенных систем

Имейте введу следующее:
1) Эти методы работают для этапа предпродажной работы (pre-sales), когда информации о проекте крайне мало, а клиент хочет получить цифры
2) На последующих этапах проект надо переоценивать заново, чтобы уточнять итог
3) Сколько будет стоить проект, будет известно только по его окончании   
4) Обязательно нужно вести историю оценок

arilou, 
это все сдорово, но если ты(то есть я) и выполняеш сам заказ?
или ты должен назвать цифры, а потом под эту сумму и время  нанять людей и тд.

Не понял вопроса... 

А какая разница, сам будешь выполнять заказ или найдёшь команду? Если ты изначально знаешь, кто будет выполнять заказ - рассчитываешь трудозатраты исходя из его (их) производительности. Если не знаешь (будет команда, но её ещё надо набрать и сплотить), то просто увеличиваешь расчётные трудозатраты при помощи коэффициента.

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

   я понял, что наверно тут все надо пощупать самому и на своей шкуре испытать. на форуме это не решить.
спасибо.

Ну опыт приходит, но попробовать самому обязательно надо.

Прошу прощения, если скажу глупость.
Я встречал  следующую методологию:
речь идет о "внутренних проектах" корпоративных(имеющих много уровней, подразделений, отделений и тд.) оргаизаций с российской спецификой.

В головном офисе сидят топ-манагеры(ПМы), долго и муторно разрабатывают(любым способом) сроки.
Этот "план" уходитв отделы, там местные манагеры просто срезают 10%(или больше) от крайнего срока,
чтобы как я понимаю подстраховаться,
далее это продолжается ровно столько, сколько исполнительных уровней в организации, а непосредственным исполнителям приходится из шкуры лезть, чтобы успеть за 30-40 % реально разработанной схемы.

вот такая российская специфика.


Это сообщение отредактировал(а) SpaceSpace - 4.9.2007, 11:52