Как сократить расписание ИТ-проекта: fast tracking vs crashing
«Проект отстаёт на две недели. Что делать?»
Проект отстаёт, заказчик требует закончить в срок, денег на дополнительные ресурсы нет, команда уже работает с перегрузкой. Что делать? В управлении проектами есть два основных метода сжатия расписания: fast tracking и crashing. Один — бесплатный, но рискованный. Другой — дорогой, но предсказуемый.
Fast tracking — бесплатно, но рискованно
Fast tracking — это выполнение задач параллельно, которые изначально планировались последовательно. Пример: вместо последовательности «проектирование (2 недели) → разработка (4 недели) → тестирование (2 недели)» вы начинаете разработку через 1,5 недели проектирования, а тестирование — через 3 недели разработки. Суммарно вместо 8 недель — 6,5.
Главный риск: если проектирование было неполным, разработка пойдёт не туда, придётся переделывать. Когда применять: когда бюджет ограничен, но есть возможность перепланировки.
Crashing — дорого, но предсказуемо
Crashing — это добавление ресурсов на задачи критического пути: дополнительные разработчики, сверхурочные, более производительное оборудование. Пример: на задачу по интеграции с 1С ставят двух разработчиков вместо одного, длительность сокращается с 5 до 3 дней.
Главный риск: закон Брукса — добавление людей на опаздывающий проект ещё больше его замедляет, новых людей нужно вводить в контекст, обучать. Второй разработчик может дать ускорение 30%, а третий — только 10%. Когда применять: когда fast tracking уже использован, но нужен ещё больший эффект, и когда есть бюджет.
Что важно помнить
Оба метода применяются только к задачам на критическом пути. Если вы ускорите задачу с резервом (не на критическом пути) — проект не сдвинется. Порядок действий: найдите критический путь (Критический путь в ИТ-проекте) → попробуйте fast tracking → если не хватило — crashing → пересчитайте критический путь.
Когда ни один метод не работает
Иногда проект нельзя ускорить. Тогда остаётся только одно: сокращать содержание — убирать фичи, переносить на следующий релиз, упрощать требования. Это третий, самый радикальный метод, но он меняет не расписание, а сам проект, и требует согласования с заказчиком.
Что в понедельник утром
Если проект отстаёт — найдите критический путь. Проверьте, можно ли выполнять задачи параллельно (fast tracking). Если да — перепланируйте. Если нет — оцените, сколько ресурсов нужно добавить (crashing). Если ни то, ни другое не работает — идите к заказчику сокращать содержание.
Заключение
Fast tracking — бесплатно, но рискованно. Crashing — дорого, но предсказуемо. Применяйте к критическому пути: fast tracking — сначала, crashing — если не хватило.
Хотите научиться сжимать расписание на реальных кейсах? В модуле 4 курса «Мастер управления IT-проектами» мы на воркшопах выбираем стратегию ускорения для ваших проектов. Подробнее о курсе →