Всем привет! Меня зовут Константин Замков. Я главный менеджер в компании «СИБИНТЕК», сертифицированный специалист по управлению проектами PMI PMP, управлению портфелями проектов PMI PfMP и Scrum-мастер PSM-I. В своей работе я управляю сложными комплексными ИТ-проектами и регулярно занимаюсь разработкой и актуализацией календарных планов. В этой статье хочу поделиться практическим подходом, который сформировался у меня за годы работы.
Интересно наблюдать, как на профессиональных встречах или внутри команд фраза «календарный план проекта» нередко вызывает либо недоумение, либо скрытое раздражение. Многие предпочитают избегать жесткой привязки к датам. Но реальность бизнеса устроена иначе.
Любая компания, инвестируя серьезные средства — на корпоративном языке это капитальные вложения (CAPEX) — ожидает получить конкретный результат. Чаще всего это новый продукт или система, то есть нематериальный актив, который будет приносить бизнесу пользу в течение многих лет. И чем выше стоимость проекта и сложнее создаваемый продукт, тем чаще заказчик задает два простых вопроса: «Сколько это будет стоить?» и «Когда это будет готово?»
Чтобы ответить на них, руководителю проекта приходится связывать в единую систему задачи, зависимости, ресурсы и риски. Результатом становится календарный план проекта. Подходы к планированию могут различаться в зависимости от методологии и культуры компании. В этой статье я расскажу о практике классического водопадного календарного планирования.
Четыре этапа календарного планирования
В своей практике я условно делю календарное планирование на четыре последовательных этапа.
-
Декомпозиция целей и задач
Все начинается с анализа входной информации: запроса, требований и целей проекта. Эту работу я обычно провожу совместно с главным архитектором. Наша задача — превратить крупные и часто абстрактные цели проекта в конкретные, измеримые задачи и подзадачи. Одновременно на этом этапе совместно с заказчиком важно определить ключевые контрольные точки — вехи проекта. Именно они позволяют отслеживать движение проекта и фиксировать промежуточные результаты.
Типичными примерами таких вех могут быть:
• завершение этапа проектирования;
• выпуск прототипа;
• окончание интеграционного тестирования;
• запуск системы в промышленную эксплуатацию.
Наличие вех делает проект «видимым» как для команды, так и для бизнеса.
-
Определение последовательности работ
Следующий шаг — определить логические связи между задачами.
Совместно с главным архитектором проекта мы определяем:
• какие работы можно выполнять параллельно;
• какие задачи должны выполняться строго последовательно.
Важно зафиксировать не только сами задачи, но и их зависимости — именно на этом уровне часто возникают ошибки при масштабировании проектов. Простой пример зависимости: «Пока не готов API, разработчики фронтенда не могут начать интеграцию». На этом же этапе определяется длительность работ. Здесь почти всегда возникает дискуссия о том, насколько детально нужно планировать задачи, которые будут выполняться через полгода или год. Избыточная детализация может привести к тому, что план придется постоянно переделывать. Поэтому я стараюсь находить баланс между точностью и гибкостью. В последних проектах оптимальным оказался уровень детализации до 10 рабочих дней на одну задачу. После этого определяется критический путь проекта — цепочка задач, задержка любой из которых автоматически сдвигает дату релиза.
Как показывает практика, в ИТ критический путь часто проходит не через разработку ИТ‑решения. Узкими местами могут оказаться:
• согласование доступов;
• закупка оборудования;
• внешнее тестирование.
Если задача на критическом пути начинает «буксовать», это сигнал для руководителя проекта: ей нужно уделить максимальное внимание.
-
Оценка трудозатрат и ресурсов
Когда структура работ определена, наступает этап планирования ресурсов. Совместно с главным архитектором проекта и руководителями профильных подразделений мы определяем исполнителей для каждой задачи. После этого в плане фиксируются конкретные даты начала и окончания работ с учетом:
• доступности специалистов;
• зависимостей между задачами.
Если необходимых специалистов нет внутри компании, то я корректирую план для задач, которые не лежат на критическом пути. Если же отсутствует специалист для задачи на критическом пути — я запускаю процесс их поиска совместно с HR и руководителями профильных подразделений.
В результате формируется ресурсная модель проекта — перечень специалистов, закрепленных за задачами календарного плана.
-
Утверждение плана и базовое расписание
Финальный этап — согласование календарного плана со всеми ключевыми участниками проекта.
В этот процесс обычно вовлечены:
• руководство компании;
• проектный офис;
• руководители профильных подразделений;
• заказчики.
После согласования создается базовое расписание проекта — эталонный график, относительно которого в дальнейшем отслеживается выполнение работ.
Почему календарный план может не работать
Даже хорошо составленный календарный план не гарантирует идеального выполнения проекта. На практике возникают типовые проблемы. За годы работы я выделил пять самых распространенных.
-
Переключение между задачами
Проблема
Сотрудник одновременно участвует в нескольких проектах. Постоянное переключение между задачами приводит к серьезной потере эффективности. По разным оценкам, до 40% рабочего времени может уходить на смену контекста. На бумаге кажется, что одного специалиста со 100% загрузкой легко заменить пятью людьми с загрузкой по 20%. На практике это почти никогда не работает.
Решение
По возможности ключевых специалистов я стараюсь подключать к проекту с полной загрузкой.
-
Ошибка оптимиста
Проблема
Разработчики часто оценивают задачи исходя из идеальных условий. Например: «Эта задача займет два часа».
Но реальность обычно выглядит иначе:
• час уходит на настройку среды;
• два часа — на изучение документации;
• еще несколько — на исправление ошибок в сторонних библиотеках.
В итоге двухчасовая задача превращается в двухдневную.
Решение
Я применяю коллективную оценку задач и метод PERT:
(Оптимистично + 4 × Реалистично + Пессимистично) / 6
Это помогает снизить влияние субъективных ожиданий.
-
Отсутствие контрольных точек
Проблема
Если в проекте нет четких ориентиров прогресса, команда постепенно теряет мотивацию, а заказчик перестает видеть движение проекта.
Решение
Я стараюсь фиксировать ключевые вехи на каждый месяц и квартал, например:
• завершено проектирование;
• проведены испытания системы;
• выполнена миграция данных;
• система переведена в промышленную эксплуатацию.
При этом хотя бы раз в квартал важно поставлять заказчику новую функциональность.
-
Неактуальность плана
Проблема
Иногда календарный план существует только формально. Он составлен один раз и больше не обновляется. Команда работает по факту, а график превращается в бюрократический документ.
Решение
Я назначаю ответственного за еженедельную актуализацию плана и регулярно обсуждаю его состояние с командой.
-
Расползание объема работ
Проблема
Знакомая фраза:
«Тут всего лишь кнопочку перекрасить и поле добавить»
Такие небольшие, но неформальные пожелания заказчика могут незаметно «съесть» до 20% времени команды, постепенно разрушая график проекта.
Решение
Я придерживаюсь принципа: базовый план менять можно только через официальный запрос на изменение.
Обычно диалог выглядит так:
«Хотите добавить кнопку? Вот оценка. Это сдвинет релиз на четыре часа. Согласуем?»
После этого либо изменение исчезает, либо оформляется официально.
Итог
Календарное планирование — это не бюрократия и не самоцель. Это инструмент управления ожиданиями, коммуникации и защиты команды. Когда есть план, руководитель проекта не надеется на удачу — он управляет реальностью.
В ИТ мы строим сложные системы. А любая сложная система нуждается в архитектуре — не только архитектуре кода, но и архитектуре времени. Станьте архитектором времени своего проекта — и вы увидите, как меняется отношение к вам со стороны и команды, и бизнеса.
ссылка на оригинал статьи https://habr.com/ru/articles/1022144/