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

Для каждого этапа жизненного цикла проекта существуют разные методики. Например, когда у вас есть набор юз-кейсов, описывающих проект, то можно воспользоваться 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

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

Это сообщение отредактировал(а) batigoal - 6.9.2007, 13:59

Оценивание трудозатрат

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

1.    Определите, насколько точной должна быть Ваша оценка. Обычно, чем точнее должна быть оценка, тем более детальным должно быть Ваше представление о проекте, и тем больше времени на этой уйдет. Если перед Вами задача получить приблизительную оценку трудозатрат (rough order of magnitude, ROM) в границах (-25%, +75%), Вы должны выполнить эту работу максимально быстро, не вдаваясь в мелкие детали. Возможно, Вы даже сможете произвести оценку с такой точностью в уме, основываясь на Ваших собственных знаниях. С другой стороны, если Вам нужно получить точную оценку в пределах 10% точности, Вам придется потратить больше времени и вникнуть в детали работы достаточно подробно.
2.    Создайте начальную оценку трудоемкости для каждой работы в отдельности и для всего проекта в целом, используя приемы, описанные в разделе "2.2.1 Методики оценивания".
3.    Откорректируйте трудозатраты в зависимости от назначенных ресурсов (дополнительно). Вероятнее всего, Ваши оценки основываются на трудозатратах, которые должен потратить на выполнение работ некий осредненный ресурс (или если бы эти работы выполняли Вы сами). Иногда Вам также бывает известно, какой конкретно ресурс или тип ресурса будет назначен на те или иные работы. Если это так, Вы можете сделать оценку больше или меньше, основываясь на понимании особенностей предполагаемого ресурса. Например, Вы оценили, что на работу уйдет 40 человеко-часов. Тем не менее, Вам также известно, что человек, назначаемый на эту работу - неопытный стажер. В этом случае Вы можете удвоить оценку до 80-ти часов. Другой вид деятельности может быть оценен в 200 человеко-часов. Однако, Вам известно, что нанимаемый Вами человек имеет большой опыт в выполняемой работе, поэтому Вы можете спокойно уменьшить оценку до 150-ти человеко-часов. Очевидно, что такой подход может применяться только в случаях, когда Вы имеете некоторое представление о реальных ресурсах, назначенных на Ваш проект.
4.    Добавьте время на специализированные ресурсы. Удостоверьтесь, что Вы включили время на работу совместителей и специализированных ресурсов. Это могут быть внештатные сотрудники, специалисты по тренингам, административные помощники и т.д. Эти люди поначалу могут не показаться необходимыми явно, но они могут потребоваться Вам для выполнения особых работ. Поскольку такие специалисты выполняют в проекте вспомогательную роль, Вы, вероятнее всего, могли просто забыть включить их работы в исходную Структуру Декомпозиции Работ.
5.    Учтите доработки (дополнительно). В идеальном мире все результаты проектов будут правильными с первой попытки. В реальных проектах такое, как правило, не встречается. Планы работ, не учитывающие возможность доработки результатов, могут легко закончиться недооценкой общих трудозатрат, необходимых для создания конечного продукта. Это нельзя путать с изменением объема проекта. Если Вы произвели продукцию, не отвечающую первоначальным требованиям или с проблемами в области качества, то может потребоваться ее доработка. Если созданный Вами конечный результат неприемлем из-за появления дополнительных требований к характеристикам или функциональности, тогда нужно организовать внесение изменений в объем проекта. Существует несколько подходов к отображению трудозатрат и времени, связанных с доработкой. 
°    Прибавить к исходной оценке. Это наиболее типичный подход. Если Вы думаете, что результат потребует 50 часов работы, Вы, скорее всего, сможете в уме представить время, необходимое для одного или двух исправлений.
°    Добавить отдельные работы. При этом подходе Вы оцениваете трудозатраты, необходимые для первоначального получения выходной продукции, а затем добавляете второй набор работ, трудозатрат и времени для выполнения исправлений и при необходимости идете по второму (или третьему) циклу работ.
°    Добавить блоки времени. Вместо добавления доработки к каждому конечному результату, можно добавить блок времени на все доработки в конце фазы проекта. По сути, это добавление резервного "буфера" по бюджету и графику, который поможет компенсировать все дополнительные работы, связанные с доработкой целой группы результатов. Трудозатраты и стоимость, закладываемые в такой резерв, могут основываться на индивидуальной оценке каждой из возможных доработок или просто на проценте от времени, необходимого для разработки соответствующей выходной продукции. 
6.    Добавьте время для управления проектом. Это трудозатраты, необходимые для успешного и упреждающего управления проектом. Вы можете включить работы по управлению проектом в СДР. В таком случае, Вам не потребуется делать что-либо еще дополнительно. Если же Вы не включаете работы по управлению проектом в явном виде, то в итоге Вам нужно будет добавить к оценкам проекта еще 15% трудозатрат. Например, если проект оценен в 12000 человеко-часов (7 - 8 человек), тогда потребуется руководитель проекта на полную занятость (1800 часов). Если оценка проекта 1000 человеко-часов, то трудозатраты руководителя проекта будет оцениваться в 150 часов. Этого недостаточно для полной занятости, поэтому руководитель проекта будет или одним из ресурсов проекта по совместительству или у него (или у нее) также будут внепроектные обязанности.
7.    Добавьте резервные часы. Резервы используются для компенсации неопределенностей или рисков, связанных с неточностью оценивания. Если Вам поручают оценить работу, которая недостаточно подробно определена, Вы можете добавить 50%, 75% или более для учета неточностей. Если оценку нужно было произвести в короткий срок, это также может потребовать очень большого резерва. Даже если у Вас было достаточно времени для создания основательной и точной оценки, резерв все равно должен быть и может составлять 10-25%. Отсутствие резерва должно означать только то, что Вы на 100% уверены в своей оценке. Такое может случиться, если у Вас большой опыт выполнения подобных проектов. Добавляя резерв на неопределенность, наилучший выход - отобразить его отдельно. Тем не менее, Ваша организация может не позволить включать такие резервы официально. В таком случае, у Вас может не быть другого выбора, кроме как пропорционально увеличить оценки всех основных работ проекта. Такой подход не предпочтителен, но это Ваша естественная реакция на внешние ограничения, причем реакция в интересах успеха Вашего проекта.
8.    Вычислите общие трудозатраты путем суммирования всех оцененных работ.
9.    Проверьте и откорректируйте при необходимости. Иногда при объединении оценок отдельных работ может показаться, что некоторые из них явно завышены или занижены. Если Вам оценка не кажется правильной, вернитесь и откорректируйте оценочные допущения для более верного отображения действительности. Также удостоверьтесь, что Ваша оценочная модель последовательна и рациональна. Например, если запланированы повторяющиеся работы, Вы можете изначально посчитать общее количество трудозатрат, умножая трудоемкость одной работы на количество ее повторений. Тем не менее, в ходе дальнейшей оценки Вы можете обнаружить, что трудозатраты на выполнение этой работы будут с каждым разом уменьшаться, поскольку персонал наберется опыта. Вам также нужно будет удостовериться, что похожие работы имеют подобные оценки трудозатрат, в противном случае их нужно будет откорректировать.
10.    Задокументируйте все допущения. Вы никогда не будете достоверно знать обо всех тонкостях проекта. Поэтому, важно задокументировать все допущения, которые Вы принимали в ходе выполнения оценивания.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

zbuk, зачем заниматься массовым копи-пейстом статей? Лучше бы выложили краткую суть одним абзацем, или примеры привели.

По-моему чаще всего так и бывает - сроки даются сверху. Я вижу только 2 причины: 
1. ПМ'ы не доверяют оценкам разработчиков: тут на сколько я понимаю и при методе Кларка ПМ должен обращаться к разрабам за более детальной оценкой, т.к. чаще всего узкому спецу лучше известно за какое время возможно реализовать функционал.
Причины - неопытный коллектив или ПМ в этом полностью убежден 
2. нет времени на планирование, ПМ хватается за проект не думая о сроках.
Скажите, насколько активно команда должна принимать участие в планировании? Или спланировать всё может и сам ПМ?

arilou, спасибо за описание методов. Эти методы только для presale; а какие методы Вы используете для следующих после presale этапов (тех. проектирование, ...)?


О каких реализациях этих систем идет речь?

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

вот они, ягодки waterfall-а.

Странно у Вас. Почему проект стартует до утверждения окончательного срока?