1. Длительность работ указывается в едином формате и целыми значениями
Все задачи проекта рекомендуется описывать длительностью в едином формате - например, только в днях, неделях или часах. Кроме того, длительности должны указываться целыми значениями. Это позволяет избежать неоднозначностей при расчётах и облегчает контроль сроков. Единый формат делает модель более стабильной, предотвращает ошибки округления и снижает риск расхождений между плановыми и фактическими показателями.
Пример из практики:
При создании расписания строительства объекта все проектировочные задачи устанавливаются длительностью 10 дн, 15 дн, 20 дн, а не «13,5 дн» или «1,75 нед».
Это позволяет избежать плавающих вычислений и упрощает контроль зависимости между задачами.
2. Задачи без предшественников связываются с вехой «Начало проекта»
Если задача не имеет входящих связей, её необходимо связать с вехой «Начало проекта». Это обеспечивает корректный запуск всех веток расписания и предотвращает появление «плавающих» задач, которые могут случайно сместиться при изменении других частей плана. Такая связь задаёт логическую точку отсчёта, от которой модель начинает расчёт времени.
Пример из практики:
Задача «Подготовка технического задания» не имеет логических предшественников.
В проекте её связывают зависимостью:
Начало проекта → Подготовка ТЗ (FS).
3. Задачи без последователей связываются с вехой «Проект завершён»
Аналогично предыдущему пункту, задачи, не имеющие выходящих связей, должны быть связаны с завершающей вехой проекта. Это позволяет MS Project корректно вычислять критический путь, определять общую длительность и предотвращать неконтролируемое «зависание» задач, которые могут быть восприняты системой как завершенные слишком рано.
Пример:
Задача «Формирование итогового отчёта» — последняя в цепочке работ.
Даже если на неё нет других зависимостей, она связывается с вехой:
Формирование отчёта → Проект завершён (FS).
4. Все задачи и вехи проекта должны быть связаны
Каждая задача должна быть встроена в логическую цепочку. Исключением являются только две точки - «Начало проекта» и «Проект завершён». Полная связность минимизирует риски логических разрывов в расписании, обеспечивает корректное построение диаграммы Ганта и помогает аналитически определить критический путь.
Пример:
При планировании монтажа оборудования каждая задача является частью цепочки:
- Поставка оборудования → Монтаж
- Монтаж → Пусконаладка
- Пусконаладка → Проверка готовности
Так формируется непрерывный логический поток.
5. Не рекомендуется связывать суммарные задачи
Связи должны устанавливаться между обычными задачами. Суммарные задачи представляют собой агрегированные данные и управляют только отображением структуры. Связывание их может привести к некорректному поведению расписания, циклическим зависимостям и ошибкам расчётов. Логика проекта должна строиться только на уровне атомарных задач.
Пример неправильной практики:
Связать суммарную задачу «Строительно‑монтажные работы» с суммарной «Пусконаладка».
Это вызывает некорректные расчёты и циклы.
Правильный вариант:
Связывать конкретные задачи внутри этих разделов:
Окончание монтажа → Начало пусконаладки (FS).
6. Использование связи «Окончание–Начало» (Finish–Start)
Тип связи «окончание–начало» является основным и наиболее предсказуемым вариантом построения зависимостей. Он формирует чёткую последовательность выполнения работ и обеспечивает стабильность модели. Другие типы связей допускаются только при наличии реального обоснования.
Пример:
«Разработка рабочей документации» (FS) → «Согласование документации»
Согласование может начаться только после завершения разработки, что логично и прозрачно.
7. Не рекомендуется использовать опережение и запаздывание
Использование Lead (опережение) и Lag (задержка) следует сводить к минимуму. Подобные механизмы усложняют анализ критического пути и могут скрывать реальные зависимости. Лучше по возможности заменить их отдельными задачами или явными связями, что делает расписание более прозрачным.
Плохой пример:
Задача «Отделка помещений» начинается с опережением 5 дней от «Монтажа инженерных систем» (FS –5).
Это трудно интерпретировать и объяснить в отчётах.
Хороший пример:
Создать отдельную задачу:
- «Частичный монтаж инженерных систем»
- «Отделка помещений»
Так логика становится прозрачной и проверяемой.
