Под давлением

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

Но нажим идет не только сверху. Его оказывает личная гордость про% граммиста. Технари любят давать оптимистические обещания; мы за% интересованные люди и гордимся тем, что создаем, и сроками, в кото% рые это делаем. Соблазнительно думать: «Ну, это не займет много вре% мени!». Но есть существенная разница между быстрым наброском ко% да или прототипом и законченным, готовым к выпуску продуктом. Наши графики должны основываться на реальности, а не на идеаль% ных пожеланиях.

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

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

В идеале срок окончания проекта устанавливается после проверки технической осуществимости, которая устанавливает, что проект осу% ществим за приемлемые сроки. Но на практике так бывает редко. Вме% сто этого вам назначают срок («поставка к Рождеству»), и вы должны думать, как в него уложиться. Если объем работы не позволяет уло% житься в срок, нужно обсуждать пути решения задачи: убрать какие% то функции, привлечь дополнительных разработчиков, отдать часть работы на сторону или договориться о том, что реализация части функций откладывается до будущей версии. Иногда такое планирова% ние превращается в занятие маркетингом и требует немалой изобрета% тельности!

А кто сказал, что это просто?

Рассказ бывалого человека

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

Но ни у кого не хватило времени (или ума), чтобы посоветовать% ся с техническими специалистами и убедиться в том, что проект технически осуществим. Он не был технически осуществим. Ме% неджеры пришли в состояние паники, но ввиду невозможности изменить срок или объем функций им было трудно найти выход. Инженеры выражали недовольство и размахивали своими пла% нами, но им было сказано: постарайтесь уложиться. Они напря% женно работали день за днем и вечером допоздна и вскоре выби% лись из сил. С каждой неделей они все больше отставали от без% надежно нереального графика.

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

Проект провалился, программисты выдохлись, нервы перена% пряглись, клиент остался недоволен. Вскоре после начала ново% го проекта большинство программистов ушло.

Практические способы оценки

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

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

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

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

Не нужно рассчитывать полное время (путем учета отвлечений на дру% гие проекты, чтения почты, серфинга в сети, перерывов на кофе и от% правления естественных надобностей). Оно обязательно будет сильно отличаться от фактически потраченного на решение задачи. Задача может выполняться параллельно с другими или прерываться, чтобы обеспечить выполнение другого проекта. Мы учтем это в плане проек% та (см. раздел «Игры с планами» на стр. 517).

Насколько консервативной должна быть оценка? К чему следует скло% няться – к оптимизму или пессимизму? Правильный ответ: оценка должна быть реалистичной. Готовьтесь к возможным проблемам и учи% тывайте их, но не нужно придумывать 1000 причин, по которым про% стая задача может затянуться, и делать из них предлог для завышения оценки. Не завышайте оценки ради перестраховки или возможности полодырничать, раскладывая пасьянс. Оценки отдельных задач не должны учитывать все возможные неполадки. Управление риском нужно проводить на уровне проекта; планировщик составит на осно% вании наших оценок разумный план с резервом на случай непредви% денных обстоятельств.

Чтобы сделать оценки более точными, учтите следующие важные об% стоятельства:

•Чем более конкретным и определенным является проект, тем про% ще делать оценки. Вам дали хорошую спецификацию?

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

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

•Чем больше функций затребовано, тем труднее сделать оценку. По% старайтесь отказаться от всей ненужной работы. Отличный метод – поэтапная поставка продукта и оценка времени для каждого этапа.

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

1Конечно, для этого потребуется время, которое вы не учли в плане!

1Джеймс Шуровьески «Мудрость толпы». – Пер. с англ. – Вильямс, 2007.