Что такое план проекта
📌 План проекта — тактический документ, который показывает действия и конкретные задачи на каждом этапе проекта. Благодаря плану проект реализуется в установленные сроки и в рамках бюджета. Если желаемый будущий проект — это общая картина, то план детализирует и объединяет её отдельные части.
В план проекта входят:
- График работ — на нём указывают этапы работы над проектом и вехи, или контрольные точки, которые говорят о достижении промежуточного результата
- Зоны ответственности — отдельных исполнителей и целых групп, например, отделов компании
- Риски, учтённые на этапе планирования
Основы проектного планирования
Проект имеет следующие признаки — это работа, ограниченная временем, ресурсами и нацеленная на появления ценности. Конечная цель проекта — результат.
Чтобы получить результат, нужно совершить череду действий — последовательных, логичных и (желательно) эффективных.
Отчасти эта череда действий и есть план. Отчасти — потому что просто расставить шаги в порядке важности и очерёдности мало.
План ограничивается сроками — датой старта и датой завершения, когда результат должен быть получен. В плане учтены и отражены ресурсы — время, люди и деньги — которые нужны для реализации.
Ещё круто, если в плане отражены возможные риски, которые могут возникнуть на пути реализации плана. Чтобы проактивно управлять возникающими проблемами, лучше заранее продумать, как участники проекта будут реагировать на них.
Получаем формулу плана проекта:
Задачи + Срок + Ресурсы + Учтённые риски = План проекта
Мастерство проджект-менеджмента не в том, чтобы расписать эти составляющие, а в том, чтобы увязать их вместе и уследить за всеми разом.
Как разработать плана проекта — 9 шагов
Шаг 1. Определить цель проекта
Важнейший шаг в планировании — понять, зачем проект нужен и какую ценность принесёт.
Задаются следующие вопросы:
- Зачем нужен проект?
- Какую пользу он принесёт?
- Как проект согласуется с целями компании?
- В чём новизна?
- Из чего будет состоять проект?
- Какие метрики будут свидетельствовать об успехе проекта?
- Кто заинтересованные стороны?
- Какая команда нужна для реализации?
Если честно и полно ответить на эти вопросы, можно даже прийти к выводу, что проект запускать не стоит — это нормально.
А если всё-таки дали зелёный свет, то нужно донести цели проекта до его ключевых игроков — заказчиков, группы стейкхолдеров, команды.
Шаг 2. Определить методологию управления проектом
В каждой методологии свои принципы и инструменты для организации задач, сроков и контроля промежуточных результатов.
Планирование в Agile — на примере методологии Scrum
Scrum — фреймворк из семейства методологий Agile, чем и определяется подход к проектной работе.
Agile — философия гибкого подхода к управлению проектами. В основе её принципов — ценность для клиента и адаптивность команды к изменениям. Адаптивность определяется ценностью: важнее внести в продукт ценное для клиента изменение, чем следовать первичному плану.
Согласно Scrum, на старте проекта нужно сформировать общий долгосрочный план, или бэклог продукта. Далее строят планы на спринты — короткие этапы работы по 1–4 недели — их называют бэклог спринта. Результатом спринта является прирост функциональности продукта, инкремент.
После спринта команда проводит ретроспективу — оценивает, что было сделано, что получилось, что не получилось. С учётом выводов формируют новый бэклог спринта.
Подробно познакомиться со всеми Scrum можно в двух наших текстах:
📎 Подробнее о методологии Scrum
Планирование в Waterfall
Waterfall, или водопадная модель — это ещё один подход к проекту. Здесь, в отличие от Agile, гибкости минимум.
Планировать проект по Waterfall значит определить порядок работы в начале. Этапы идут последовательно, один за другим, а план не меняется без крайней необходимости.
Этапы планирования в водопадной модели:
Сбор требований ➡️ Проектирование ➡️ Реализация ➡️ Тестирование ➡️ Эксплуатация и поддержка
Для визуализации этапов идеально подойдёт диаграмма Ганта в формате каскадной дорожной карты:
📎 Подробнее про водопадную модель Waterfall
Планирование в P3.express
P3.express — фреймворк для гибкого управления проектами, который представляет почти пошаговую инструкцию.
В P3.express семь циклов. В первом из них пристально оценивают важность проекта. Составляется верхнеуровневый план, но ключевая задача в решении — запускать проект или нет.
В остальных циклах методология рекомендует планировать методом набегающей волны — то есть уточнять и детализировать план по мере реализации проекта. План корректируют с учётом обратной связи от команды, заказчиков и хода проекта.
Управлять планом и реализацией проекта удобнее всего на Канбан-доске. Для этого в WEEEK есть готовый шаблон, который мы подготовили вместе со школой PMCLUB.
Как использовать шаблон:
- 1. Зайди в раздел Шаблоны в левом нижнем углу рабочего пространства
- 2. Переходи в раздел «Разработка и продукт»
- 3. Выбери шаблон «P3.express»
- 4. Нажми «Использовать шаблон»
Шаг 3. Создать предварительный план и структурную декомпозицию работ (WBS)
На этом этапе важно уточнить объём работ — он сильно влияет на сроки проекта. Для этого можно разработать структуру декомпозиции работ, или WBS (Work Breakdown Structure).
Эта схема позволяет разбить проект на небольшие части. Ход работ выстраивается иерархически — от общей цели проекта до задач и подзадач. Планировать и следить за прогрессом становится легче.
Создание WBS укладывается в четыре шага:
- Определение цели и результата проекта. Чем чётче, тем лучше. А ещё советуем подробно описать, что будет и не будет входить в результат
- Построение первого уровня иерархии. Для этого задайся вопросом «Что нужно сделать для достижения цели?». Ответ должен быть максимально ёмким — пока без детализации
- Разделение задач на подзадачи таким образом, чтобы они были простыми и выполнимыми. Важно, чтобы у каждой из них был ответственный и дедлайн
- Определение вех и распределение задач, чтобы понять, насколько схема реалистична. На этом этапе можно рассчитать трудоёмкость и распределить ресурсы, чтобы не перегружать команду
Собрать WBS можно в формате иерархической таблицы, ментальной карты или на диаграмме Ганта.
Шаг 4. Определить команду, роли и ресурсы
На этой стадии планирования необходимо чётко определить, кто нужен для успешного достижения целей проекта.
Как правило это:
- Проджект-менеджер или владелец проекта, который спланирует проект и ресурсы, распределит задачи и будет следить за сроками их выполнения
- Владелец продукта или заказчик проекта, который решит, какими будут цели и результат проекта
- Стейкхолдеры, которые повлияют на результат проекта и работу команды
- Бизнес-аналитик, который на основе данных о проекте определит, как он будет развиваться с учётом ключевых целей
- Члены команды, которые возьмутся за выполнение задач
Структурировать их отношения в работе помогут матрицы RACI и DACI. Это две таблицы, где расписано, кто и за что отвечает в проекте.
RACI определяет зоны ответственности в задачах, а DACI — ответственность за принятие решений. Их строят и согласовывают на старте проекта.
Матрицы помогают закрепить за каждым игроком команды его роль и зону ответственности, а ещё быстрее решать споры.
🔥 Готовые шаблоны для составления матриц RACI и DACI
💡 Чтобы визуализировать управление ресурсами, подойдут диаграмма Ганта или таймлайн. В документе можно перечислить этапы и задачи проекта, обозначить исполнителей и сроки работы.
Шаг 5. Создать календарный график проекта
Нужно собрать на диаграмме Ганта верхнеуровневый план проекта — он будет включать в себя все задачи, промежуточные этапы и дедлайны. В таком документе можно декомпозировать большие задачи, назначать исполнителей, отмечать вехи и многое другое.
💡 Календарных графиков проекта составляют два: для внутреннего и внешнего использования. С первым будет сверяться команда, а со вторым — внешние заинтересованные стороны, например, заказчики или стейкхолдеры.
📎 Подробнее о создании календарного графика проекта
Приоритизируй важные этапы и подзадачи в графике проекта. Срочные будут подсвечиваться красным, несрочные — зелёным, а замороженные — голубым.
Шаг 6. Оценить риски и спланировать порядок действий на случай отклонений
В план проекта важно включить потенциальные риски. Это повысит качество результата, минимизирует непредвиденные ситуации и упростит внесение изменений.
Как правило, за это отвечает проджект-менеджер, а помочь в оценке рисков могут стейкхолдеры и заказчик.
По PMBOK управление рисками можно разделить на пять шагов:
- Идентификация рисков. Команда собирается на мозговой штурм, чтобы собрать информацию о всевозможных рисках. Учитывается прошлый опыт, кейсы коллег по рынку, SWOT- и PEST-анализ. Далее всё это нужно занести в реестр рисков — список или таблицу
- Анализ рисков. Он может быть количественным, когда измеряется вероятность риска в цифрах, — или качественным, когда для оценки привлекают экспертов
- Планирование реакции на риски. Это поможет определить подходы и планирование мер. Нужно опираться на три стратегии: перенос, согласие и смягчение
- Мониторинг рисков. Важно контролировать риски параллельно с основной работой над проектом
- Общение и отчётность. Для минимизирования возможных проблем, важно поддерживать коммуникацию в команде, обмениваясь фидбеком и идеями по их решению
В методологии P3.express управление рисками входит в шаг D01, где их вносят в реестр последующего наблюдения.
Напоминаем, в нашем шаблоне для работы по P3.express для этого есть отдельная доска:
❗️Описывай риски так, чтобы смысл был понятен всей команде, и задай измеримые критерии успеха. В этом помогут алгоритмы и правила — лучше держать их под рукой, чтобы в случае проблемы решать её оперативно.
Шаг 7. Выстроить правила коммуникации
Перед началом работы определяем формат, частоту и каналы общения сотрудников.
О чём стоит позаботиться при составлении плана проекта:
- Планирование. На старте проекта проджект-менеджер предлагает план коммуникаций и согласует его с командой. Например, общаемся только в корпоративном чате с 10 до 19, в личные мессенджеры не пишем
- Ведение коммуникаций, или сам процесс взаимодействия. Команда обменивается статусами и отчётностью, документирует решения и передаёт заинтересованным лицам. Желательно отправлять информацию о ходе проекта в заранее установленное время
- Принятие мер с учётом фидбека. Например, если кто-то из команды выпадает из диалога в нужный момент и подводит остальных. Комментарии лучше всего оставлять по конкретным задачам
❗️Обговори с командой, почему важно следовать плану коммуникаций. Сотрудники будут в курсе происходящего на проекте — это поможет придерживаться общей цели, вовремя выполнять задачи и сохранять вовлечённость.
Проведи установочную встречу — не лишним будет письменно оповестить команду и стейкхолдеров о старте проекта. В командном чате или в письме расскажи, почему компания решила взяться за проект, какую пользу он принесёт компании, дай ссылку на дорожную карту и план проекта.
Шаг 8. Контролировать процесс
Когда задачи получены и сроки оговорены, менеджеру проекта надо выстроить систему отслеживания прогресса. Тут поможет таск-менеджер и другие фичи для управления проектами.
Задача проджекта — отслеживать общие дедлайны и промежуточные результаты, а не мониторить каждую задачу.
На Канбан-доске WEEEK есть статусы задач в колонках — можно начинать рабочий день с проверки, соблюдаются ли этапы и дедлайны. В этом помогут фильтры по Просроченным задачам или Непросроченным задачам проекта.
Ещё один способ эффективного мониторинга — уведомления о перемещениях задач из одной колонки в другую.
Для этого нужно настроить автоматизацию действий в колонках, чтобы приходило пуш-уведомление об изменении статуса задачи.
В WEEEK проджект-менеджер может контролировать ход работы через статус Подписчика задачи и настроить уведомления на события — смена статуса или исполнителя, новый комментарий. Тогда проджект получит уведомления об изменениях в задаче, не будучи исполнителем.
Дополнительно понимать, что происходит с проектом, помогут отчёты по статусам. Там отражают промежуточные результаты, проблемы и риски. Отчёты помогают оценивать прогресс и вовремя отлавливать проблемы.
Отчёты бывают ежедневными, еженедельными, ежемесячными и ежеквартальными. Частоту обмена статусами нужно обговорить с проджектом.
📎 Полный гайд по отчётам по статусам здесь
Шаг 9. Завершить план и запустить проект
Ура, мы на финише!
Редкий проект проходит гладко и без погрешностей. Советуем провести ретроспективу по итогам проекта, чтобы подсветить успехи и обсудить неудачи. Это похоже на работу над ошибками — она поможет качественнее планировать и реализовывать будущие проекты.
Ещё одна важная часть — постпроектные активности (или постпроектный мониторинг). Это нужно, чтобы контролировать, как приживается готовый продукт и насколько он соответствует потребностям аудитории. Как правило, за это отвечает отдельный менеджер, который ведёт подробный отчёт по постпроектному мониторингу.
План этого текста
- План проекта — это подробный документ, который включает его этапы, цели, результаты, сроки и риски
- График работ делает проект управляемым. Он подсвечивает зоны ответственности, помогает придерживаться целей и сроков, управлять рисками и ресурсами
- Элементы планирования проекта — задачи, сроки, ресурсы и бюджет
- План проекта составляется в следующем порядке. Сначала определяют цели, задачи и масштаб проекта, назначаются роли, распределяют ресурсы и бюджет. Затем создаётся график работ и оцениваются риски. В финале организуют общение и контроль прогресса
- Есть базовые шаги планирования проектов, но в каждой методологии свои тонкости и инструменты для организации этого процесса
Подписаться 
