Влияние политических факторов на оценки

Реакция руководства на оценки программных проектов зависит от ряда факторов, не относящихся к технической стороне дела.

Внешние ограничения

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

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

СОВЕТ № 111

Учитывайте воздействие внешних факторов. Ваши собеседники должны видеть, что вы понимаете коммерческие требования и их важность.

Бюджет и даты

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

Переговоры по поводу оценок и обязательств

В одних обстоятельствах переговоры уместны, в других — нет.

Технический руководитель: По нашей оценкеу проект займет от 5 до 7 месяцев. Впрочем, сейчас мы еще находимся в ранней части конуса неопределенности, поэтому оценка будет уточняться в ходе работы.

Администратор: От 5 до 7месяцев — слишком большой разброс. Нельзя ли просто использовать оценку в 5 месяцев?

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

Администратор: Ничего не понял. А в чем разница?

Технический руководитель: Наш диапазон от 5 до 7 месяцев включает одно стандартное отклонение в каждую сторону от медианной оценки в 6 месяца. Это означает, что вероятность завершения за 7 месяцев равна 84 %. Наши оценки показывают, что вероятность соблюдения 5-месячных обязательств составляет всего 16 %.

Администратор: Нам нужна более чем 50 % уверенность в сроке, по которому заключаются обязательства, но 84 % — более консервативная оценка, чем нужно. Какой срок можно считать достоверным на 75 % ?

Технический руководитель: Согласно нашим вычислениям, около 6,5 месяца.

Администратор: На нем и остановимся.

Технический руководитель: Договорились.

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

СОВЕТ № 112               :

Обсуждайте обязательства, но не оценки.

Что делать, если ваша оценка не принята

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

Ответственность технического персонала за обучение

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

Расскажите ответственным участникам, не связанным с технической стороной проекта, о принципах эффективной оценки программных проектов.

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