Какова допустимая погрешность при оценке продолжительности проекта?

Компания, в которой я работаю, стремится к максимальной погрешности в 10%. Они ожидают, что аналитики не пропустят оценку более или менее чем на 10%.

Я не знаю, что об этом думать, так как мне не с чем сравнивать.

Что может быть хорошей базой для измерения, если мы оцениваем слишком неправильно, более или менее? Сколько (в%) Как вы думаете , это нормально , чтобы пропустить?

Если вы не оцениваете что-то очень похожее на то, что вы и ваши коллеги делали раньше, +/- 10% смехотворно оптимистично. Ваше руководство либо не имеет большого опыта работы с программным обеспечением, либо они не знают о больших ограничениях в оценке программного обеспечения . Этот документ имеет некоторые сопроводительные материалы и много мужественных .

Давайте рассмотрим гораздо более простую систему, чем типичный программный проект: кубик Рубика. Вы можете решить любую позицию за 20 ходов , макс. Но так как вы оцениваете, вы можете посмотреть на данный куб только на несколько минут, прежде чем предлагать решение. Можете ли вы дать хорошую оценку? Нет, иногда оценка процесса занимает больше времени, чем процесс.

Еще одна простая система: Буратино. Деревянный автомат, его носовая часть растет, когда он произносит ложь. Что происходит, когда Буратино отдыхает, а затем говорит: «Мой нос растет»? Некоторые системы не поддаются прогнозированию, они неразрешимы.

Эти две проблемы встроены в большинство программных систем. Из-за этого вы никогда не получите оценки, близкие к +/- 10%.

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

Я бы очень сомневался по поводу какого-либо «целевого запаса ошибок», потому что это действительно зависит от проекта. Если вы пытаетесь оценить, сколько времени потребуется, чтобы установить, настроить и настроить новую систему CRM, в которой никто не уверен, какие настройки будут необходимы и какие изменения в бизнес-процессах понадобятся, и у компании нет истории подобных крупных проектов, ваша погрешность должна быть довольно большой (то есть вы можете догадаться, что это займет 18 месяцев +/- 50% и котируется 9-27 месяцев). По мере продвижения проекта спецификации становятся более четкими, принимаются решения относительно бизнес-процессов, вашим разработчикам становится удобнее и т. Д., Эти границы ошибок должны становиться все жестче. Если вы пытаетесь оценить, сколько времени вы собираетесь создать 101-й сайт базовой электронной коммерции, когда вы Если у вас есть хорошая история из первых 100, вы ожидаете, что сможете дать гораздо более точную оценку. Большинство проектов, однако, упадет где-то посередине.

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

Хороший базовый уровень будет один на основании реальных данных , вы собрали.

Первым шагом для этого является запись всех оценок . Второй шаг запись фактических результатов . Будьте честны, не поддавайтесь соблазну «саморегулировать» фактическое. Соберите достаточно этой информации, и у вас есть некоторые данные для статистической базы, насколько хороши ваши оценки. Обратите внимание, что это может / будет сильно отличаться в зависимости от того, кто сделал оценку и кто работает. Только делая это, можно разумно ожидать, что вы получите «предел погрешности», который является чем-то другим, чистым мусором.

Это не останавливается там также; Анализ причин отклонения оценок может помочь повысить точность ваших будущих оценок. Примечание: они все еще остаются оценочными , и, как таковые, являются только оценочными .

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

Во-вторых, возможно, лучшим способом обработки погрешности является « внутреннее доверие », а не просто% погрешности. Вы основали свою предполагаемую дату доставки на доверительном интервале, а не на единственной дате.

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

«Исходя из того, что я знаю сейчас, у нас есть уровень доверия 90%, который мы можем достичь за 8 месяцев. Доверие 95% за 10 месяцев, доверие 99% за 2 года и т. Д.»

Обратите внимание: чем увереннее они вас хотят, тем больше будет оценка. В зависимости от сложности (точнее, насколько точной вы могли бы быть), это может быть небольшая разница между 80% и 90%, или она может быть огромной!

И наконец - удачи;) Если вы когда-нибудь решите «максимальную погрешность» в оценке программного обеспечения, при которой вы можете указать что-то вроде «все наши оценки будут +/- 10%», обязательно запустите кассовый фильм на оставшуюся часть мы в индустрии программного обеспечения. Я думаю что-то вроде помехи между Office Space и The Matrix: D

На самом деле это во многом зависит от размера и сложности проекта.

Если оценка вашего проекта, скажем, 1 неделя - 10% разумно. Это означает +/- 1/2 дня.
Если это 1 месяц, то 10% шатко - из моего опыта невозможно предсказать, что вы обнаружите через 1 месяц.

Больше месяца - все ставки сняты :).

Они рассчитаны на одного разработчика, поэтому для группы из 4 разработчиков 1 неделя == 1 месяц.

Для группы разработчиков из 4 человек, в основном, полезно составить список функций, которые могут быть выполнены за 1 месяц, и быть в пределах 10% для этих функций. Затем переоцените на следующий месяц.

Я сделал несколько наивных предположений здесь

1. Все разработчики могут выполнять работу параллельно.
2. Не считали тестером - у них должно быть время для тестирования
3. Все разработчики равны - Frontend, Backend, Designers и т.д ...

Вы должны учитывать это в ... но это общая идея.

Есть много переменных:

1. Как долго длится проект?

2. Как будет управляться проект? Водопад? Agile? SCRUM?

Я бы предположил из вопроса водопад. Если это так, вы, скорее всего, потерпите неудачу на некоторый процент, учитывая запрос на маржу.

Если ответ - какая-то гибкая методология, особенно что-то вроде SCRUM. Неважно, какой процент маржи. Погрешность 50% на 2-недельном Спринте составляет 1 неделю, на 1-недельном Спринте - 2,5 дня, что является крайне неблагоприятным сценарием. Это связано с тем, что дата доставки переоценивается с каждым Спринтом, и с течением времени она будет становиться все более и более точной, а не все меньше и меньше.

С Waterfall 50% погрешности тоже не слышны, но за 12-месячный проект, который длится 6 месяцев, и его действительно не обнаруживают и не восхищают, это так плохо до 10 месяцев из 12.

В те времена, когда я руководил командами разработчиков программного обеспечения, примерно на границе между Меловым и Третичным, мы фактически приблизились к достижению +/- 10% по оценке. Было около +/- 15%, если мне не изменяет память. Но это было потому, что мы оценивали то, что уже сделали : относительно простую коммуникационную прошивку в реальном времени, которая брала байты из A и перемещала их в B, используя знакомый нам язык, в среде реального времени, разработанной нами. , разговаривая с оборудованием, разработанным парнями в нескольких офисах. Множество небольших вариантов на вышеуказанную тему, буквально за годы .

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

Вы, наверное, слышали 300%, верно?

Я на самом деле использую это. Полностью основано на том, что я видел годами. Когда я слышу , день или два, это в неделю или больше , чтобы быть действительно сделано . И проверено. Во всех средах. Документация обновлена. Юзабилити проверено. Производительность проверена. Нагрузка проверена. Пара часов действительно больше похожа на день.

Я думаю, что мы действительно плохо оцениваем из-за:

• Помогать другим
• Быть прерванным
• Обучение новых людей
• Другие вещи, подходящие
• Заболевание или недомогание
• Охватывает людей, которые уходят
• Необходим отпуск или выходной
• Отвлекаться на других
• Поддерживается другими группами
• Быть чрезмерно оптимистичным по сравнению с реалистичным
• Не выделяется время для работы при периодических неудачах теста
• Легко исключая время на тестирование, в частности написание автоматических тестов

Таким образом, на самом высоком уровне, когда деловые люди нуждаются в оценках, превышающих 300%, мы в конечном итоге стремимся получить достаточно хорошие оценки, но ценой более высокого уровня и общего характера. «У нас будет функция редактирования пользователя», даже если версия 1 означает только 1 группу пользователей для изменения 1 поля.

Когда дело доходит до «Какова допустимая погрешность при оценке продолжительности проекта?» Я считаю, что этот подход, используемый во многих Agile-средах, помогает изменить вопрос на минимальную функциональность, чтобы запустить альфа- или бета-версию, а затем повторить ее.