Скотт Беркун - Искусство управления IT-проектами

Рис. 14.5.Миттельшпиль не закончится до тех пор, пока не будут завершены все запланированные работы. Эндшпиль начнется только после их завершения. Приоритет всего, что не является показателем хода завершения работ, должен быть ниже

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

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

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

Постоянная смена направлений, в которых движется проект, стала одним из самых сильных аргументов в пользу коротких циклов и других элементов экстремального программирования (Extreme Programming, XP). Использование коротких циклов разработки позволяет проекту реагировать на существенные изменения направлений без потери предыдущих наработок, а все усилия по планированию и проектированию могли быть сосредоточены на вполне осязаемом коротком отрезке времени. Все это, по-моему, имеет глубокий смысл, поскольку дает возможность нацелиться на достижение череды краткосрочных побед. Но есть еще одна истина, о которой следует помнить: долгосрочные планы, даже самые приблизительные, облегчают внесение краткосрочных и среднесрочных изменений.

Смысл в том, что в момент изменения целей, требований или замысла, первоначальный план редко отбрасывается полностью. А все изменения делаются в соответствии с некоторой основной идеей, которой проект соответствовал до этого. Чем тщательнее разработан первоначальный план, пусть даже он носил весьма приблизительный характер, тем больше можно на него ориентироваться и тем быстрее могут быть внесены соответствующие поправки. Из этого следует, что с самого начала лучшей гарантией против непостоянства, связанного с изменениями, послужит вполне реальный план, поправки в который можно будет вносить уже в ходе реализации проекта. Вот что думает по этому поводу генерал-майор Дэн Лэйнер (Dan Laner), командующий израильскими силами обороны:

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

Особенность использования планов в условиях ожидаемого смещения целей состоит в том, чтобы не допускать слишком долгой работы без обновления плана. Если подобрать подходящие интервалы, смещение целей реально не отражается сразу на всем: просто наблюдается направление их движения с конкретной скоростью за определенное время. Если в проекте намечено несколько контрольных точек, или этапов (см. главу 2), они станут естественными интервалами для внесения поправок (а если на каждом этапе запланировано время на проектирование, то вы сможете вернуться к первому этапу, в который нужно внести поправки). Даже внутри трех– или шестинедельных этапов вы сможете отыскать одну-две промежуточные точки для вычисления новой траектории движения проекта относительно любых возможных изменений целей или требований. Поэтому продолжительность этапов должна соответствовать степени изменчивости проекта: чем чаще меняется его направление, тем короче должен быть этап.