Эдвард Йордон - Путь камикадзе [Смертельный марш]

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

36) Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?

37) Располагаете ли вы утверждённым планом и бюджетом?

38) Знаете ли вы, за разработку какого ПО несёте ответственность?

39) Можете ли вы перечислить первые десять проектных рисков?

40) Известен ли вам процент сжатия вашего плана по сравнению с нормальным?

41) Каков оценочный объём вашего ПО? Каким образом он вычисляется?

42) Известна ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?

43) Достаточными ли знаниями о предметной области располагают ваши специалисты?

Как было отмечено выше, «тест на алкоголь» проводится в том случае, когда кто-либо в организации – как правило, не менеджер проекта, а кто-либо, стоящий на существенно более высоком уровне иерархии – почувствует, что проект идёт не так, как надо. Для того, чтобы выжить в политических схватках, менеджеру проекта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта вообще все время следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если в соответствии с официальным графиком PERT все выглядит как положено. Такими признаками могут быть:

44) Уход ключевых участников команды – это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участники проекта веру в свою способность завершить проект. Если начнут уходить ключевые разработчики, другие могут последовать за ними.

45) «Фактор обратной корреляции Дильберта» – чем больше карикатур Дильберта появляется на дверях в офисе и на досках объявлений, тем хуже идут дела в проекте.

46) Чрезмерный юмор висельников – если проектная команда начнёт носить в офисе чёрные рубашки и проигрывать на аудиосистеме погребальные мелодии, значит, что-то идёт не так.

47) Проекту даются новые имена, например, «Проект Титаник» – другая разновидность юмора висельников, которая, однако, является более серьёзным признаком того, что проектная команда утратила веру в успех, чувство причастности к проекту и вообще какой-либо интерес к работе.

48) Зловещее молчание конечных пользователей и высшего руководства, которые обычно каждый день интересовались ходом проекта – к тому моменту, когда вы это осознаете, может оказаться слишком поздно, чтобы наверстать упущенное, однако у вас может быть по крайней мере несколько дней, чтобы обновить своё резюме.

49) Бестолковая суета – бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи «мини-этапов» и стратегии «ежедневной сборки проекта».

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

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

Разумеется, реалии таковы, что приступить к ежедневной сборке проекта с самого первого дня невозможно. Правда, уже на второй день проекта можно написать подпрограмму типа «Hello, World», и трудно сегодня удивить кого-то совершенно новыми технологиями (в частности, многие из проектов, использующих Java, во время написания этой книги уже находились в процессе разработки). Однако, существуют определённые требования, которым должна удовлетворять версия прототипа системы при первой «официальной» демонстрации: помимо того, что она включает необходимую совокупность компонентов, процедур или модулей и, по крайней мере, несколько сотен, а может быть и тысяч строк кода, она должна выполнять реальный ввод данных, производить реальную обработку или вычисления и формировать реальный выход. Именно с этого момента следует начинать ежедневную сборку проекта и формировать каждый день новую (желательно улучшенную) версию системы.

Почему это так важно? Как любит говорить Jim McCarthy, менеджер продукта Microsoft Visual C++ и автор книги Dynamics of Software Development [4]:

«Ежедневная сборка – это биение сердца проекта. Она даёт знать, что жизнь продолжается». Такая стратегия может быть приоритетом номер один для менеджера проекта. Если в течение недели каждый крутит свою прялку, и никто не соберётся с духом, чтобы сообщить менеджеру проекта, что разрабатываемое ими клиент-серверное приложение никак не хочет правильно взаимодействовать с новой замечательной объектно-ориентированной базой данных, то в результате проект может безнадёжно отстать от графика. До тех пор, пока менеджер судит о состоянии проекта по устным отчётам, запискам или диаграммам потоков данных, будет слишком легко перепутать движение с прогрессом и усилия с результатами. Однако, если менеджер проекта настаивает на ежедневной физической демонстрации результатов, будет гораздо труднее скрыть какие-либо трудности, которые в конечном счёте могут способствовать провалу проекта.

Некоторые менеджеры проекта будут кивать головами и подтверждать, что они всегда именно так и поступают, однако большинство согласится, что они довольствуются еженедельным, ежемесячным или полугодовым контролем реализации системы. В то время как вряд ли кто-нибудь вправе претендовать на «изобретение» данного подхода, многие знают, что он впервые стал популярным во время разработки операционной системы Windows NT (интересную дискуссию на эту тему можно обнаружить в описании данного проекта, приведённом в [5]). Любопытно также отметить, что при разработке Windows 95 также использовался принцип ежедневной сборки проекта; заключительная бета-версия перед выпуском конечного продукта была реализована в августе 1995 года и называлась «Проект 951».