Мифический человеко-месяц

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

Я не разделяю столь усердно проталкиваемую коммивояжерами идею о "глобальной АСУ", когда руководитель вводит запрос в вычислительную машину, и на экране терминала загорается ответ. Существует множество очень важных причин, по которым таких систем никогда не будет. Одна из причин заключается в том, что только малая часть, примерно 20% времени руководителя уходит на задачи, для решения которых ому нужна информация не из его собственной головы. Остальное время занимают контакты: он слушает, докладывает, учит, приказывает, советует, поощряет. Для той части его работы, которая действительно базируется на внешних данных, жизненно необходимо наличие лишь небольшого количества документов, чтобы были удовлетворены почти все его потребности.

Задача руководителя - разработать план, а затем реализовать его. Но только записанный план остается точным и коммуникабельным. План состоит из документов па темы: что, когда, сколько, где и кто? Это небольшое множество основных документов воплощает в себе большую часть работы руководителя. Если их важная и ответственная роль будет осознана с самого начала, то руководитель сможет подходить к ним как к полезным инструментам, а не как к тягостным обязанностям.

XI. ПЛАН НА ВЫБРОС

"В атом мире нет ничего постояннее непостоянства".

(Свифт)

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

(Ф. Д, Рузвельт)

Опытные установки и увеличение масштабов

Инженеры-химики давно уже знают, что процесс, который идет в лаборатории, нельзя сразу передавать на завод. Необходим промежуточный шаг, опытная установка, для того чтобы проверить этот процесс в больших масштабах и в условиях, приближенных к реальным. Так, например, лабораторный метод опрес^-нения воды следует сначала проверить на опытной установке мощностью 50 тыс. л воды в день, прежде чем использовать его в городской системе опреснения мощностью 10 млн. л в день.

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

Обычно первая система довольно мало пригодна к использованию. Она может быть слишком медленной, слишком большой, неудобной в использовании или обладать всеми этими качествами одновременно. Нет другого выхода, кроме как начать все сначала, строже подойти к проекту и создать новый вариант, в котором эти недостатки будут ликвидированы. Отказ от старого и создание нового проекта можно осуществить в один этап, можно это делать и по частям. Однако весь опыт создания больших систем говорит, что сделать это придется2). Каждый раз, когда используются новые концепции или новая техника, приходится создавать систему "на выброс", поскольку даже лучшие методы планирования но настолько хороши, чтобы сразу "те получалось то, что нужно.

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

Постоянны только изменения

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

Конечно, все это справедливо и в отношении потребностей, удовлетворяемых самыми разными машинами, будь то новые автомобили или новые вычислительные машины. Но само существование реального объекта сдерживает требования пользователей изменить что-либо и квантует их. А податливость программного продукта и его неосязаемость подставляют его создателей под нескончаемый поток изменений в требованиях.

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

Тем нс менее, некоторые изменения в целях и задачах неизбежны, и лучше быть готовым к ним, чем считать, что их не будет. Неизбежны изменения не только в целях, но н в стратегии и методах разработки. Концепция "работы в корзину" сама по себе является принятием того факта, что, научившись чему-то, мы вносим в проект изменения4).

Планирование изменений в системе

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

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

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

Планирование изменений в организации

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

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

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