Как вы оцениваете сроки и стоимость задач/проектов?

Question

[Пума Тайланд]

Собираюсь написать статью о методиках оценки стоимости, сроков, времени на выполнение задач.
Хотелось бы услышать как делаете это вы?

Answer 1

[Артур Смирнов]

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

Comments

[Пума Тайланд]

Чем вы это обосновываете?
Какие причины для этого?

[Артур Смирнов]

На самом деле любой проект практически 100% кроит в себе задачи которые не решить сразу, возможно они принципиально новые. На хабре была статья, собственно если честно формулу я взял из неё, и она практически всегда дает верное значение.

[Пума Тайланд]

А вы как то обосновываете такие сроки перед заказчиком?
Как вы это преподносите?

[Doktor_Gradus]

Предположим, есть задача, выполнение которой я оцениваю в 4 часа. По этой формуле я должен буду озвучить заказчику срок 4*2 + 8 * 5 + 8 * 3 = 72, то есть 9 дней? А в деньгах как? Стоимость 4 часов или 72 часов?

[Юрий Фирс]

Doktor_Gradus +1
Я думаю нужно разделить проекты на разные категории (например, проекты на пару часов/дней, проекты на пару недель и проекты на пару месяцев) и для каждой категории будет отдельная формула.
Тогда можно будет более адекватно применять эти формулы.
Но сами формулы уже должен сам разработчик(или менеждер) рассчитывать, т.к. она у каждого будет своя. ИМХО

Answer 2

[Ravmos]

для проекта, состоящего из более 20 взаимозависимых задач строим диаграмму ганта в MS Project.
Оцениваем сроки и стоимости для каждой из задач, расчет итогового срока получаем автоматически, помесячный бюджет финансирования также автоматически.

Для оценки каждой из задач, в случае, если раньше сталкивались, используем статистику, если не сталкивались, консультируемся у экспертов в этой области.

На составление плана и бюджета может уйти до нескольких недель при сроке реализации проекта более 2х лет.

Answer 3

[vaevictus]

Относительная оценка сложности плюс статистика. Самый простой вариант: Мы сделали проект ХХХ за месяц, данный проект втрое сложнее, значит за три месяца управимся. (Данный способ применяю, когда о команда новая, и статистики нет)

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

Однако, если у вас достаточно длительный проект, добавте ещё и статистику недоступности(заболел, проспал, плохое настроение) разработчиков (как правило, на 15 человек, 1 всегда недоступен). В идеале, ещё б и статистика по новым задача не помешала бы, если давно работаете с данным заказчиком, но это можно и другими методами решать.

Answer 4

[StepEv]

Например, так — step-e.livejournal.com/23685.html

Можно ещё почитать вот это www.ozon.ru/context/detail/id/3115179/

Ну и что-то такое — www.ozon.ru/context/detail/id/3182401/

Answer 5

[StepEv]

Да, ещё поищите статью по Use Case Points

Comments

[Warchoon]

В русском переводе — Функциональные Точки.

[StepEv]

Гоните. Это Functional Points. Принцип похож, но UC Points ближе к жизни. Если вы, конечно, используете UC или что-то близкое по духу для описания требований.

[Warchoon]

Ok. Есть пара но:
FP описывают реализацию, а UCP описывают требования.
Если, конечно, вы не работаете по MSF. Потому что MS как всегда взяли чужие термины и изгадили их свом смыслом: у них UC — не варианты использования, а сценарии.
В случае, когда UC — это сценарии, UCP вырождается в FP.
В случае, когда UC — это действительно UC, многие варианты использования задействуют уже отработанные сценарии из других вариантов.
В итоге имеем:
— UCP используют аналитики (не разработчики)
— в проектах с известной трудоёмкостью сценариев (не новый функционал)

[StepEv]

Извините, но это поток сознания какой-то.

UC — варианты использования, описываются набором сценариев. Так что у MS всё корректно по смыслу. Это просто форма записи требований, удобная. Так что используют их все в проекте, а не только аналитики.

В FP UCP выродиться никак не могут, потому что это они никак не пересекаются. Если вы записываете требования в виде набора функций — будут FP, в виде сценариев — будут UCP.

При известной трудоёмкости сценариев — вопрос оценки вообще не стоит. Она ж известна :)

Answer 6

[Vorchun]

Много типовых задач. Их на основе ранее сделанного.

Если что-то новое, то делаю разбиваю на части. Каждую часть отдельно описываю/проговариваю с техспециалистом. С командой давно (с 2007 года), т.ч. примерно знаю на какой коэффициент каждую оценку умножать.

Мне очень помогает mindmap для понимания картины, команде — драфты