PMsoop: Глава №31: Завершение проекта – взгляд изнутри

В ролях - Менеджер Проекта, команда проекта

Артефакты – по необходимости

Суть – финальный разбор полётов и завершение проекта для разработчиков

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

Если коротко, сделать нужно следующее:

1. Провести финальный «разбор полётов», оценить вклад каждого сотрудника в проекте, наградить непричастных и наказать невиновных

2. Зафиксировать все результаты проекта – сложить вместе все артефакты и дополнительную информацию, и сохранить на всякий случай для потомков в защищённом хранилище

3. По результатам проекта составить сводное резюме Заказчика – описать его психологический портрет, сильные и слабые стороны (с точки зрения разработки ПО), другие нюансы – всю информацию, которая может оказаться полезной в случае, если этот Заказчик обратится к Разработчику с новым проектом

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

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

Сделать всё это удобно следующим образом:

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

a. Изначальные требования проекта

b. Реальные требования проекта + дефекты + ченджи, по которым велась работа (при использовании Jira можно сделать экспорт всех тасков, дефектов и ченджей)

c. План проекта – изначальный и финальный (лучше сохранить обе версии, для сравнения)

d. Исходный код проекта (SVN dump, c учётом всех brunch’ей и trunk’ов)

e. Техническая документация – всё что есть

f. Переписка по проекту и логи общения с Заказчиком

g. Спецификация сред проекта

h. Сценарии тестирования и тест-планы

2. Менеджер проекта собирает информацию и утверждает возможные меры (поощрения/наказания) для «разбора полётов»

3. Назначаем собрание с участием всей команды проекта, темы собрания:

a. Сверка списка артефактов, подлежащих хранению

b. Разбор полётов и раздача слонов

c. Составление резюме Заказчика

4. На собрании, после выполнения п.а. и b. проводим опрос сотрудников – просим дать свою характеристику Заказчику. Важно услышать мнение всех сотрудников, в том числе тех кто с Заказчиком не общался. Комментарии по качеству поступающих требований, срокам получения ответа на заданные вопросы, формулировке дефектов – всё это будет полезным. Полученную информацию фиксируем.

5. Назначаем ответственного за сбор и сохранение технических артефактов.

6. В конце собрания объявляем о завершении проекта. Можно сразу сообщить, кто из сотрудников может быть задействован для исправления дефектов и реализации ченджей, а кто уже свободен (если с этим вопросом всё уже понятно).

7. После собрания менеджер проекта составляет резюме (портрет) Заказчика, основываясь на своём опыте и отзывах участника проекта.

8. Сохраняет все артефакты проекта (согласно списка) установленным (принятым в Компании) образом

9. Готовит и отправляет общий отчёт для руководства

10. Ощущает удовлетворение от проделанной работы и хорошо выполненного проекта J

Немного подробнее остановимся на п.6. В большинстве случаев необходимые дополнительные трудозатраты менеджер проекта может оценить самостоятельно – руководствуясь знанием данного Заказчика и особенностей проекта. Исходя из оценки трудозатрат и знания проектной команды также можно «прикинуть» кто из сотрудников лучше справится с этими работами (исправление дефектов в течение периода поддержки, реализация ченджей потом). После чего, составленный приблизительный план рекомендуется обсудить и утвердить с руководством Компании и начальниками отделов, в которых числятся указанные товарищи. Чтобы потом не было ситуаций, когда нужный сотрудник уже на 100% задействован в других задачах, а тут срочные багфиксы пришли. Избежать таких ситуаций полностью удаётся редко, но приложить все усилия для их минимизации однозначно стоит. И делать это лучше ещё до финального собрания с командой проекта.

Ну и, напоследок, снова о «тёмной» стороне. Для менеджера проекта по завершению проекта очень важно и полезно получить отзыв о своей работе, причём от всех участвующих сторон, которыми являются:

1. Команда проекта

2. Заказчик

3. Руководство Компании

Как это сделать? Например, где-то так:

1. На финальном собрании, после составления резюме по Заказчику, можно попросить участников проекта дать характеристику своей работе. Такой вариант подходит в случае весьма «тёплых» и открытых отношений в команде. Если есть риск, что обуждение сведется к ругани, либо народ просто не выскажет то, что думает на самом деле – можно поступить другим образом. После собрания можно разослать сотрудникам краткий «опросник», в котором попросить оценить качество работы МП по различным критериям. Можно опрос сделать анонимным. Кстати, в хороших Компаниях такой опросник и оценка работы менеджера по результатам проекта может являться стандартной практикой

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

3. В идеале, руководство само вызовет вас «на ковер» и сделает с вами то же, что вы сделали с сотрудниками на финальном разборе полётов J Руководствуясь при этом сводным отчётом по проекту, отзывами сотрудников и Заказчика. Это в идеале, конечно. Если что-то подобное в вашей Компании не принято – не стесняйтесь обратиться за оценкой своей работы самостоятельно.

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

The End.