Случаются ситуации, когда проект переходит от менеджера к другому менеджеру. Мне передавали проекты, я передавал проекты. Почти каждый раз оказывается, что что-то “недопередали”, и это становится проблемой. Особенно, если передавший менеджер покинул компанию, и ему нет никакого интереса возвращаться к этому вопросу. В итоге мы имеем кучу ненужной работы с разбором ситуации, недовольного клиента и стресс — свой и участников проекта.
Чтобы минимизировать этот риск, я собрал список контрольных вопросов. Он подходит проектам по веб-разработке, но при обработке напильником пригодится и в других типах проектов. Это не инструкция, а пример плана, на основании которого ты сможешь собрать собственный шаблон. Статья будет полезна тем, кто пишет такой документ — чтобы не забыть указать детали проекта. Также, принимающие могут взять процесс передачи под свой контроль и самостоятельно контролировать получение информации по этому списку.
Агенда передачи проекта
Вот примерный план приемки-передачи проекта
- Рассказать про проект, клиента и команду
- Добавить нового менеджера в рабочее пространство (Trello/Jira)
- Представить нового менеджера проекта клиенту
- Представить менеджера участникам проектной группы
- Отдать все имеющиеся контактные данные и детали
- Добавить во все чаты — внутренние и клиентские
- Передать последние значимые задачи и договоренности — особенно, если они не учтены в проектной документации
- Выслать файл с ревью информации по проекту (то, что заполняли выше)
По глобальным пунктам нас интересует
- Клиент (заказчик)
- Команда проекта
- Бюрократические отношения
- Детали по самому проекту
Клиент
В этом разделе описываем, что представляет из себя клиент. Информацию можно поделить на несколько блоков: рассказ о компании в целом, и о людях в отдельности.
Компания
Описание клиента, история и характер взаимоотношений. Значение имеет общее отношения клиента к нам, бывшие конфликты, моменты которыми клиент не был доволен. Особенно это важно, если проект передается не по причине ухода предыдущего менеджера проектов – в этом случае, его передача как раз и происходит по причине конфликта.
Люди
Со стороны клиента может быть несколько ответственных лиц. В крупных компаниях разные вопросы решают разные же специалисты. Здесь перечисляем всех, с кем придется коммуницировать. К информации о роли человека, добавляем контакты и все имеющиеся важные детали.
В описании коллег из компании клиента можно описать, как происходит коммуникация – каналы, частота, особенности (например, еженедельные встречи). Если существуют известные загоны (например, клиент требует особого к нему отношения или “отвечать в течении 10 минут”), об этом тоже нужно рассказать.
Иван Петров, менеджер проектов
+7 911 1234567 :: ivan@somecompany.hk
К Ивану можно обращаться по любому вопросу и в непонятных ситуациях. Помогает разрулить задачи на стороне клиента. Быстрее всего отвечает в телеграме, обычно доступен до 6 часов вечера.
Лидия Иванова, бухгалтер
lidia@somecompane.hk
Решает все вопросы, связанные с бухгалтерией и документами. Отвечает только по почте, в течении суток. Если ответа нет через двое суток после письма — можно маякнуть.
Команда проекта
В этом разделе описываем, кто участвует в проекте. Перечисляем специалистов с нашей стороны. Если в проекте задействованы третьи лица (менеджеры сервисов, например), их тоже желательно указать здесь же. По потребности указываем и контакты людей, которые участвовали в проекте ранее – если результаты их работы актуальны до сих пор.
Илья Ильин, программист
+7 965 1234567 :: телеграм: ilyacoder
Работает удаленно, часовой пояс — GMT+5. Занимается разработкой бэкэнда.
Андрей Сидоров, дизайнер
Телеграм: sidorov126 :: andrey@sidorov.hk
Алексей Иванов, бывший дизайнер проекта
Если требуется найти первые исходники дизайна – обращайся к нему.
Телеграм: alexey49 :: alexey@ivanovdesign.hk
Бюрократические вопросы
Сюда мы относим все вопросы по бухгалтерским и юридическим документам. В некоторых компаниях ты будешь с ними соприкасаться, даже если не занимаешься напрямую. Например, функции аккаунт-менеджера типа отправить документы и проконтролировать их получение. При приемке проекта в первую очередь нужно убедиться, что нет долгов по документам — в обе стороны.
Вот чек-лист:
- Проект time and material или fix-price?
- Оплачивали ли уже что-то за проект
- Какая сумма к оплате осталась, когда следует выставлять счета
- Есть ли документы, которые нужно отправить или получить от клиента
Из собственного опыта скажу, что все эти вопросы нужно сразу же забирать на себя. Предыдущий проджект так же быстро забудет про них, как забудет про проект в целом. Если не заберешь сразу — столкнешься с этими вопросами позже, когда они станут горящими. Как вариант — брать на контроль выполнение договоренностей с предыдущим менеджером. Но я не советую идти этим путем.
Проект
Может показаться, что это самый важный пункт, но я его сознательно увел в конец статьи, потому что вещи типа команды-клиента все же важнее. Плюс, проектов может быть несколько, а при передаче тебе все равно отдадут самую верхушку айсберга. Да и находясь уже в процессе, знакомство с проектом происходит эффективнее.
Вот, что нужно описать:
- Проект в целом — что должно получиться в результате
- Проектная документация — план проекта, техническое задание, резюме
- Статус проекта — степень выполнения
- Что делается сейчас — последние обещания клиенту
- Какая задача стоит перед менеджером — что нужно сделать, зачем ты здесь?
Последний момент важен. Твоя роль может быть как курирующая — когда сотрудники общаются с представителем клиента напрямую, и нужно вмешиваться только когда что-то идет не так. Может быть репрезентативная — когда тебе нужно выстроить отношения с клиентом. Случается и когда передают заведомо проблемный проект — здесь нужно выяснить, в чем проблемы (“клиенту не нравится, что ему долго отвечают”) и направить силы на исправление этого момента.
Параметры доступа
Нужно получить параметры доступа к фронту, к админ-панели, всем тестовым/боевым ссылкам, репозиториям и ко всем подключенным сервисам. В зависимости от ситуации, пароли изменяются или остаются прежними. Если руководитель проекта уходит из компании, желательно доступы менять (как, впрочем, при уходе любого из участников проекта). В остальных случаях руководствуясь ситуацией.
Рабочее пространство
Рабочее пространство — то место, где происходит постановка и принятие задач. Это может быть доска трелло, проект в Jira или Redmine. Если вся коммуникация велась через почту или скайп — будь готов к сюрпризам, когда проект передадут тебе. В случае с почтой, прививкой может стать пересылка последних значимых писем с договоренностями.
В целом, файл должен содержать всю информацию, которая поможет новому менеджеру понять, что происходит в проекте. Конечно, все перечислить нереально, но получить базовую информацию поможет. В конкретные задачи лучше при передаче не закапываться — они лучше понимаются уже в процессе.
Резюме передачи проекта
Передачу проекта желательно осуществлять лично. В крайнем случае (например, при распределенности команды) — через скайпколл. Письмо с информацией отправляется вдогонку, как памятка. Второе письмо — письмо-знакомство, которое должен отправить предыдущий менеджер проекта. Оно короткое, и основная его суть, дать понять заказчику, что руководитель проекта меняется, но клиенту не о чем переживать, потому что новый проджект достаточно квалифицирован, а предыдущий остается на связи, и поможет если что. Не так прямо конечно, но в целом задача — дать понимание того, что все окей. Разумеется, в конфликтных ситуациях это письмо пишется немного иначе. При конфликте можно подключать ресурс в виде руководства организации, но это уже другая история.
При приемке проекта управляй процессом. Ты — проджект, и твоя роль вступает в действие еще до того, как тебе его передали полностью. Фасилитируй процесс, не давай уводить разговор в праздную беседу без выполнения финальной точки — это самая большая проблема, с которой я сталкивался и сталкиваюсь фактически при каждой передаче проекта. Составление резюме передачи проекта не так сложно, а польза, полученная от грамотной передачи проекта сэкономит с десяток человеко-часов, потраченных на прояснение базовых деталей в процессе. Как бы предыдущий проджект не обещал, что будет в процессе какое-то время, он так или иначе убежит решать свои задачи. Опять же, проект передают либо из-за загруженности менеджера, либо из-за проблем, возникших в процессе работы. Если руководитель проекта увольняется — здесь сценарий тоже вполне себе предсказуем.
P.S. Бонусом подготовил пример реального резюме передачи + бесплатный (!) шаблон резюме проекта в гуглдоке, который можешь скопировать себе, распечатать или заполнять прямо в онлайне. Он универсальный, потому не воспринимай его как директивный чек-лист, добавляя или удаляя свое. Надеюсь, документ тебе пригодится. А если вдруг столкнулся с паттерном, который можно было бы добавить в такой шаблон — велком ко мне в личку телеграма, буду благодарен за комментарии.
