khusamov
@khusamov
ReactJS, NodeJS, TypeScript, Sencha ExtJS

Как точно подсчитать время создания программного продукта?

Всем привет! У меня у одного такая проблема или у всех? Клиент спрашивает сроки выполнения заказа на ПО. Я называю Икс, а на практике выходит Икс помноженное на четыре.
  • Вопрос задан
  • 854 просмотра
Пригласить эксперта
Ответы на вопрос 7
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
это примерно то же самое что научиться абсолютно точно предсказывать погоду на месяцы вперед.

Есть хорошая мантра:

таски на 4 часа мы делаем за 4 часа, таски на 8 часов мы делаем за 12, таски на 16 часов мы делаем за 24, таски на 40 часов мы не делаем никогда.

Просто старайтесь делать декомпозицию задачи на как можно меньшие кусочки. И домножайте на коэффициенты рисков (в вашем случае - 4). Со временем этот коэффициент будет уменьшаться и вы будете точнее предсказывать сроки.
Ответ написан
Комментировать
@ruGuardian
В теории теория и практика совпадают. А на практике...
Можно очень долго пытаться строить из себя тайм менеджера крупного звена, играться с формулами, учитывать коэффициэнты форс-мажоров и никогда не стать вангой. Но сама жизнь подсказывает вам решение. Я с удовольствием использую этот метод и не подводило никогда. Следует набросать план и умножить срок на Пи. И признаться себе в том, что несмотря на твою гениальность и работоспособность - так оно и будет. Это психология нас подводит. Даже самый детальный план с десятками подзадач не включает такие пункты как: обед, сон, я заболел, я напился, кошка окотилась, теща приехала и т.д.. Оценивая задачу вы исходите из 100% занятости и максимальной фокусировке. Умножайте время на Пи это гарантированный прогноз (к финансовым тратам это относится аналогично).
Ответ написан
Комментировать
opium
@opium
Просто люблю качественно работать
ну значит вы свой икс берете с потолка , почему вы удивляетесь что он не совпадает с действительным?
систем оценки проектов куча прочитайте хоть про одну.
Ответ написан
max-kuznetsov
@max-kuznetsov
Главный IT-архитектор
Есть такая вещь, называемая фокус-фактором. Фокус-фактор показывает, какую долю времени в среднем тратит работник на действительно полезную деятельность. В самых лучших случаях значение этого коэффициента достигает 0,7, но можно считать хорошим результатом, если фокус-фактор достигает 0,6. В средних командах он близок к 0,55 (отсюда и "принцип умножения на 2").

Это очень важно учитывать при планировании работ. Так, если на выполнение некоторой задачи требуется 4 "идеальных" часа, когда исполнителя никто не отвлекает, то при фокус-факторе 0,6 он затратит на эту задачу не 4, а без малого 7 часов. Чувствуете разницу?

При этом у каждого члена команды фокус-фактор свой. И, если сроки критичны, нужно в планировании учитывать не среднее значение по больнице, а значение конкретных исполнителей конкретных задач. Но этого никто не делает.
Ответ написан
@Sk1talec
Фанат Java, Android и компьютерного зрения :)
Только опыт.
Если хочешь что-то из фундаментального, то почитай Фредерика Брукса "Мифический человеко-месяц"
Ответ написан
Комментировать
@Elizavetta
Matroid: gamedev/js-разработка
Если заказчик опытный, сам умножит на 3, но ваша задача приблизиться к коэффициенту 1,5 в оценке.
Также стоит учесть, что требовать абсолютно точной оценки заказчик имеет право, лишь предоставив абсолютно точное описание продукта, на практике же заказчик меняет "фичи", дизайн и др. в процессе разработки, и часто рассчитывает на те же сроки.
Ответ написан
Merovei
@Merovei
Возможно, Вам поможет глава 12 из бестселлера "The Deadline", чтобы подсчитать время создания программного продукта.

Вот резюме главы:

1. Определяйте размер каждого проекта.

2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.

3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).

4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.

5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.

6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.

7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.

8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы