Наверняка вы слышали термин гибкий или подвижный по отношению к расписанию проекта или его задачам. И тот и другой термин используется для оценки количества времени и действий, которые могут задерживаться без задержки всего проекта. Используя эту информацию, мы знаем, что «Разработать спецификации программного обеспечения» — это не критический путь.
И все же, если задачи задерживаются достаточно долго, другие задачи или этот путь будет задержан и они могут случайно (если будут задержаны достаточно долго) повлиять на критический путь. Действительно, если любая задача в проекте задерживается достаточно долго, она может поставить под угрозу весь проект (если это не так, то можно задать вопрос — а должна ли эта задача выполняться вообще).
Вот другой пример: предположим, что пользователи должны быть подготовлены для использования новых возможностей корпоративных приложений, которые будут модернизированы. Пользователи уже знакомы с продуктом, им просто требуется короткая — в четыре часа — программа подготовки для того, чтобы быстрее освоить новые возможности. Эта подготовка, гипотетически, может происходить в любой момент перед началом эксплуатации продукта и не задерживает выполнение проекта. Конечно, есть несколько оптимальных режимов времени в этом случае, но подготовка должна обладать определенной подвижностью или гибкостью. Например, ее можно назначить за месяц до начала эксплуатации продукта, но у этого срока есть «зазор» в две недели, что означает, что она может пройти на две недели позднее и тем не менее никоим образом не задерживать проект.
Это дает вам определенную гибкость при задержке обучения или же в случае болезни педагога. Определение этого «зазора» в ваших задачах очень важно при составлении расписания проекта, поскольку это дает вам возможность перемещать те или иные задачи для решения проблем, которые могут повлиять на расписание всего проекта. Это также позволяет вам знать, где вы можете распоряжаться ресурсами так, чтобы использовать их при возникновении проблем. Некоторые люди указывают наличие «зазора» в задаче на диаграмме (если вы используете компьютерную программу для управления проектом, вы также можете ввести «зазор» или «подвижку» и она будет изображена на сетевой диаграмме), чтобы вы могли визуально наблюдать места, где у вас есть определенная свобода.
Помните, что задачи на критическом пути практически всегда не имеют такого зазора, именно поэтому они и попадают на критический путь. Если у задачи нет зазора, она «наименее гибкая» и практически не может шевелиться. Задачи с «зазором» обычно не лежат на критическом пути по той причине, что они не могут двигаться при возникновении изменений.
Определите все «зазоры» и подвижность задач вашего проекта. Это поможет вам проще принимать решения при возникновении тех или иных перемен. Понимание того, какие задачи имеют «зазор» и какие нет, поможет вам принять оптимальные решения о том, как распределить ресурсы и сделает ваше расписание более эффективным. Поскольку критический путь может измениться, если у слишком большого числа задач будут нулевые «зазоры», убедитесь, что вы знаете, какие задачи могут перемещаться, а какие — никогда.