Моя роль в планировании проекта
Когда я руководил проектным офисом, через него проходило планирование всех новых проектов компании. Одновременно в портфеле находилось около пятнадцати инициатив. Они отличались по содержанию, но сам подход к подготовке плана менялся незначительно.
Я не пытался быть экспертом во всех предметных областях. Для этого есть руководитель проекта и функциональные специалисты: они знают требования заказчика, технологию работы и ограничения своих подразделений. Моя задача как руководителя PMO заключалась в другом — организовать процесс, задать правильные вопросы и превратить разрозненные знания участников в согласованную модель проекта.
Такое разделение ролей важно. Специалист может прекрасно знать, как нанять персонал или открыть склад, но не видеть межфункциональные зависимости. Методолог, наоборот, умеет построить сетевой график, но не должен самостоятельно придумывать содержание работ. Качественный план появляется только при соединении этих компетенций.
Входная задача: открыть новый склад
Разберу подход на реальном типе задачи из моей практики. Логистическая компания планировала открыть склад в новом регионе. Это требовалось, чтобы выполнить условия крупного клиента по географии присутствия и снизить затраты на доставку и хранение товаров в соседних регионах.
На подготовку проекта отводилось две недели. За это время нужно было описать содержание, разработать расписание, определить бюджет и необходимые ресурсы, а затем согласовать план с участниками и руководителями подразделений. Сам склад должен был начать обслуживать клиента примерно через три месяца.
На входе такая задача выглядит понятной: найти помещение, нанять людей и запустить работу. Но уже первый разбор показывает, что «открыть склад» — это не одна работа. Это набор связанных результатов в юридической, кадровой, транспортной, ИТ-, финансовой и операционной областях. Если хотя бы один критический контур не готов, объект физически существует, но бизнес-результат не получен.
Шаг 1. Собрать команду планирования
Сначала я определяю не всю будущую команду проекта, а круг людей, без которых невозможно описать содержание и построить реалистичный план. Главные участники — руководитель проекта и представители функций, владеющие необходимой информацией.
Заказчик или спонсор часто является топ-менеджером. Он задаёт бизнес-ожидания и принимает ключевые решения, но его участие в каждой рабочей сессии не всегда полезно. Если исходная постановка достаточно ясна, детальное планирование эффективнее проводить с его заместителем или профильными руководителями, а накопленные вопросы выносить заказчику отдельным списком.
В проекте открытия склада я привлёк руководителя проекта, руководителя HR, юриста и начальника транспортного отдела. Руководитель проекта знал требования клиента и имел опыт похожей работы. HR мог оценить подбор и найм персонала. Юрист — лицензии, регистрационные действия и корпоративные документы. Транспортная функция — перемещение и оформление автомобилей.
Финансистов и ИТ-специалистов на первую рабочую сессию мы не приглашали: их типовые требования уже были известны, а специфических вопросов на этапе первичной декомпозиции не возникало. Это не означает, что они исключались из проекта. Они подключались тогда, когда появлялся предмет для оценки и согласования.
Главный критерий состава встречи прост: каждый участник должен принести знание, необходимое для построения модели. Большая группа не делает план точнее — она часто лишь замедляет разговор.
- кто понимает ожидаемый бизнес-результат;
- кто уже выполнял похожую работу;
- кто знает ограничения ключевых функций;
- кто способен оценить длительность и ресурсы;
- чьё решение потребуется для утверждения допущений.
Шаг 2. Определить содержание через результаты
Первую сессию я начинаю без сложной системы автоматизации. Доска, большой лист бумаги или простой цифровой canvas позволяют быстрее фиксировать идеи и перестраивать структуру. Инструмент не должен мешать группе думать.
Я объясняю участникам, что не являюсь предметным экспертом и нуждаюсь в их помощи. Затем задаю похожие вопросы с разных сторон: из каких результатов состоит проект, что должно существовать к моменту запуска, какие условия позволят заказчику принять результат, какие объекты и документы будут переданы в эксплуатацию.
Повторяемость вопросов намеренна. Один человек думает категориями действий, другой — объектов, третий — критериев готовности. Разные формулировки помогают обнаружить то, что не появилось бы в ответе на общий вопрос «что нужно сделать?».
Полученные результаты я объединяю в иерархическую структуру работ — WBS. На верхнем уровне проекта открытия склада появились здание, персонал, юридическое оформление, складское и офисное оборудование, автоматизация, транспорт, бизнес-процессы, безопасность и изменения бюджета. Затем каждый блок раскладывался глубже до управляемых результатов и работ.
Я проговариваю вслух то, что заношу в структуру. Так участники следят за логикой, исправляют неверную интерпретацию и дополняют картину. На этом этапе лучше добавить сомнительный элемент, а затем удалить его, чем незаметно потерять критическую часть scope. Многие проекты начинают разрушаться именно из-за поверхностной проработки границ.
- Из каких результатов состоит проект?
- Что должно быть готово для начала обслуживания клиента?
- Какие 3–5 результатов заказчик считает критическими?
- Какие документы, объекты, системы и роли передаются в эксплуатацию?
- Что сознательно не входит в проект?
Шаг 3. Зафиксировать допущения и вопросы к заказчику
Во время декомпозиции почти всегда появляются утверждения, которые группа считает истинными, хотя заказчик их явно не подтверждал. Их нельзя оставлять внутри расписания как скрытые предположения.
Для склада такими вопросами были требования к объекту, использование существующей конфигурации учётной системы, необходимость перемещения товарного запаса и включение в границы проекта отдельных коммерческих договоров. Ответ на каждый из них мог изменить содержание, сроки или бюджет.
Я веду отдельный список допущений и вопросов. После рабочей сессии заказчик подтверждает их либо даёт новые вводные. Если допущение остаётся неподтверждённым, оно должно быть видно как риск, а не маскироваться точной датой в плане.
Современные системы позволяют связать допущение с задачей, решением и владельцем. Но управленческий принцип не изменился: план достоверен только при тех условиях, на которых он построен. Изменилось условие — нужно пересчитать прогноз и осознанно принять последствия.
Шаг 4. Перенести WBS в рабочее расписание
После первичной декомпозиции я вместе с руководителем проекта переношу структуру в систему календарно-сетевого планирования. В исходном кейсе это был Microsoft Project, но выбор программы не является сутью метода. Для сложного расписания важно, чтобы инструмент поддерживал иерархию работ, зависимости, ресурсы, базовый план и расчёт критического пути.
При переносе мы ещё раз проверяем формулировки. Название должно описывать конкретную работу или проверяемый результат, а не размытый процесс. «Работа с персоналом» не позволяет определить завершение. «Ключевой персонал принят и готов к обучению» задаёт понятное состояние.
WBS и расписание решают разные задачи. WBS отвечает на вопрос, из чего состоит результат. Расписание добавляет последовательность, длительность, календарь и ресурсы. Если сразу начать с диаграммы Ганта, команда легко забудет часть содержания и преждевременно сосредоточится на датах.
Шаг 5. Установить зависимости
Когда структура готова, команда определяет предшественников и последователей каждой значимой работы. Я задаю простые вопросы: что невозможно начать до завершения этой задачи, какой результат является входом для следующей работы, что перестанет двигаться при задержке?
Работа методичная и не всегда увлекательная, но именно она превращает список задач в модель проекта. Фраза «можно делать в любой момент» часто означает, что зависимость ещё не найдена или участник рассматривает только свою функцию.
В сетевом графике я создаю одну начальную и одну итоговую веху. Все значимые ветви должны быть связаны с общим стартом и завершением. Так можно проверить целостность сети, сдвигать стартовую дату и видеть рассчитанный прогноз окончания.
При этом не нужно механически связывать всё со всем. Лишние зависимости делают расписание хрупким и создают искусственный критический путь. Каждая связь должна отражать реальное технологическое, информационное или управленческое ограничение.
Шаг 6. Назначить реальных ответственных
Параллельно с зависимостями мы назначаем владельца каждой работы. Мне важно видеть конкретного человека, который способен организовать получение результата. Названия подразделений и обезличенные роли вроде «разработчик» скрывают ответственность и не позволяют проверить реальную доступность ресурса.
Это не означает, что один исполнитель делает всю работу лично. Он может координировать группу, привлекать подрядчика или получать данные от коллег. Но в плане должен существовать человек, у которого можно запросить прогноз и который понимает своё обязательство.
После назначения ответственных становится видна ещё одна реальность: один специалист одновременно нужен нескольким потокам или проектам. Поэтому план согласуется не только с участниками, но и с ресурсными руководителями. Без их подтверждения назначение человека остаётся пожеланием проектной команды.
Шаг 7. Оценить длительность, ресурсы и риски
Оценку длительности должен давать тот, кто понимает работу и условия её выполнения. Руководитель проекта и PMO проверяют логику, сравнивают с похожим опытом и задают вопросы, но не подменяют эксперта произвольной цифрой.
В первоначальной практике я иногда добавлял резервы прямо в работы, где ожидались задержки согласований или передачи информации. Это помогало построить более реалистичный прогноз, однако со временем мой подход стал строже: резерв должен быть виден и управляем. Скрытый запас внутри каждой оценки затрудняет анализ и может быть незаметно израсходован.
Сегодня я предпочитаю разделять рабочую оценку и резерв, связывать его с конкретной неопределённостью и размещать там, где им можно управлять: перед ключевой вехой, на уровне потока или всего проекта. Для существенных рисков определяются владелец, триггер и действие реагирования.
На этом же шаге оцениваются трудозатраты, оборудование, внешние закупки и денежные расходы. Бюджет не формируется отдельно от расписания: стоимость возникает из выбранного способа выполнения работ, используемых ресурсов и календаря.
Шаг 8. Проверить, укладывается ли модель в требуемый срок
Первая версия расписания открытия склада не помещалась в установленное окно. Расчёт показывал: чтобы закончить всё вовремя, проект следовало начать значительно раньше. Это полезный результат планирования, а не ошибка программы. Модель впервые сделала конфликт ожиданий и реальности видимым.
Мы не стали вручную сокращать длительности до желаемой даты. Вместо этого вместе с командой проверили логику. Часть найма можно было вести параллельно, а некоторые зависимости оказались необязательными. Главное решение состояло в разделении двух вех: «склад готов обслуживать клиента» и «проект полностью завершён».
В первую веху вошли только результаты, необходимые для начала работы с клиентом. Второстепенные элементы можно было закончить позднее без ущерба для основного бизнес-результата. После оптимизации обязательный контур завершался с резервом до целевой даты.
Так выглядит содержательная оптимизация: изменить способ выполнения, последовательность, ресурсы или границы этапа. Простое сокращение оценок создаёт красивый график, но не повышает вероятность результата.
- параллелизировать действительно независимые работы;
- убрать искусственные зависимости;
- усилить критические задачи ресурсами;
- разделить запуск ценности и полное завершение;
- вынести изменение срока или scope на решение заказчика.
Шаг 9. Согласовать и зафиксировать базовый план
После рабочей модели остаётся превратить её в управленческое обязательство. Я готовлю устав проекта, фиксирую цели, результаты, границы, ключевые вехи, бюджет, допущения и роли. Руководители подразделений подтверждают участие своих специалистов и проверяют обязательства функций.
В исходном кейсе разработка проекта заняла около недели: три рабочие встречи общей продолжительностью примерно десять часов плюс обработка результатов, построение расписания и согласования. Это не универсальный норматив, а показатель того, что даже межфункциональный проект можно подготовить быстро, если собрать правильных людей и вести обсуждение по строгой логике.
После утверждения расписание становится базовым планом. Он нужен не для наказания за любое отклонение, а для различения трёх вещей: что было обещано, что изменилось по решению и что стало отклонением исполнения. Новые вводные после утверждения проходят через управление изменениями с оценкой влияния.
Что в этом подходе осталось неизменным
Инструменты стали удобнее: совместные доски, современные task trackers, портфельные системы и BI быстрее связывают данные. Но программа по-прежнему не способна сама определить содержание проекта, договориться о допущениях и назначить реального владельца результата.
Последовательность остаётся той же: собрать носителей знаний, определить результаты, построить WBS, подтвердить допущения, установить зависимости, назначить ответственных, оценить длительность и ресурсы, проверить срок, оптимизировать и согласовать базовый план.
Сильный план — не максимально подробный документ. Это достаточно точная модель того, как организация собирается получить результат. Она показывает участникам их обязательства, руководителю проекта — логику исполнения, а заказчику — цену решений и честный прогноз.
Если расчёт говорит, что желаемая дата недостижима, задача руководителя проекта не заставить диаграмму показать нужное число. Его задача — объяснить причины, предложить варианты и добиться осознанного выбора. Именно в этот момент планирование становится управлением.