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

• любой процесс продлится дольше, чем вы надеетесь;

• всегда появляется что-то, о чем вы не подумали.

Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния проекта», старайтесь контролировать разрастание и обязательно убедите ваших подчиненных в том, что вы человек проницательный, поскольку предсказывали такую возможность и учли ее в процессе тщательного планирования. «Тщательное планирование»! Звучит замечательно, но что же это означает в контексте выпаса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложенным в них принципам и попытайтесь сделать их неотъемлемыми элементами своего характера. Помните, что лидерство происходит от сердца, а не от ума[36].

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

Таблица 3.3. Нереалистичный план проекта

Руководствуясь таким планом, вы рискуете нарваться на кучу неприятностей. Будучи глубоко убеждены, что конечная дата сдачи проекта будет равняться сумме временных интервалов A + B + C + D + E + F, вы немало удивитесь, обнаружив, что это совершенно не так.

Рассмотрим более реалистичный план, показанный в табл. 3.4.

Таблица 3.4. Реалистичный план проекта

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

Каков механизм совершенствования навыков временной оценки? Он очень прост – поначалу вам предстоит неоднократно нарушать утвержденные графики сдачи проектов, но, в конце концов, вы научитесь им соответствовать. Практика эта довольно нервозная и даже угрожающая вашему карьерному росту. Возможно, это не лучший способ самосовершенствования, но что можно утверждать со всей определенностью, так это то, что в области управления проектом опыт играет огромную роль. А чтобы ускорить обучение, почитывайте анекдоты, относящиеся к руководству проектами. В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласс (Robert Glass) составил список наиболее распространенных «программных катастроф», который я привожу в порядке снижения значимости