Читать книгу "Искусство управления IT-проектами - Скотт Беркун"
Шрифт:
Интервал:
Закладка:
• Проводит ли кто-нибудь ежедневный или еженедельный анализ выполнения календарного плана в целом? Обладает ли этот человек достаточными полномочиями, чтобы задавать резонные вопросы и вносить поправки?
• Чувствует ли команда причастность к календарному плану и ответственность за его выполнение? Если нет, то почему? Внесла ли команда свой вклад в составление календарного плана и в определение объема работ или все это было спущено им сверху?
• Чего больше было в действиях руководства командой, добавления требований по характеристикам продукта или помощи в их исключении? Говорили ли когда-нибудь руководители команды решительное нет новым объемам работ и предоставляли ли они своей команде разумную философию реагирования на новые (запоздавшие) требования?
• Находили ли сотрудники поощрение и поддержку, если говорили нет новым требованиям, если те шли вразрез с их целями и представлениями?
• Какая вероятность была заложена в расчеты? 90 %? 70 %? 50 %? Нашла ли она отражение в главном календарном плане высокого уровня? Был ли клиент, вице-президент или заказчик уведомлен об этом? Обсуждалось ли другое предложение, более затратное по времени, но имеющее более высокую вероятность соблюдения сроков?
• Имели ли место периодические согласования и пересмотры календарного плана со стороны руководителей команд и руководителей проекта?
• Учтено ли в календарном плане сокращенное рабочее время в период праздников. (Обычно череда праздников снижает продуктивность работы.) Учтены ли в плане наиболее вероятные разрушительные погодные явления (например, снежные заносы в Чикаго, торнадо в Канзасе или жара в Сиетле)?
• Был ли достаточно качественным уровень разработки технических требований и проектирования для получения качественных расчетов времени, отводимого на работы?
• Была ли у расчетчиков достаточная практика или опыт в производстве расчетов времени, отводимого на работы?
Даже при правильной реакции на большинство вопросов предыдущего списка вы, к великому сожалению, не гарантированы от провала, поскольку слишком велика степень взаимозависимости всех усилий, прикладываемых к составлению календарного плана. Все принимаемые командой решения, от выбора замысла до оценок, являются основой многих будущих решений. Чем позднее обнаруживается просчет, допущенный на начальной стадии проекта, тем выше степень его влияния на реализацию проекта. Сложность процесса реализации календарных планов легко недооценить, поскольку причинно-следственная связь зачастую не просматривается (последствия становятся заметными только в случае проявления их причин). В худших вариантах, при обнаружении нескольких крупных упущений, шансы на то, что план не рассыплется, стремятся к нулю (рис. 2.4).
На самом деле все еще хуже. Вероятность наступления ряда независимых событий равна произведению вероятностей наступления каждого отдельного события (так называемая совместная вероятность). Отсюда следует, что если вероятность прочтения вами этой главы до конца равняется девяти шансам из десяти (9/10), а вероятность того, что вы осилите и следующую главу, также равна 9/10, то суммарная вероятность, что вы дочитаете до конца обе главы, равняется уже не 9/10, а 81/100. Это означает, что если у вашей команды 90-процентная вероятность точного следования еженедельному графику работ, с течением времени шансы срыва сроков возрастают. Вероятность – вещь холодная и беспощадная, напоминающая нам, что энтропия существует повсеместно и не благосклонна ни к проектам, ни к их руководителям.
Рис. 2.4. Эффект снежного кома
Теперь, когда стало понятно, почему так трудно придерживаться календарных планов, я хочу дать совет, как снизить риски и увеличить полезную отдачу от любого календарного плана. Предлагаемые подходы и поступки идут вразрез с традиционными устоями или привычками, в чем, я думаю, и кроется реальная природа планирования. Поскольку календарный план охватывает весь проект, единственный способ его эффективного использования состоит в том, чтобы приобрести какие-то понятия о природе всего, что требуется для успешной реализации проекта. Это многоплановая задача, относящаяся не только к разработке и управлению.
Выбирайте продолжительность этапов в соответствии со степенью изменчивости проекта. Чем больше ожидаемых изменений, тем короче должны быть этапы. Небольшие этапы настраивают команду на менее болезненные поправки в ходе реализации проекта. Управленцы получают более короткие контролируемые интервалы, что сокращает риски внесения изменений. Команда должна быть готова к поправкам на стыке этапов, чтобы все ожидали перемен, а не противились им.
Будьте оптимистом во взглядах и скептиком в планировании. Главное психологическое испытание в планировании – придерживаться надлежащей степени скептицизма, без подавления энтузиазма и устремлений команды. В отличие от принципов создания концептуального документа, в котором должен преобладать оптимистический взгляд на будущее, календарный план должен исходить из противоположных перспектив. Числа, положенные в расчеты продолжительности работ, без каких бы то ни было поблажек должны соответствовать закону Мэрфи («все, что может пойти не так, пойдет не так»). В планах не должно отражаться то, что может произойти при оптимальных условиях. Вместо этого в хорошем плане отображается то, что должно случиться, несмотря на то что несколько существенных положений не оправдали своих ожиданий. Важно привлечь к планированию команду тестировщиков и контролеров качества, поскольку они внесут в разработку свойственный им скептицизм и критический взгляд на вещи.
Делайте ставку на проектирование. В процессе проектирования закладываются лучшие гарантии от неизвестных и неожиданных осложнений. Качественное проектирование – это единственный способ сделать более гладким преодоление командой фазы разработки и других фаз реализации проекта. Навыки проектирования отличаются от навыков разработки, поэтому самый сильный или самый продуктивный специалист по составлению программного кода не обязательно будет лучшим проектировщиком или специалистом по решению проблем. Качественному проектированию не учат на курсах информатики, несмотря на всю его важность в поиске путей и решений по разработке и управлению проектами. Эта тематика подробнее рассматривается в главах 5 и 6.
Планируйте контрольные точки для обсуждения исключений и добавлений. В календарные планы должны включаться короткие периоды для его пересмотра, позволяющие руководству критически оценить текущий процесс и учесть новую информацию и отзывы заказчика. Все это должно быть включено в главный календарный план и стать частью любого контракта на разработку проекта. В процессе пересмотра существующие работы могут урезаться или к ним могут добавляться новые, если это будет продиктовано результатами анализа текущей обстановки, проведенного руководством. Естественным временем для таких пересмотров являются промежутки между фазами или, в сокращенном варианте, моменты окончания каждой фазы проектирования или разработки, но они могут проводиться и в любое другое время, если возникнут серьезные опасения или явные расхождения между планом и реальным положением дел. Целью подобных пересмотров должно стать оздоровление проекта, освежение плана, уточнение приоритетов и инициирование следующего этапа выполнения календарного плана при ясном видении обстановки и с верой в будущее (см. главы 14 и 15).
Внимание!
Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Искусство управления IT-проектами - Скотт Беркун», после закрытия браузера.