существующие работы могут урезаться или к ним могут добавляться новые, если это будет продиктовано результатами анализа текущей обстановки, проведенного руководством. Естественным временем для таких пересмотров являются промежутки между фазами или, в сокращенном варианте, моменты окончания каждой фазы проектирования или разработки, но они могут проводиться и в любое другое время, если возникнут серьезные опасения или явные расхождения между планом и реальным положением дел. Целью подобных пересмотров должно стать оздоровление проекта, освежение плана, уточнение приоритетов и инициирование следующего этапа выполнения календарного плана при ясном видении обстановки и с верой в будущее (см. главы 14 и 15).
Посвящайте команду в философию планирования. Какие бы технологии и подходы к планированию не использовались, их нужно доводить до команды. Если каждый программист и тестировщик сможет в общих чертах разобраться в принципах работы календарных планов и конкретной стратегии управления, применяемой в данном проекте, у него появится возможность задавать продуманные вопросы, понять общий замысел и поверить во все то, что планируется сделать.
Оцените опыт команды в сфере решаемых проблем. Одной из «волшебных» переменных величин в планировании является опытность команды в сфере тех проблем, которые ей предстоит решать. Если команда создает веб-сайт, управляемый базой данных, и пять или шесть программистов ранее уже не раз занимались такого рода работой, есть основания предполагать, что они лучше справятся с проектированием и расчетом графика работ, чем команда, ранее не делавшая ничего подобного. Этот фактор должен стать решающим в определении степени агрессивности или консервативности календарного плана.
Оцените уверенность и опыт команды в совместной работе. Несмотря на то что расчеты выполняют отдельные программисты, созданием чего-нибудь действительно сложного программисты занимаются вместе, как единое целое. Даже команда, составленная из опытных суперзвезд программирования, не достигнет ожидаемой результативности, если входящие в нее программисты ранее никогда вместе не работали (или не сталкивались все вместе со сложными задачами). Нельзя допускать, чтобы только что сформированной команде поручалась работа над сложным и рискованным проектом или предлагался агрессивный календарный план.
Беритесь за риски как можно раньше. Если известно, что Салли поручена наиболее сложная работа, учтите это в самом начале календарного плана. Чем выше риск, тем больше времени нужно зарезервировать для того, чтобы с ним справиться. Если вы откладываете учет рисков в календарном плане на более поздний срок, у вас останется меньше степеней свободы, чтобы справиться с этими рисками. То же самое относится к политическим, организационным или ресурсозависимым рискам. Мы поговорим об управлении работами при рассмотрении производственного конвейера в главе 14.
Выводы
• Календарные