Привет, Хабр! Я — Вера Осолодкина, аккаунт-директор в диджитал-продакшене Далее. Сегодня рассказываю о том, как удачно финалить проекты и спать себе спокойно, а еще делюсь своим чек-листом в конце статьи.

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

Разберем, из чего состоит этот процесс.

#1. Проверям статус задач

Смотрим в своей системе управления, например, в Jira, что все в таск-менеджере завершено.

Если какие-то задачи остались открытыми, то разбираемся, ведутся ли по ним финальные работы или нет. Вполне возможно, что их просто не успели перенести в закрытые — все выясняем и наводим порядок для отчетности. Иногда на этом этапе выясняется, что остались несделанные задачи. Гораздо лучше, если первыми их обнаружите вы, а не клиент.

#2. Сверяем работы с заказчиком

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

Подтверждаем актами и отчетами, что все выполнено в полном объеме согласно договору. Уточняем, нужно ли заказчику что-то еще для приема проекта. И помним, что все документы должны быть подписаны. В контексте наших внутренних процессов мы также фиксируем не только даты отправки документов, но и их подписания, а также оплаты. Важно не бросать работу с документами и не выполнять ее на уровне «лишь бы отделаться». В ваших внутренних таблицах с реализацией должны быть указаны все важные даты. Для любого продакшена очень важно иметь такую информацию на руках.

#3. Анализируем метрики проекта

Сравниваем целевые и фактические показатели проекта. Если есть отклонения от целей, фиксируем это для ретро.

Приведу наш более-менее стандартный набор метрик, за которыми мы следим:

Командные метрики:

Загрузка ресурсов: насколько верно вы оцениваете проект, как часто случаются (или нет) переработки и т.п.
Velocity (используется при работе по agile) — показывает, какой объем работы команда может стабильно выполнять за один спринт.
Количество ревью/правок — показывает, насколько хороша ваша команда по нескольким пунктам: качество выполнения задач разработчиками, качество постановки задач менеджером, качество работы тестировщиков.

Метрики по методологии DORA:

Частота деплоев (Deploy Frequency) — показывает, насколько часто мы доставляли изменения до конечного юзера.
Время доставки изменений (Lead Time for Changes) — отражает скорость прохождения кода от разработчика до пользователя.

Качественные:

Удовлетворенность команды
Удовлетворенность клиента (NPS)

Финасовые показатели.

Метрики самого продукта. Тут можно долго обсуждать, поэтому подробностей не привожу. Слишком объемная тема, которая тянет на целый отдельный материала.

#4. Обучаем сотрудников клиента

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

Сайты, маркетплейсы, CRM или ERP — все это администрируется или используется сотрудниками ежедневно. Базово есть такие варианты обучения:

Встреча на 1-2 часа с передачей информации;
Презентация в PDF с описанием системы и порядка работы с ней;
Видео-туториалы;
Тест-драйв системы с поддержкой от команды разработки;
Интерактивный воркшоп — может занимать от 3 часов до целого рабочего дня;
и др.

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

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

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

#5. Благодарим за сотрудничество

Сказать клиенту «спасибо» — вполне естественно, ведь он центральный участник проекта и тот, кто доверил вам свой продукт.

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

И не забывайте о PR-активностях: публикации в СМИ о проекте, награды на отраслевых премиях — всем этим надо делиться с клиентом и всячески его вовлекать.

#6. Запрашиваем ОС

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

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

Удовлетворенность процессом
Удовлетворенность результатом
Удовлетворенность коммуникацией
Что понравилось в работе с нами
Что можно улучшить
Готовность рекомендовать нас

Будет лучше, если обратную связь вам дадут в письменном виде.

#7. Предлагаем зоны роста проекта

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

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

#8. Проводим ретроспективу

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

Ретро проходит в двух форматах:

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

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

Главное в финале любого проекта — оставить клиенту открытую дверь для сотрудничества

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

***

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

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

Как проджект-менеджеру грамотно завершать проекты по разработке