Практически все проекты (настоящие, соответствующие классическому определению, когда в условиях временных и ресурсных ограничений создаётся уникальный результат) сложны и требуют серьёзного напряжения сил проектной команды для успешного их завершения. Причём сложность проектов проявляется не только в техническом и методологическом аспектах, но и в психологическом. По умолчанию положительный результат проекта ни разу не гарантирован, и не каждый готов взвалить на себя эту ношу.

Больше всего достаётся менеджерам проектов. Ведь они отвечают за результат проекта и, в глазах стейкхолдеров, да и остальных участников проекта виноваты во всём негативном, что на их проектах происходит.

Чтобы не выгореть на первых проектах, нужно не только изучать проектный и продуктовый менеджмент, предметные области и т. д., но и изучать опыт других проектных менеджеров, чтобы хотя бы части «шишек» и «синяков» избежать.

Я тоже хотел бы поделиться опытом управления проектами. В ходе своей практической деятельности я был руководителем более 20 проектов в ИТ и кое-чего повидал. Надеюсь, мой опыт будет полезен как начинающим менеджерам проектов, так и более опытным.

Почти во всех моих проектах применялся и применяется классический waterfall, так как создавали мы с командами в основном громоздкие ERP-решения. Поэтому материал будет «водопадоориентированным», но, я надеюсь, и любители agile найдут что-нибудь полезное.

Когда я прикинул содержание своей статьи, то у меня получилось 27 пунктов. Какой-то long read. Поэтому, чтобы не утомлять читателей, я решил подготовить серию небольших статей.

Проведя в ИТ большую часть жизни, в основном как руководитель ИТ-проектов (на моём счёту их уже 26, почти все связаны с внедрением ERP-систем), я накопил некоторый опыт управления, которым хотел бы поделиться в своих статьях на Habr. Надеюсь, мои истории будут полезны начинающим проектным менеджерам и тимлидам, заинтересуют зрелых руководителей или хотя бы развеселят сообщество. Аналитикам, программистам, инженерам и т.д. эта статья, скорее всего, не будет интересна.

Как и многие руководители проектов, я мечтаю об инструменте, который бы позволял мне легко и непринуждённо планировать проектные работы на горизонте всего проекта, а также на месяц и на неделю, мониторить выполнение работ, управлять ресурсами, сроками, пользоваться удобными дашбордами, быстро формировать отчёты для руководства (а не рисовать картинки в Share Point) и т.д. Мечты, мечты… В большинстве проектов мне был доступен MS Project и MS Excel. Ну хотя бы так.

Давайте посмотрим, как решить с помощью этих двух инструментов задачу еженедельного планирования работ команды для средних ИТ-проектов длительностью от 3 месяцев до года и с командой до 15 человек.

В своих проектах я часто использую два плана-графика: верхнеуровневый (для проектов длительностью до шести месяцев среднеуровневый) и детальный на ближайшую неделю. Почему два? На мой взгляд, детальный план-график проект на всю его длительность делать сложно, а зачастую и вредно. Слишком много неопределённости на старте проекта и много чего меняется в его ходе. И если у вас нет команды планировщиков (а в ИТ я их не встречал), то всё нужно будет делать самому, и постоянная актуализация детального плана-графика «съест» всё время руководителя проекта. Поэтому такие расписания лучше делать верхнеуровневыми до конца проекта и среднеуровневыми на ближайшие два месяца, с длительностью задачи на нижнем уровне иерархии не менее 5 рабочих дней.

С другой стороны, на ближайшую неделю нужен точный план-график либо реестр задач с конкретными исполнителями и сроками.

Рассмотрим такие планы-графики на моём любимом кейсе – проекте «засунуть слона в холодильник». Могу, конечно, ошибаться, но на простых и весёлых примерах всегда проще и интереснее объяснять методику.