Ускорили главное — срок не сдвинулся
Запуск сервиса самообслуживания на первой точке. Самая тяжёлая работа проекта — бэкенд: десять рабочих дней, треть всей разработки, главный предмет разговоров на статусах. Руководитель проекта делает очевидное: добавляет людей и сжимает бэкенд с десяти дней до шести.
Проект как занимал 29 рабочих дней, так и занимает 29. Выигрыш — ноль.
Причина не в исполнении и не в оценке. Срок проекта держат другие работы: двухдневный заказ оборудования, пятнадцать дней ожидания поставки, монтаж, тестирование, пилот. На этой цепочке никто не программирует — половину времени вообще никто ничего не делает. А бэкенд, сколько его ни ускоряй, упирается в дату, которую задаёт не он.
Цепочка, которая задаёт срок, называется критическим путём. Метод её расчёта опубликован в 1959 году и с тех пор не изменился: два прохода по сети арифметикой уровня сложения. Сложность не в расчёте — в том, чтобы поверить его результату, когда он противоречит ощущению важности.
- Связывать работы четырьмя типами связей и понимать, зачем в расписании нужен лаг и чем он опасен
- Считать ранние и поздние даты, полный и свободный резерв — руками, на бумаге, без программы
- Отвечать на вопрос «если ускорим вот это, на сколько сдвинется срок» числом, а не ощущением
- Выбирать между сжатием ресурсами и распараллеливанием, зная цену каждого
- Видеть шесть мест, где расчёт критического пути врёт, и что делать в каждом
Нет декомпозиции. Работы уже выделены — мы берём их как вход и связываем. Как разобрать содержание проекта на элементы, разбирает лекция «Декомпозиция работ: WBS».
Нет оценки длительности. Ни трёхточечной, ни любой другой формулы. Все длительности здесь — готовые входные числа. Как их получают — отдельный разговор.
Нет вероятностного анализа. Ни симуляции, ни доверительных уровней. Сталкивание путей мы разберём как структурное свойство сети — умножением двух вероятностей, которые дал стандарт. Реестр рисков, резерв под риск и моделирование — лекция «Риски проекта».
Нет освоенного объёма. Ни одного индекса исполнения. Деньги появятся ровно один раз: как стоимость сокращения работы. Бюджет и его контроль — лекция «Бюджет проекта».
Нет процесса согласования изменений. Изменение у нас появляется одним фактом: перед пересчётом расписание архивируют.
Примеры взяты из разных проектов: разработка, стройка, маркетинговый запуск, внедрение внутренней системы, контракт по 44-ФЗ. Сквозной числовой пример один на всю лекцию — тот самый запуск сервиса на 29 дней. Все его числа посчитаны прямым и обратным проходом и сходятся вручную.
Список задач с датами — ещё не расписание
В большинстве проектов расписание выглядит как таблица: работа, начало, окончание, ответственный. Такую таблицу можно составить за час, и она даже будет выглядеть убедительно. Проверить её нельзя ничем: даты в ней проставлены, но не выведены.
Разница проявляется в момент первого сдвига. Подрядчик сообщает, что монтаж сдвигается на три дня. В таблице вы правите две ячейки — и не знаете, поехал ли срок проекта. В сети вы пересчитываете и получаете ответ числом.
Норма требует связей, а метод оставляет вам
ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» действует с 01.09.2012 (введён приказом Росстандарта от 22.12.2011 № 1582-ст). Расписание он определяет коротко — п. 3.15: «расписание проекта (календарный план): Плановые даты исполнения работ и контрольных событий проекта».
А вот перечень обязательных выходов процесса разработки расписания (п. 5.3.2) устроен интереснее. Первым в нём идёт не то, что обычно показывают заказчику:
- определены взаимосвязи между работами проекта
- проведена оценка длительности работ проекта
- определён и утверждён график привлечения ресурсов, необходимых для выполнения проекта в срок
- определено и документировано расписание проекта
- утверждён базовый календарный план проекта
Слов «критический», «сетевой» и «резерв» в тексте ГОСТ Р 54869-2011 нет ни одного. Стандарт нормирует обязательные выходы процессов, а не способы их получения — в области применения это сказано прямо.
Читается это так: взаимосвязи между работами вы обязаны определить, а чем их считать — норма оставляет вам. Метод критического пути и есть самый дешёвый способ выполнить первый пункт так, чтобы четвёртый получился выводом, а не выдумкой.
Действующий ГОСТ Р ИСО 21502-2024 (приказ Росстандарта от 02.11.2024 № 1599-ст, идентичен ISO 21502:2020) применяется с 01.01.2025 — упоминаем как факт, цитировать его пункты здесь не будем. Отдельно стоит знать, что ГОСТ Р ИСО 21500-2014 недействующий: ссылка на него в документах проекта — ссылка на отменённый стандарт.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.