Что лучше: настроить недооцененные или завышенные крайние сроки? [закрытый]

Вам следует использовать наилучшее предположение, которое является функцией минимальных и максимальных оценок *, а не только простое среднее -

best_guess = (min * min_weighting + max * max_weighting) / divisor *

* Том Нейланд предлагает, чтобы оно было (min_weighting + max_weighting) . На самом деле я не уверен, правильно ли это, но, вероятно, он более правильный, чем мой первоначальный делитель 2.0 .

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

Вам также следует использовать эти значения, а также значение уверенности при разговоре с высшим руководством и клиентами. Хотя давать максимум и делать рано - это не то же самое, что давать минимум и делать поздно, это все же показывает, что вы не контролируете свое развитие.

Придание уверенности и представление о рисках также поможет управлять ожидания, поэтому, если есть проблемы, они не являются неожиданными.

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

Не используйте ни минимум, ни максимум, а что-то среднее.

Лучше ошибиться в сторону завышения. В долгосрочной перспективе у него будет гораздо более приятное поведение по затратам.

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

• Дополнительные затраты из-за неэффективности из-за синдрома студента ведут себя линейно.

Оценки и цели разные. Вы (или ваши менеджеры и клиенты) устанавливаете цели, которых необходимо достичь. Оценки говорят вам, насколько вероятно, что вы достигнете этих целей. Срок - это одна из целей. Выбранный вами крайний срок зависит от того, какой уровень уверенности (риск несоблюдения срока) вы готовы принять. P50 (вероятность уложиться в срок 0,5) - обычное дело. Иногда вы можете захотеть составить график с P80 или другим уровнем уверенности. Обратите внимание, что кривая вероятности является длиннохвостой, и чем больше уверенности вы хотите, тем дольше вам нужно будет выделить время для проекта.

В целом, я бы не стал тратить слишком много времени на отслеживание отдельных задач. С целевыми показателями P50 половина из них в любом случае опоздает. Важнее всего то, как ведет себя агрегат. При составлении оценок отдельных задач в совокупность ни минимум, ни максимум не имеют смысла. Крайне маловероятно, что все задачи будут выполнены за минимальное время (скорее всего, что-то вроде времени P10) или максимальное время (например, время P90): для n задач P10 / P90 вероятность составляет 0,1 ^ n.

PERT имеет некоторые методы для создания разумных распределений вероятностей продолжительности задач и их объединения в более крупные целые. Я не буду здесь вдаваться в математику. Вот какой указатель для дальнейшего чтения:

• Стив МакКоннелл: Оценка программного обеспечения - демистификация черного искусства . Это вполне читабельно и прагматично, но, по крайней мере, первое издание, которое у меня есть, имеет некоторые причуды в математике и прочем.

• Ричард Д. Штутцке: Оценка программно-ресурсоемких систем - проектов, продуктов и процессов . Это немного более академично, сложнее для чтения, но, например, лучше объясняет математику.

Вместо этого запросите оценки наилучшего , вероятного и наихудшего сценария . Затем используйте Методику оценки и анализа программ . Однако вы можете сначала взглянуть на некоторую критику PERT .

Для отдельных задач или задач, составляющих критический путь , просто неразумно прибегать к оценке наилучшего случая. Это все равно что сказать, что проект абсолютно лишен риска и неопределенности. Если реальная работа окажется совсем не в лучшем случае, вы в конечном итоге сорвете график. Лучше получить дополнительное время и заполнить его некоторыми полезными вещами, а не работать по ночам и в выходные.

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

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

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

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

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

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

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

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

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

Это также позволяет вам устанавливать сжатые сроки для разработчиков, не давая им слишком много стресс, потому что они будут знать, что вы рядом, чтобы помочь скорректировать сроки, когда это необходимо.

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

What are you using the estimates for? Specifically, why will the developer feel stressed if you normally underestimate?

If you're trying to schedule how long something is likely to take, you go for an intermediate value. Probably on the long side, since people normally underestimate. In any case, you shouldn't be using these estimates as firm objectives for developers, and so they shouldn't be overly stressful.

If you're using these estimates to set up commitments, you need to err on the side of overestimating. Giving developers insufficient time leads to burnout, unmaintainable buggy code that doesn't do quite what the user wants, and low morale and high turnover. Set the commitments to be reachable, and encourage the developers to finish early.

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

Что касается первоначального вопроса, я думаю, что я сломаюсь. Изложите это на несколько различных результатов и рассмотрите каждый из них:

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

Незначительная недооценка -> В этом случае либо есть расширение, либо объем сокращен, либо в выпуске есть некоторые ошибки, но это лучше, чем в предыдущем случае.

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

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

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

Это просто мое мнение о каждом, и другие могут иметь другое отношение к этому, чем я.

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

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

Это просто мое мнение о каждом, и другие могут иметь иное мнение, чем я.

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

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

Это просто мое мнение о каждом, и другие могут иметь иное мнение, чем я.

Это зависит от проекта.

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

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

Но в любом случае MAX-время не должно использоваться: это самая неточная мера, которая обычно приводит к еще большему времени. И вот простая причина: когда разработчик просто выдает этот MAX, он почти не измеряет. Он просто выдает свою интуицию, которая имеет очень мало информации в то время. Но если он потратит хотя бы полчаса, то поймет специфику своих задач, он даже может разделить ее на подзадачи и повысить точность. Таким образом, вы можете дать разработчику некоторую предвзятость вроде "эй, ребята, просто подумайте, за какое время вы предоставите здесь стабильный код", но отправьте его измерять самому. Это хорошо для работы, это хорошо и для самого программиста.

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

In Agile / Scrum, вы не устанавливаете жесткие сроки, а устанавливаете, «сколько часов осталось на эту задачу». Каждый день вы обновляете количество оставшегося времени. Вы не отслеживаете потраченные часы, но отслеживаете их приблизительные оставшиеся часы и стараетесь оставаться честными в этом отношении.

Если у вас есть ленивые разработчики, это плохо, потому что они легко могут обойти эту систему. Если у вас есть достойные разработчики, это здорово.Они довольно быстро становятся лучше в оценке, и вы, как руководитель проекта, узнаете, насколько надежны их оценки, и вы гораздо лучше почувствуете, какие оценки следует пропустить по цепочке на основе оценок отдельных разработчиков. {{1 }}

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

Если есть сомнения в соответствии с обещание и сверхдоставление: вы хотите быть человеком, который дает больше, чем они ожидали, а не меньше. Исходя из этого, всегда руководствуйтесь большей из оценок.

Немного сложнее:

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

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

Реже понимают, что если вы дадите среднее значение (предполагая, что ваши минимальные и максимальные усредненные значения дают что-то приблизительно равное фактическому среднему), вы достигнете этого срока только в 50% случаев.Фактически, если вы используете среднее значение, вы пропустите крайний срок вдвое . Не знаю, как вы, но мне не нравится, когда меня считают парнем, который пропускает половину своих сроков.

Итак, вам нужно число, которое даст вам то, что вы нажимаете, скажем, в 90% случаев. Для удобства 95% представляет собой среднее значение + два стандартных отклонения, но если у вас нет возможности вычислить это (а у большинства из нас, вероятно, нет данных), мой опыт говорит, что:

(3 x max + 1 x min ) / 4

дает разумный результат.

Между прочим, то, что вы сообщаете разработчику о крайнем сроке, - это совершенно другой вопрос. Лично я бы дал ему где-то около ((2 x max + 1 x min) / 3), а остальное оставил бы на всякий случай.

Первая ошибка, которую большинство сметчиков допускают при определении сроков, заключается в предположении, что разработчик будет работать над задачей полный рабочий день, что является катастрофической ошибкой. Это может привести к несоблюдению сроков, даже если вы используете завышенную оценку для определения сроков. Не уложиться в отведенные часы, но не уложиться в срок, о котором вы сообщили клиенту, - большая проблема. Люди уходят в отпуск, болеют, работают в суде присяжных, должны посещать необходимые собрания по новой кадровой политике, их вызывают на помощь в другой проект, когда кто-то застрял, им приходится загружать программное обеспечение на новый компьютер, когда старый сломался, исследовать производственную проблему в коде, который они недавно развернули, и т.д. Если вы оцениваете более 6 часов в день на проект на человека, то у вас уже есть проблемы со сроками до начала проекта. Когда я занимался изучением трудовых ресурсов, мы использовали цифру, которая равнялась чуть более 6 часам в день непосредственной работы, когда рассчитывали, сколько людей необходимо для любой работы. И мы проводили много статистического анализа в качестве основы для цифры, которую мы использовали.

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

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