Передача проектов между менеджерами

Случаются ситуации, когда проект переходит от менеджера к другому менеджеру. Мне передавали проекты, я передавал проекты. Почти каждый раз оказывается, что что-то “недопередали”, и это становится проблемой.

Вот примерный план приемки-передачи проекта

По глобальным пунктам нас интересует

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

Описание клиента, история и характер взаимоотношений. Значение имеет общее отношения клиента к нам, бывшие конфликты, моменты которыми клиент не был доволен.

Со стороны клиента может быть несколько ответственных лиц. В крупных компаниях разные вопросы решают разные же специалисты.

В описании коллег из компании клиента можно описать, как происходит коммуникация — каналы, частота, особенности (например, еженедельные встречи).

Иван Петров, менеджер проекта, +7 911 1234567 :: ivan@somecompany.hk - К Ивану можно обращаться по любому вопросу и в непонятных ситуациях. Помогает разрулить задачи на стороне клиента.

В этом разделе описываем, кто участвует в проекте. Перечисляем специалистов с нашей стороны. Если в проекте задействованы третьи лица (менеджеры сервисов, например), их тоже желательно указать здесь же.

Илья Ильин, программист+7 965 1234567 :: телеграм: ilyacoder - Работает удаленно, часовой пояс — GMT+5. Занимается разработкой бэкэнда.

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

Вот чек-лист:

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

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

Вот, что нужно описать:

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

Рабочее пространство — то место, где происходит постановка и принятие задач. Это может быть доска трелло, проект в Jira или Redmine. В целом, файл должен содержать всю информацию, которая поможет новому менеджеру понять, что происходит в проекте.

Передачу проекта желательно проводить лично. В крайнем случае (например, при распределенности команды) — через скайпколл. Письмо с информацией отправляется вдогонку, как памятка. Второе письмо — письмо-знакомство, которое должен отправить предыдущий менеджер проекта. Оно короткое, и основная его суть, дать понять заказчику, что руководитель проекта меняется, но клиенту не о чем переживать, потому что новый проджект достаточно квалифицирован, а предыдущий остается на связи, и поможет если что.

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

P.S. Бонусом подготовил пример реального резюме передачи + бесплатный (!) шаблон резюме проекта в гуглдоке, который можешь скопировать себе, распечатать или заполнять прямо в онлайне. Если вдруг столкнулся с паттерном, который можно было бы добавить в такой шаблон — велком ко мне в личку телеграма, буду благодарен за комментарии.

А вот мой канал в телеграме, где нерегулярно появляются ссылки на новые статьи: t.me/zapostil/