Простыми словами: что такое вехи проекта и как сделать работу управляемой

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

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

Вместе с Ариной Барловой, сертифицированным проектным менеджером, разобрались, что такое вехи, какова продолжительность контрольной точки и как визуализировать вехи проекта в Kaiten.

Вехи: что это и для чего

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

Также вехи называют «майлстоун» (от англ. «milestone»), что переводится как «мильный камень» — отметка на пути о расстоянии.

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

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

Вехи в проекте нужны для того, чтобы понимать:

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

Чем вехи отличаются от целей и этапов проекта

Планирование проекта тесно связано с такими понятиями, как «цели», «этапы проекта» и «вехи». Давайте разграничим их, используя пример из жизни — постройку дома.

Цель проекта — это ваше конечное видение, например, «построить дом мечты».

Этапы проекта помогают разбить большую цель на маленькие, управляемые части, такие как: закладка фундамента, строительство стен, установка забора и т. д.

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

Поэтому делаем вывод. Главное отличие вех от целей и этапов заключается в их характере и функции. Цели проекта определяют, что именно нужно достигнуть.Этапы проекта описывают основные разделы работы. Вехи же выступают как контрольные точки, позволяющие оценить, насколько успешно проект движется к своим целям.

Как определить ключевые вехи проекта

Определение вех начинается с понимания структуры и целей проекта. Поэтому руководитель может спросить себя: «Какие ключевые моменты помогут мне понять, что проект движется вперед?» Ими могут стать подписание контракта с ключевым клиентом, успешное прохождение тестирования или другие события.

Обычно вехи задач расставляются на дорожной карте на этапе планирования. Давайте снова разбираться на примере.

Представим, что компания хочет сделать веб-приложение. Тогда управление проектом будет состоять из 4 ключевых шагов. Коротко рассмотрим, как визуализировать каждый шаг в Kaiten, используя диаграмму Ганта. Для детального погружения в работу с диаграммой приглашаем в наш подробный гайд.

Шаг 1. Описываем проект

На этом этапе нужно:

• описать цели и проблемы, которые проект точно решит;
• оценить возможности, риски, перспективы на рынке;
• предварительно оценить ресурсы и сроки;
• подумать о технологиях, которые будем использовать в проекте.

На выходе компания получает концепт или описание проекта «Как сделать веб-приложение». В нем будут отражены ожидаемые результаты и цели, с помощью которых будет понятно, что проект успешно реализован.

Чтобы начать работу с проектом в Kaiten, для начала нужно создать пространство с доской. А после — перейти в раздел пространства Timeline и создать проект, нажав на плюс.

Шаг 2. Раскладываем проект на работы и результаты

Для достижения поставленных целей — результатов проекта — их можно декомпозировать на небольшие задачи. В этом помогает метод WBS (Work Breakdown Structure) — он же ИСР, Иерархическая Структура Работ.

Проще говоря, WBS — это инструмент планирования, в основе которого лежит известный прием тайм-менеджмента: чтобы съесть слона, нужно разделить его на бифштексы. То есть разбить большой проект на задачи, которые помогут достигнуть результата.

Обычно организация проекта строится по этапам работы (от инициации до реализации) или критериям (типам работ, срокам).

Существует и альтернативный подход, например, во фреймворке P3.express. В нем менеджер может сделать карту результатов, которые получит от конкретных работ. Это поможет понять, какие задачи и действия приведут к нужным исходам.

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

Важно, что в WBS фиксируются ожидаемые результаты, а не отдельные задачи или процессы.

WBS прописываются именно результаты будущих работ, а не задачи и процессы. Посмотрели на описание проекта, понимаем, что WBS будет выглядеть так:

Шаг 3. Формулируем задачи

На основании выделенных результатов работ формулируем задачи и подзадачи, выполнение которых поможет достичь этих результатов (с учетом рисков).

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

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

В Kaiten вы можете добавлять базовую линию проекта и редактировать задачи в режиме Timeline.

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

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

Шаг 4. Устанавливаем вехи

Когда результаты проекта, задачи, ответственные и тайминг проекта визуализированы, гораздо проще выделить важные моменты проекта — ключевые вехи.

Для нашего примера с приложением проджект-менеджер может выделить такие вехи:

• утверждение концепта веб-приложения;
• утверждение бюджета и графика работ;
• согласование ТЗ;
• завершение, например, бэкендной разработки, клиентской разработки или завершение разработки MVP.

В Kaiten на диаграмме Ганта вехи обозначаются фиолетовым ромбом.

Важный момент. Вехи зависимы от конкретных задач. Например, сдача готового макета веб-приложения от команды дизайна напрямую влияет на событие (веху) «Утверждение дизайна».

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

Не рекомендуется располагать важные вехи далеко друг от друга или ставить их слишком близко друг к другу.

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

Как контролировать вехи проекта

Вехи — это не просто галочка в вашем календаре. Это возможность оценить, насколько эффективно движется проект, и при необходимости скорректировать план.

После того когда вы визуализируется план по вехам на диаграмме Ганта, нужно:

1. Поделиться созданным списком вех с командой

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

Например, если команда думает, что мы утвердим концепт проекта 25 марта, но из-за зависимости от подрядчика закончить проект получится только 2 апреля. В этом случае нужно сдвинуть срок у задачи и изменить дату вехи, оповестив всю команду в карточке.

2. Определить время проверки для вех

Обычно менеджер контролирует выполнение задач, поставку результата и его передачу в нужные руки.

Например, веха — утверждение дизайн-проекта в заказной разработке. Есть договоренности с заказчиком, что это событие произойдет в понедельник, в 12.00.

Аналитик позже сдал ТЗ, дизайнер позже взял в работу, задержался, чуть не умер, но сдал вовремя. Могла ли я предугадать, что сдвиг по задаче аналитика окажется существенным для вехи? Могла ли вмешаться и отдать готовое ТЗ частями, а не отдавать по готовности целиком, чтобы дизайнер мог начать вовремя свою часть?

К сожалению, универсального ответа на эти вопросы нет. Чтобы определить время для вех, менеджеру нужно проводить регулярные встречи с командой, собирать обратную связь и обращать внимание на дедлайны. Логично спрашивать у исполнителя, будет ли готова какая-то часть работы к такому-то сроку, потому что от этого зависит важное событие.

Помимо встреч и личного общения, можно отслеживать статусы задач в таск-трекерах. Если карточка не была взята в работу в оговоренный срок, PM может изменить дату сдачи задачи, найти другого исполнителя или перенести веху.

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

3. Отмечать вехи

Наступление долгожданного важного события — отличный повод похвалить команду, расставить акценты на целях будущих этапов, дать команде выдохнуть, увидеть, что они хорошо справляются. Что их работа сделала наступление этого события возможным.

Как отмечать вехи, которые сдвинулись? Как обычные вехи. Можно коротко указать, что с опозданием, но добились, справились. Обратную связь, разбор ошибок, комментарии по результатам можно давать в личке.

4. Анализировать план-факт достижения вех

Слишком амбициозные сроки? Слишком маленькие команды? Слишком большие сроки, с запасом и мы всегда опережали план? В следующих проектах это поможет лучше планировать и контролировать ход выполнения проекта.

Свои наблюдения можно указывать в отчете заинтересованным лицам или поделиться ими с командой. Например, предложить устроить брейншторм вместе.

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

Это прозрачно и честно по отношению к команде, проекту, заказчику.

Советы и ошибки

Теперь, когда мы разобрались терминологией, давайте рассмотрим популярные ошибки и рекомендации при работе с вехами (майлстоунами).

Распространенные ошибки

• Слишком много вех. Если каждое небольшое действие становится вехой, их значимость теряется. Фокусируйтесь на действительно ключевых моментах.
• Недостаточно четкое определение. Неопределенные вехи могут привести к путанице и недопониманию в команде.
• Отсутствие связи вех с планом проекта. Вехи должны быть интегрированы в общий план и способствовать достижению целей проекта.

Советы

• Будьте конкретны. Веха должна быть четко определена. Недостаточно просто назвать веху «Начать строительство дома». Лучше обозначить ее четко и конкретно — «Закладка фундамента завершена».
• Свяжите вехи с ключевыми достижениями. Вехи должны отражать значимый прогресс в проекте, а не просто отмечать время. И не забывайте отмечать вехи вместе с командой.
• Используйте вехи для коммуникации с командой и заинтересованными сторонами. Вехи — отличный способ держать всех в курсе основных достижений проекта.

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