Как работать с планом проекта в условиях повсеместного Agile Как какой то момент все вдруг поняли, что каскадные модели планирования - это атавизм. И все побежали в agile и scram. Фраза «Проектный менеджер» стала чуть ли не ругательной. Но прошло время, стих хайп и вдруг все поняли, что кому то все таки надо собирать требования, ругаться с заказчиком, вести дурацкую работу с документами и много еще чего, что новые методологии не предполагают вообще. И тут вспомнили, что есть же Он! Так, ну и где там наш решала всех вопросов, вечно затюканный РП? Тащите сюда, пусть нас любимых обслуживает. Так РП начали пытаться превращать в ишака, который тащит проблемы, а не в лидера проекта. Смесь из администратора, консьержа и завхоза. Почему пишу именно в таком ключе - наблюдаю такую картину и в своей организации, где сейчас работаю, и в других, где работает много бывших коллег. Что с этим делать? Всегда помните - лидер проекта, на котором ответственность за его успех или провал именно Вы. Нельзя пытаться встать в позицию, ну раз я ничего не решаю, то буду просто бумажки перебирать, вести результаты совещаний и вообще - во всем виноваты команды. Это же они на самом деле проект ведут, а я так- для прицепа. Это не правильно. Это не позиция сильного лидера. Что надо сделать. 1. На этапе фиксации требований, выписывайте все бизнес фичи, которые должны появиться в результате проекта. Это будет ваш будущий план по вехам доставки функционала. Почему так- прогресс для заказчика должны быть видимым. 2. С каждой командой проекта договоритесь, что они могут планировать свои работы любым способом, но все их активности должны реализовывать одну из ваших фич функционала. Весь бекэнд разработки или других работ, убирайте внутрь работ по вехам. 3. Весь бэклог задач проекта должен быть ориентирован на достижение одной из ваших вех. В той последовательности, как вы все договоритесь. Это возможно. Это поддается планированию. Это полностью соответствует методологиям. 4. Настаивайте на своем видении управления проектом. Почему это удобно: вы отвечаете за передачу результатов проекта заказчику. Вот такие видимые результаты заказчик ожидает. Как и какой методологией команды вам их будут поставлять- это проблема команд. Но- за график сдачи функционала отвечаете вы. Вы показываете и защищаете эти сроки перед заказчиком. Задача команд- реализовать функционал в согласованные сроки. Вот именно тут ваши интересы точно зонируются. И вы имеете конкретные точки влияния на вектор развития проекта и направления работы команд. 5. И в конце концов, перестаньте себя уже называть РП. Зовитесь круто- Деливери Менеджер.