Нарастающие катастрофы с графиком

Что нужно предпринять, когда важный программистский проект не укладывается в график? Естественно, добавить рабочей силы. Как видно на рисунках (2.1— 2.4), иногда это помогает, а иногда — нет.

Давайте рассмотрим пример³). Допустим, что трудоемкость задачи оценена в 12 человеко-месяцев и троим сотрудникам отвели на нее 4 месяца, причем установили количественные вехи А, В, С и D, которых в соответствии с графиком нужно достичь в конце каждого месяца (рис. 2.5).

Допустим теперь, что первая отмотка достигнута только через два месяца (рис. 2.6). Перед какими альтернативами оказался руководитель?

1. Допустим, что задачу нужно сделать вовремя. Допустим также, что неверно оценено только время выполнения первой части (см. рис. 2.6). Тогда остается 9 человеко-месяцев усилий и два месяца времени, т. е. задача требует 4,5 человека. Добавим двоих людей к трем первоначальным.

2. Допустим, что .задачу нужно сделать вовремя. Допустим также, что время выполнения было занижено, а реальное положение дел представлено на рис. 2.7. Тогда остается 18 человеко-месяцев работы и два месяца времени, т. е. понадобится 9 человек. Добавим шестерых к трем первоначальным работникам.

3. Составление нового графика. Мне нравится девиз П. Фагга, опытного инженера, специалиста по вычислительной технике: «Не исправляйте понемногу». Другими словами, делайте новый график достаточно свободным, чтобы работу можно было сделать тщательно и основательно без последующего перепланирования. -

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

В двух первых случаях настаивать на том, чтобы задача бело всяких изменений была закончена за четыре месяца, по меньшей мере ошибочно. Рассмотрим, например, какие помехи возникают в первом случае (рис. 2.8).

Для того, чтобы ввести в курс дела двух новых людей, пусть даже вполне компетентных и опытных, нужен один старый работник. Если. ему на это потребуется месяц, то 3 человеко-месяца будут отданы работе, никак не учитывающейся первоначальными планами. Кроме того, задачу, ранее поделенную на три части, теперь придется поделить на пять частей, следовательно, часть уже проделанной работы пропадет, а комплексная отладка значительно удлинится. Значит, к концу третьего месяца останется больше 7 человеко-месяцев работы, 5 обученных людей и месяц времени. Как видно из рис. 2.8, сроки выполнения задания не сократились, несмотря па появление новых людей (см. рис. 2.6).

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

Заметим, что к концу третьего месяца дела обстоят очень плохо. Отметка «I марта» все еще не достигнута, несмотря на усилия руководителя. Очень велик соблазн повторить весь цикл и привлечь дополнительных работников. Но это безумный путь.

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

Крайне упрощая, мы сформулируем закон Брукса:

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

Таким образом, мы развеиваем миф о человеко-месяце. Число месяцев, отводимых на проект, зависит от ограничений на его линейность. Максимальное число людей зависит от числа независимых подзадач. Исходя из г»тпх двух величрга, можно построить график, рассчитанный на меньшее число людей и большее количество месяцев. (Единственная опасность заключается в том, что конечный продукт устареет.) Нельзя, однако, составить работоспособный график, используя больше людей и меньше месяцев. В большинстве программистских проектов дела шли скверно скорее всего из-за нехватки календарного времени, нежели по всем другим причинам, вместе взятым.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: