У повара есть ещё одна возможность: добавить жару. В результате омлет часто оказывается безнадёжно испорченным: горелым с одного края и сырым — с другого.
Я не думаю, что у менеджеров программных продуктов меньше храбрости или твёрдости, чем у поваров или других менеджеров в инженерных областях. Но липовые графики, нацеленные на желательную хозяину дату, встречаются здесь значительно чаще, чем в любых других инженерных областях. Очень тяжело, рискуя потерять рабочее место, с энергией и любезностью отстаивать срок, который определён без применения каких-либо количественных методов при недостатке данных и подкреплён, в основном, интуицией менеджера.
Очевидно, необходимо сделать две вещи. Мы должны получить и сделать общедоступными численные данные, характеризующие производительность, частоту программных ошибок, методы оценки и т.д. Вся отрасль может только выиграть от опубликования таких данных.
Пока методы оценивания не получат более прочной основы, менеджерам остаётся только мужаться и защищать свои прогнозы, утверждая, что полагаться на их слабую интуицию все же лучше, чем основываться на одних желаниях.
Действия при срыве графика
Что делают, когда важный программный проект начинает отставать от графика? Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда помогает.
Рассмотрим пример. [4] Предположим, что трудоёмкость задачи оценивается в 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 человеко-месяца будут потрачены на работу, которая не учитывается в исходной оценке . Кроме того, задача, разбитая первоначально на три потока, должна быть теперь перекроена на пять частей.