Книга: Искусство управления IT-проектами

Что должно произойти, чтобы календарные планы заработали

Что должно произойти, чтобы календарные планы заработали

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

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

 Будьте оптимистом во взглядах и скептиком в планировании. Главное психологическое испытание в планировании – придерживаться надлежащей степени скептицизма, без подавления энтузиазма и устремлений команды. В отличие от принципов создания концептуального документа, в котором должен преобладать оптимистический взгляд на будущее, календарный план должен исходить из противоположных перспектив. Числа, положенные в расчеты продолжительности работ, без каких бы то ни было поблажек должны соответствовать закону Мэрфи («все, что может пойти не так, пойдет не так»). В планах не должно отражаться то, что может произойти при оптимальных условиях. Вместо этого в хорошем плане отображается то, что должно случиться, несмотря на то что несколько существенных положений не оправдали своих ожиданий. Важно привлечь к планированию команду тестировщиков и контролеров качества, поскольку они внесут в разработку свойственный им скептицизм и критический взгляд на вещи.

 Делайте ставку на проектирование. В процессе проектирования закладываются лучшие гарантии от неизвестных и неожиданных осложнений. Качественное проектирование – это единственный способ сделать более гладким преодоление командой фазы разработки и других фаз реализации проекта. Навыки проектирования отличаются от навыков разработки, поэтому самый сильный или самый продуктивный специалист по составлению программного кода не обязательно будет лучшим проектировщиком или специалистом по решению проблем. Качественному проектированию не учат на курсах информатики, несмотря на всю его важность в поиске путей и решений по разработке и управлению проектами. Эта тематика подробнее рассматривается в главах 5 и 6.

 Планируйте контрольные точки для обсуждения исключений и добавлений. В календарные планы должны включаться короткие периоды для его пересмотра, позволяющие руководству критически оценить текущий процесс и учесть новую информацию и отзывы заказчика. Все это должно быть включено в главный календарный план и стать частью любого контракта на разработку проекта. В процессе пересмотра существующие работы могут урезаться или к ним могут добавляться новые, если это будет продиктовано результатами анализа текущей обстановки, проведенного руководством. Естественным временем для таких пересмотров являются промежутки между фазами или, в сокращенном варианте, моменты окончания каждой фазы проектирования или разработки, но они могут проводиться и в любое другое время, если возникнут серьезные опасения или явные расхождения между планом и реальным положением дел. Целью подобных пересмотров должно стать оздоровление проекта, освежение плана, уточнение приоритетов и инициирование следующего этапа выполнения календарного плана при ясном видении обстановки и с верой в будущее (см. главы 14 и 15).

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

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

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

 Беритесь за риски как можно раньше. Если известно, что Салли поручена наиболее сложная работа, учтите это в самом начале календарного плана. Чем выше риск, тем больше времени нужно зарезервировать для того, чтобы с ним справиться. Если вы откладываете учет рисков в календарном плане на более поздний срок, у вас останется меньше степеней свободы, чтобы справиться с этими рисками. То же самое относится к политическим, организационным или ресурсозависимым рискам. Мы поговорим об управлении работами при рассмотрении производственного конвейера в главе 14.

Оглавление книги