Искусство управления IT-проектами - [19]

Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов

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

Почему рушатся планы

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

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

Выстрел вслепую издалека

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

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

Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов[11] писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.

Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма «Software Engineering Economics»)

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

Календарный план – это оценка вероятности

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

Когда мы обсуждали, в чем состоит разница между этим главным планом и календарным планом, созданным моей командой на основе списка работ,[12] главный план казался нам высосанным из пальца. Он был спущен сверху, аккуратно отформатирован, разбит на красивые столбцы из дат и чисел, но при этом казался чем-то искусственным, украденным из будущего.