Что лучше — переоценка или недооценка?
На интуитивном уровне ясно, что точная оценка закладывает идеальную основу для планирования проекта. Наличие точных оценок позволяет эффективно координировать работу между несколькими разработчиками.
Результаты, выдаваемые одно группой для другой группы, планируются с точностью до дня, часа или минуты. Но мы знаем, что точные оценки встречаются редко, и раз уж нам все равно суждено ошибиться — в какую сторону это лучше сделать? В сторону завышения или занижения?Аргументы против переоценки
Начальство и другие заинтересованные стороны иногда опасаются, что при переоценке проекта вступит в силу закон Паркинсона — принцип, согласно которому любая работа заполняет все отведенное для нее время. Если дать разработчику 5 дней на решение задачи, которую можно решить за 4 дня, разработчик придумает, чем заняться в лишний день. Если дать группе 6 месяцев на завершение проекта, который можно завершить за 4 месяца, группа найдет способ использовать лишние два месяца. В результате некоторые начальники сознательно поджимают оценки, пытаясь избежать действия закона Паркинсона.
Другая потенциальная проблема — «студенческий синдром» Голдрэтта (Gold- ratt 1997). Если выделить разработчикам слишком много времени, они работают спустя рукава. Когда проект близится к концу, начинается аврал, и скорее всего, разработчики не успеют сдать проект к сроку.
Недооценка также часто применяется еще по одной похожей причине — из-за желания внушить группе разработчиков чувство срочности проекта. Обоснование выглядит примерно так.
Разработчики говорят, что проект займет 6 месяцев. Наверняка, в их оценках есть какие-нибудь допуски и излишества, которые можно отжать. Кроме того, в проект нужно заложить плановую срочность, чтобы обеспечить его приоритетное исполнение. Значит, нужно настаивать на 3-месячном сроке. Конеч7ю, я не верю, что проект можно завершить за 3 месяца, по разработчикам назову именно этот срок.
Если я прав, разработчики все сделают за 4 или 5 месяцев. В худшем случае потребуются те 6 месяцев, которые были названы в изначальной оценке.Насколько убедительны эти аргументы? Чтобы выяснить это, необходимо изучить аргументы в пользу смещения в другую сторону, то есть переоценки.
Аргументы против недооценки
Недооценка создает множество проблем — как очевидных, так и скрытых. Снижение эффективности планирования. Заниженные оценки подрывают эффективность планирования и закладывают неверные предположения в планы выполнения некоторых операций. Они могут привести к ошибкам планирования в численности группы — скажем, заложенная в план численность группы окажется меньше необходимой. Также могут быть подорваны возможности координации между группами — если группа не успевает завершить работу к положенному сроку, другие группы не смогут использовать ее результаты.
Что лучше — переоценка или недооценка? 41 Если ошибка оценки приводит к нарушению плана всего на 5 % или 10 %, она не вызовет серьезных проблем. Однако многочисленные исследования показали, что оценки программных проектов часто оказываются неточными на 100 % и более (Lawlis, Flowe, and Thordahl 1995; Jones 1998; Standish Group 2004; ISBSG 2005). Если предпосылки планирования неверны до такой степени, планы среднего проекта настолько отрываются от реальности, что становятся практически бесполезными. Статистическое снижение вероятности своевременного завершения. Разработчики обычно склонны оценивать объем работы на 20-30 % ниже реального (van Genuchten 1991). Даже если просто воспользоваться их обычными оценками, планы проекта будут слишком оптимистичными. Дальнейшее сокращение оценок делает своевременное завершение еще менее вероятным. Плохая техническая база ухудшает результат по сравнению с номиналом. Заниженная оценка может привести к тому, что на предварительные операции (такие, как постановка требований и проектирование) будет потрачено слишком мало времени. Если же требованиям и проектированию уделено недостаточно внимания, вам придется переделывать и то и другое на более поздних стадиях проекта, причем с большими затратами, чем при своевременном выполнении этих операций (Boehm and Turner 2004, McConnell 2004a).
В конечном итоге работа над проектом займет больше времени, чем при точной оценке. Деструктивная динамика поздней стадии работы над проектом ухудшает результат по сравнению с номиналом. При переходе проекта в состояние «опоздания» рабочим группам приходится тратить время на действия, не нужные для «своевременных» проектов. Вот лишь несколько примеров: Дополнительные встречи с начальством с обсуждением хода работ и мер, призванных вернуть проект на правильный путь. Частые переоценки для определения уточненной даты завершения проекта. Общение к важными клиентами по поводу нарушения срока поставки (в том числе и посещение собраний с участием этих клиентов).« Подготовка промежуточных версий продукта для выставок, демонстраций и т. д. Если бы проект был готов вовремя, можно было бы использовать саму программу вместо промежуточных версий.
« Дополнительные дискуссии по поводу того, какие требования абсолютно необходимо включить в задание из-за задержки проекта.
« Решение проблем с наспех сделанными обходными решениями, которые пришлось реализовать ранее из-за поджимающих сроков.
У всех перечисленных действий есть одна важная особенность: они совершенно не нужны, если работа над проектом идет по графику. Дополнительные действия отвлекают от продуктивной работы и задерживают сдачу проекта по сравнению с точной оценкой и-планированием.
Сравнивая аргументы
«Студенческий синдром» Голдрэтта может оказывать влияние на программные проекты, но я обнаружил, что самым эффективным способом его устранения является активное отслеживание задач и буферное управление (то есть управление проектом), по аналогии с предложениями Голдрэтта, а не смещение оценок.
Как видно из рис. 3.1, лучшие результаты проекта достигаются при самых точных оценках (Саймонс 1991). Если оценка занижена, неэффективность планирования ведет к повышению затрат и затягиванию проекта. Если оценка завышена, начинает действовать закон Паркинсона.
