Bonus eventus
Ранее я писал статью о выводе продукта из эксплуатации. Да и о постмортемах писал. Давайте поговорим предметно и системно о завершении проекта, составим что-то вроде чек-листа того, что нужно сделать.
Но перед этим спросим у ясеня.
Грок о завершении проекта
Что самое важное в завершении проекта?
Завершение проекта — это критический этап, который требует тщательной организации, чтобы закрепить результаты и извлечь уроки. Самое важное — обеспечить выполнение всех целей и требований, оговорённых на этапе инициации. Это включает финальную сдачу продукта заказчику, проверку соответствия KPI и бизнес-целям, а также подписание всех закрывающих документов (актов, отчётов). Не менее значимо провести финальное тестирование, чтобы убедиться, что продукт работает без сбоев, и передать его в поддержку или эксплуатацию с чёткой документацией. Успешное завершение подтверждает, что проект достиг своей ценности для стейкхолдеров.
Второй ключевой аспект — управление стейкхолдерами и коммуникация. На этапе завершения важно собрать обратную связь от всех заинтересованных сторон: заказчиков, команды, пользователей. Это помогает оценить удовлетворённость результатом и выявить недочёты. Проведение финального собрания (closure meeting) позволяет обсудить успехи, проблемы и уроки, а также поблагодарить команду за вклад. Чёткое информирование всех сторон о завершении проекта и его итогах предотвращает недопонимание и укрепляет доверие к команде. Кроме того, необходимо закрыть все контракты с подрядчиками и убедиться, что финансовые обязательства выполнены.
Наконец, анализ и документирование опыта — залог будущих успехов. После завершения проекта важно провести ретроспективу, чтобы зафиксировать, что прошло хорошо, а что требует улучшения. Это включает анализ рисков, сроков, бюджета и эффективности процессов. Создание финального отчёта и архивация всех проектных материалов (планов, переписки, артефактов) облегчит доступ к информации для будущих проектов. Уроки, извлечённые на этом этапе, помогут избежать повторения ошибок и повысить качество управления проектами в будущем, делая завершение не просто формальностью, а ценным вкладом в развитие команды и организации.
А теперь разбор темы от живого пиэма.
Проверка содержимого таск-трекера
Не знаю, как у вас, а у меня зудит, когда проект, вроде как, завершён, но в таск-трекере по нему есть какие-то незакрытые задачи, которые маячат в отчётах и дашбордах и по которым то ли ведутся работы, то ли нет, ничего непонятно.
В общем, первым делом проводим ревизию незакрытых задач, добиваем недобитое, закрываем и киляем неактуальное. Может выясниться, что проект на самом деле, не завершён и вы недоделали часть задач. Лучше так, чем если это выявит клиент.
Сверка результатов работы с заказчиком
Нужно пройтись с заказчиком по бэклогу и убедиться, что он всё принял. Предполагается, что приёмо-сдаточные испытания вы уже провели и всё хорошо. Проверка нужна, чтобы точно убедиться, что ничего не забыли.
Потом начинаем самую неприятную часть работы пиэма — разборки с документами. Надо убедиться, что заказчику отправлены все закрывающие документы и он их получил.
Дожимаем подписание этих документов. Вообще, в нормальной компании должен быть аккаунт-менеджер, который этим занимается, но если его нет, это ваша работа. Эта работа очень важна, её нельзя делать «на отвали».
Итоговый анализ метрик
Нужно сверить плановые показатели проекта с фактическими и аргументированно прийти к выводу, насколько успешен проект в чиселках. Я понимаю, главное мерило — удовлетворённость заказчика и его желание работать с нами дальше, но чиселки очень важны для руководства проектного офиса.
Командные метрики:
- Загрузка ресурсов: насколько верно вы оцениваете проект, как часто случаются (или нет) переработки и т. п.
- Velocity (используется при работе по agile) — показывает, какой объём работы команда может стабильно выполнять за один спринт.
- Количество ревью/правок — показывает, насколько хороша ваша команда по нескольким пунктам: качество выполнения задач разработчиками, качество постановки задач менеджером, качество работы тестировщиков.
Метрики по методологии DORA:
- Частота деплоев (Deploy Frequency) — показывает, насколько часто мы доставляли изменения до конечного юзера.
- Время доставки изменений (Lead Time for Changes) — отражает скорость прохождения кода от разработчика до пользователя.
Качественные:
- Удовлетворенность команды
- Удовлетворенность клиента (NPS)
Финасовые показатели. P&L-ка вам в помощь.
Организация обучения сотрудников заказчика
Обычно в стоимость проекта добавляют передачу заказчику знаний о продукте. Чаще всего этим занимаются менеджеры отдела внедрения ПО, но могут повесить и на вас. Давайте думать, что тут нужно.
Базово есть такие варианты обучения:
- Встреча на 1-2 часа с демонстрацией экрана и рассказом о системе;
- Презентация в PDF с описанием системы и порядка работы с ней;
- Скринкасты с основными сценариями использования системы;
- Тест-драйв системы с поддержкой от команды разработки;
- Интерактивный воркшоп — может занимать от 3 часов до целого рабочего дня;
- и др.
Если продукт простенький, может хватить pdf-презентации. Но использованию более крупных систем надо обучать.
Если про обучение при планировании проекта забыли, можно предложить его заказчику как дополнительную опцию.
Благодарность клиенту за сотрудничество
Если есть возможность, лучше съездить в офис заказчика лично. Нет такой возможности — проведите созвон, напишите имейл с благодарностью.
«Систех» обожает привлекать специалистов заказчика для пиар-активностей, чтобы они рассказывали другим действующим и потенциальным заказчикам о своих кейсах. Хорошая практика. Пиарщики вам в этом помогут.
Запрос подробной обратной связи
Клиент может не высказывать вам все моменты в процессе общения. А эти моменты могут оказаться важны для улучшения вашей работы.
Договоритесь с клиентом, что он даст ОС, составьте опросник, зашлите ему. Можете добавить туда пункты:
- Удовлетворенность процессом;
- Удовлетворенность результатом;
- Удовлетворенность коммуникацией;
- Что понравилось в работе с нами;
- Что можно улучшить;
- Готовность рекомендовать нас.
Предложение развития проекта
Проявите проактивность. Предложите клиенту идеи по развитию проекта, новым фичам для ПО, новым процессам. Это добавит вам очков в глазах заказчика, а может быть, принесёт новый проект и дополнительные деньги компании. Вы же хотите, чтобы вашему гендиру хватало на самую последнюю модель Бентли, не так ли?
Ретроспектива
Члены команды могут донести до вас важную информацию по выученным урокам на проекте. Обязательно нужно провести ретроспективу.
Ретро проходит в двух форматах:
- С командой проекта — обговорить с членами команды, что было хорошего, что было плохого, какие выученные уроки. Зафиксировать, записать, принять к исполнению.
- С менеджерами — поговорить с коллегами-прожектами, рассказать, что было на проекте, дать советы им, послушать их советы.
Открытая дверь для клиента
Вы должны качественно и грамотно заархивировать все проектные артефакты на случай, если заказчик придёт снова, чтобы вы смогли быстро стартовать. Это хорошо, это профессионализм.
