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

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

Робость в оценках

Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время ее фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения.

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.

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

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

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

Действия при срыве графика

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

Рассмотрим пример.[3] Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения (рис. 2.5).

Рис. 2.5

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

1. Допустим, что необходимо соблюсти срок выполнения задачи, и ошибочно оценена была только первая часть задачи, т.е. рисунок 2.6 верно отражает положение. Значит, остается 9 человеко-месяцев трудозатрат и два месяца, поэтому понадобится 4Ѕ человека, и к троим имеющимся нужно добавить еще двоих.

Рис. 2.6

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

Рис. 2.7

3. Изменить график. Мне нравится замечание, сделанное П. Фаггом (P. Fagg), опытным инженером по вычислительной технике: «Маленьких задержек не бывает». Это означает, что в новом графике должно быть достаточно времени, чтобы работа была исполнена тщательно и полностью, и не пришлось бы вновь переделывать график.

4. Сократить задачу. На практике этим всегда и кончается, когда команда обнаруживает, что не укладывается в график. Когда очень высоки вторичные издержки, это единственное, что можно сделать. Менеджеру предоставляется возможность официально и аккуратно сократить задачу, изменить график, либо наблюдать, как задача молча урезается при поспешном изменении проекта и неполном тестировании.

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

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

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

Рис. 2.8

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

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

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

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