Шаг за шагом: как мы управляем короткими и средними проектами длительностью до 1 года

Привет! Я Руслан Шапиев, руководитель проектного офиса в системном интеграторе DMM, поделюсь подробным процессом управления недолгими ИТ-проектами — от запуска до постпроектной работы.

Мы сотрудничаем с разными заказчиками, каждый из которых представляет управление их проектом по-своему. Особенно на проектах, которые завершаются в течение года, заказчики предпочитают более гибкие подходы. Часто они не придерживаются жёстких методологий, таких как PRINCE2, PMBOK, PM2, так как это требует дополнительного обучения и глубокого вовлечения их сотрудников.

Нужен более ясный подход — и мы выбрали P3.express. Эта методология предлагает простой процесс для любых проектов, будь то строительство или разработка приложения.

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

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

Мы взяли этот подход за основу и немного адаптировали его под себя.

Я решил поделиться с вами тем, как мы выстроили процесс управления. Далее описываю каждый шаг с пояснениями. Можете брать эту схему за основу и пробовать применять в своём проекте.

A01. Выбрать спонсора
A02. Назначить руководителя проекта
A03. Назначить ключевых членов команды

Эти три шага мы выполняем на этапе инициации проекта в рамках предпроектного обследования (ПО). Последнее необходимо, чтобы:

выявить функциональные разрывы, где нужна кастомизация под нужды заказчиков;
построить модели AS IS/TO BE (как есть / как должно быть) и проработать архитектуру.

В среднем предпроектное обследование занимает 1-2 месяца.

A04. Написать резюме проекта

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

А05. Ожидаемые результаты

Ожидаемые результаты мы прописываем в рамках предпроектного обследования. То есть комбинируем карту результатов и резюме проекта в одном документе. Получается микс на основе шаблона резюме проекта по Р3.express.

A06. Риски

Составляем реестр рисков.

A07. Ревью запуска проекта

Собираем все полученные и проработанные данные в отчёт — бизнес-кейс (резюме проекта), ожидаемые результаты и риски.

A08. Решить Go/No-Go

Знакомим заказчика с результатами предпроектного обследования. Далее рассказываем, что можем сделать с текущими ожидаемыми результатами и рисками, а что — нет, что лучше изменить.

Мы всегда стараемся описать все плюсы и минусы предлагаемых вариантов и способов реализации проекта. При этом финальное решение об инициации остаётся за заказчиком.

A09. Инициировать стартовую встречу

P3.express рекомендует инициировать стартовую встречу с вводной презентацией, чтобы обсудить план и ввести всех в курс дела.

Мы же проводим несколько встреч и до, и в процессе, и после предпроектного обследования.

Только после того, как мы предварительно согласовали бюджет на архитектуру, результаты ПО, мы инициируем стартовую встречу с топ-менеджментом компании (заказчиком и спонсором). Встреча нужна, чтобы:

Провести обзор того, что сделано и что будет.
Убедиться, что мы друг друга понимаем.

A10. Направить фокусированную коммуникацию

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

В этой же рассылке прописываем сроки, когда приступаем к работе, и добавляем контакты для связи.

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

B01. Обновить и детализировать планы

Тут всё по канонам P3.express. Мы приоритизируем задачи по методу MoSCow (must-have — обязательно должно быть сделано; should-have — должно быть сделано; could-have — могло бы быть сделано; won't-have — не должно быть сделано).

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

B02. Провести ежемесячное ревью

У нас это статус-отчёт по проекту.

<p><span>Сводный документ топов. Далее — детальный отчёт</span></p>

P3.express рекомендует для разных групп стейкхолдеров разные отчёты. Мы готовим несколько статус-отчётов:

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

B03. Решить «Go/No-Go»

После того как отправили статус-отчёт заказчику и спонсору, мы проводим с ними стартовую встречу. Обсуждаем проблемы и открытые вопросы, а также в целом состояние проекта.

Это отличный шаг, чтобы решить судьбу проекта.

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

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

B04. Провести стартовую встречу цикла

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

B05. Направить фокусированную коммуникацию

Мы направляем две фокусированные коммуникации на этом шаге.

Заказчику и всем стейкхолдерам: с протоколом обсуждения статус-отчёта, с таймингом, расшифровкой и ключевыми решениями.
Для команды во внутренний чат: с зафиксированными решениями и планам на цикл.

C01. Оценить и зафиксировать прогресс

На этом шаге я как проджект-менеджер проверяю таск-трекер, смотрю на затраченное время, бюджеты проекта, отслеживаю возможные проблемы и риски.

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

У нас в таск-трекере есть поля:

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

Прогнозируемая дата — когда исполнитель задачи рассчитывает её завершить. Эту дату ставит сам исполнитель.

Пример «на пальцах»:

Я как ПМ согласовал с командой и заказчиком, что задача будет готова к 01.06 — это плановая дата.
Разработчик, ответственный за задачу, решил, что сделает ее к 31.05. Это его прогнозируемая дата.
Но вдруг разработчик приболел и понял, что не может уложиться в срок. Он сдвигает прогнозируемую дату 2 рабочих дня — до 05.06.
В итоге мы имеем плановую дату (согласованную с клиентом) — 01.06, и прогнозируемую дату выполнения задачи от разработчика — 05.06. Отклонение равно -2 рабочих дня
Для меня, как проджекта, при своевременном реагировании это может помочь привлечь ресурсы, перераспределить задачи или пересогласовать дату с заказчиком.

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

На текущем этапе менеджер готовится к планированию спринта либо рано утром в понедельник, либо после ретро в пятницу.

C02. Реагировать на отклонения

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

Вкратце процесс выглядит так: выявили отклонения после первого шага → занесли в реестр рисков → выбрали стратегию реагирования → и выработали возможные пути решения.

C03. Провести еженедельную встречу

Спринт длится неделю и начинается в понедельник около 11:00, чтобы все успели проснуться и пробежаться по задачам. Мы расширенно планируем задачи и загрузку команды, отмечаем, что сделал разработчик, тестировщик, какие возникли проблемы. Это как расширенное дейли.

C04. Направить фокусированную коммуникацию

По итогам планирования спринта актуализируем или заводим новые карточки задач в таск-трекере, информируем команду в общем чате.

D01. Управлять рисками, проблемами и запросами на изменения

Менеджер проекта следит за всеми метриками в трекере. Плюс каждый день перед дейли участники пишут в специальные чаты информацию по трём пунктам (элемент Scrum-методологии):

что сделал вчера;
что планируешь сегодня;
что может помешать (риски).

Как это работает?

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

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

D02. Принять результаты работы

Здесь идёт совместная работа менеджера проекта, аналитика и тестировщика.

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

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

Ещё одно важное правило: мы не ждём какой-то даты X, чтобы презентовать апдейт. Как только разработчик сказал, что всё готово, подключаются тестировщик и аналитик.

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

Если проект завершился в 1 этап, то мы пропускаем закрытие цикла и сразу переходим к закрытию проекта.

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

<p>Так с помощью диаграммы разбирали, почему не ведём базу знаний</p>

Какие это могут быть вопросы:

Почему не сделали часть функционала по какому-то блоку?
Почему не заполняли таск-трекер заказчика?
Почему не вели базу знаний?

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

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

F01. Передать продукт
F02. Оценить удовлетворённость стейкхолдеров
F03. Сделать ревью этапа закрытия
F04. Заархивировать проектную документацию

Эти шаги у нас объединены. Когда проект идёт к закрытию, я начинаю опрашивать стейкхолдеров: насколько он соответствует ожиданиям. Часто клиенту необходимо объяснить, почему всё работает так, а не иначе.

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

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

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

F05. Отметить окончание проекта

Суперважный этап в работе команды. Я стараюсь звать ребят к себе в гости либо собирать всех на природу, в парк в тёплое время года. Чтобы они отдохнули, разгрузились и поделились обратной связью в неформальной обстановке.

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

F06. Направить фокусированную коммуникацию

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

После такого отдыха начинаем готовится к новым проектам. Например, наш разработчик год трудился фултайм, а потом пошёл в отпуск. Когда вернулся, мы неделю ставили ему ненапряжные задачки, чтобы ввести в проект.

G01. Оценить полученные выгоды
G02. Сгенерировать новые идеи
G03. Направить фокусированную коммуникацию

Пункты «Завершение проекта» и «После проекта» зацикливаются до следующего проекта. Всё это время мы следим за ним, получаем обратную связь от заказчика, оказываем техподдержку при необходимости. Также собираем аналитику по тому, насколько эффективно работает то, что мы создали.

Так клиент видит выгоду от проекта. И это аргумент в пользу дальнейшей работы с нами.

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

Нам важно, чтобы клиенты оставались с нами надолго. Мы не про «сделали проект, передали и скрылись», а про «доработали, сопроводили на всех этапах, поддержали и приступили к новым проектам заказчика».

Хочу такой же системный подход

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

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

PMCLUB — онлайн-школа для менеджеров проектов и продуктов. Мы учим управлять командой и не срывать дедлайны, правильно оценивать сроки, риски и бюджет. Подписывайтесь на нас на vc.ru и в Telegram.

#управлениепроектами #менеджмент #p3express