Я очень люблю MS Project. Не потому что это идеальный инструмент и не потому что без него нельзя управлять проектами. Можно. Но в проектном бизнесе он хорошо решает одну важную задачу: заставляет проверить управленческое ощущение логикой графика.

На глаз всегда можно сказать: «эта работа займёт примерно месяц», «здесь нужно три месяца», «это можно делать параллельно», «а вот это начнём после того».

Но нередко после построения нормального графика выясняется, что проект устроен иначе. Работы не так параллельны, как подсказывал опыт, а какой-то небольшой документ, который легко забыть, внезапно становится на критическом пути всего проекта.

Например, заказчик задерживает доверенность. Проектировать вы, может быть, начнёте. А вот согласовывать проект — нет. В голове такой документ можно не удержать. Хорошо собранный график напомнит.

Для меня MS Project — это модель проекта. Но модель работает только при соблюдении правил.

Первое — нужна нормальная декомпозиция работ. Не слишком крупная, где за одной строкой «разработка документации» скрывается два месяца разных действий. И не слишком мелкая, где “взял длкумент”, “взял ручку”, “поставил подпись”. За такими микрозадачами просто никто не станет следить.

Второе — у задач должны быть зависимости: предшественники и последователи. На мой взгляд, это вообще основа хорошего графика. Если у задачи нет последователя, стоит задать простой вопрос: зачем она нужна? К чему она ведёт? Возможно, задача действительно справочная или завершающая. Но часто отсутствие связи означает, что логика проекта просто не описана.

А если логика не описана, график перестаёт быть инструментом управления. Он превращается в ручную подгонку ощущений руководителя проекта под желаемый срок.

Критический путь проекта нередко может проходить не там, где его ждёшь. Он может проходить не через самую сложную техническую работу, а через согласование, исходные данные, письмо или третьестепенную задачу. Увидеть это можно только тогда, когда зависимости прописаны внимательно.

В нашей компании мы стараемся вести графики по единой структуре.

Верхняя часть графика — для руководства. Там вехами указаны основные этапы договора. Формулировки строгие, единообразные и совпадают с договором. Это ускоряет сверку: можно быстро понять, какой этап договора когда стартует и когда заканчивается.

Нижняя часть графика — рабочая зона руководителя проекта или главного инженера проекта. Там первичная структура также соответствует договору, но внутри управленческих блоков они сами расписывают конкретные задачи так, как им удобно.

Например, одному руководителю достаточно одной строки: «получение письма о согласовании». А другому удобнее разложить это на несколько действий: «направить проект на согласование», «проверить статус через 7 дней», «получить письмо о согласовании».

И оба подхода могут быть правильными. Одному человеку нужны напоминания внутри графика, другому достаточно видеть ключевое событие. Важно не заставлять всех вести график одинаково до последней строки, а договориться о единых правилах именно там, где это влияет на управление.

Так руководители видят в графиках то, что нужно им: сроки, этапы, риски, критический путь и связь с договором. А исполнители ведут рабочую часть так, чтобы им самим было удобно управлять задачами.

Но это работает только при общих стандартах.

Когда проектов три-четыре, каждый график может быть «снежинкой»: со своей логикой, формулировками и структурой. Это ещё можно удержать в голове.

Когда проектов больше десяти, так уже нельзя. Команда начинает тратить время не на управление проектами, а на расшифровку чужой логики. Хороший график в MS Project — это не просто план работ. Это управленческий язык компании.

Главный вывод для меня такой: MS Project полезен не тогда, когда в нём нарисовали диаграмму Ганта. Он полезен тогда, когда график начинает спорить с ощущениями руководителя и показывает, как проект устроен на самом деле.