Случаются ситуации, когда проект переходит от менеджера к другому менеджеру. Мне передавали проекты, я передавал проекты. Почти каждый раз оказывается, что что-то “недопередали”, и это становится проблемой. Особенно, если передавший менеджер покинул компанию, и ему нет никакого интереса возвращаться к этому вопросу. В итоге мы имеем кучу ненужной работы с разбором ситуации, недовольного клиента и стресс — свой и участников проекта.
Чтобы минимизировать этот риск, я собрал список контрольных вопросов. Он подходит проектам по веб-разработке, но при обработке напильником пригодится и в других типах проектов. Это не инструкция, а пример плана, на основании которого ты сможешь собрать собственный шаблон. Статья будет полезна тем, кто пишет такой документ — чтобы не забыть указать детали проекта. Также, принимающие могут взять процесс передачи под свой контроль и самостоятельно контролировать получение информации по этому списку.
Попытка не пытка! Европа пытается со скрежетом нарастить производство для Украины | AfterShock.news
Агенда передачи проекта
Вот примерный план приемки-передачи проекта
- Рассказать про проект, клиента и команду
- Добавить нового менеджера в рабочее пространство (Trello/Jira)
- Представить нового менеджера проекта клиенту
- Представить менеджера участникам проектной группы
- Отдать все имеющиеся контактные данные и детали
- Добавить во все чаты — внутренние и клиентские
- Передать последние значимые задачи и договоренности — особенно , если они не учтены в проектной документации
- Выслать файл с ревью информации по проекту (то, что заполняли выше)
По глобальным пунктам нас интересует
- Клиент (заказчик)
- Команда проекта
- Бюрократические отношения
- Детали по самому проекту
Клиент
В этом разделе описываем, что представляет из себя клиент. Информацию можно поделить на несколько блоков: рассказ о компании в целом, и о людях в отдельности.
Компания
Описание клиента, история и характер взаимоотношений. Значение имеет общее отношения клиента к нам, бывшие конфликты, моменты которыми клиент не был доволен. Особенно это важно, если проект передается не по причине ухода предыдущего менеджера проектов – в этом случае, его передача как раз и происходит по причине конфликта.
Со стороны клиента может быть несколько ответственных лиц. В крупных компаниях разные вопросы решают разные же специалисты. Здесь перечисляем всех, с кем придется коммуницировать. К информации о роли человека, добавляем контакты и все имеющиеся важные детали.
В описании коллег из компании клиента можно описать, как происходит коммуникация – каналы, частота, особенности (например, еженедельные встречи). Если существуют известные загоны (например, клиент требует особого к нему отношения или “отвечать в течении 10 минут”), об этом тоже нужно рассказать.
Как проверить качество проекта? Алгоритм проверки проектной документации.
Иван Петров, менеджер проектов
К Ивану можно обращаться по любому вопросу и в непонятных ситуациях. Помогает разрулить задачи на стороне клиента. Быстрее всего отвечает в телеграме, обычно доступен до 6 часов вечера.
Лидия Иванова, бухгалтер
Решает все вопросы, связанные с бухгалтерией и документами. Отвечает только по почте, в течении суток. Если ответа нет через двое суток после письма — можно маякнуть.
Команда проекта
В этом разделе описываем, кто участвует в проекте. Перечисляем специалистов с нашей стороны. Если в проекте задействованы третьи лица (менеджеры сервисов, например), их тоже желательно указать здесь же. По потребности указываем и контакты людей, которые участвовали в проекте ранее – если результаты их работы актуальны до сих пор.
Илья Ильин, программист
+7 965 1234567 :: телеграм: ilyacoder
Работает удаленно, часовой пояс — GMT+5. Занимается разработкой бэкэнда.
Андрей Сидоров, дизайнер
Алексей Иванов, бывший дизайнер проекта
Если требуется найти первые исходники дизайна – обращайся к нему.
Бюрократические вопросы
Сюда мы относим все вопросы по бухгалтерским и юридическим документам. В некоторых компаниях ты будешь с ними соприкасаться, даже если не занимаешься напрямую. Например, функции аккаунт-менеджера типа отправить документы и проконтролировать их получение. При приемке проекта в первую очередь нужно убедиться, что нет долгов по документам — в обе стороны.
- Проект time and material или fix-price?
- Оплачивали ли уже что-то за проект
- Какая сумма к оплате осталась, когда следует выставлять счета
- Есть ли документы, которые нужно отправить или получить от клиента
Из собственного опыта скажу, что все эти вопросы нужно сразу же забирать на себя. Предыдущий проджект так же быстро забудет про них, как забудет про проект в целом. Если не заберешь сразу — столкнешься с этими вопросами позже, когда они станут горящими. Как вариант — брать на контроль выполнение договоренностей с предыдущим менеджером. Но я не советую идти этим путем.
Проект
Может показаться, что это самый важный пункт, но я его сознательно увел в конец статьи, потому что вещи типа команды-клиента все же важнее. Плюс, проектов может быть несколько, а при передаче тебе все равно отдадут самую верхушку айсберга. Да и находясь уже в процессе, знакомство с проектом происходит эффективнее.
Вот, что нужно описать:
- Проект в целом — что должно получиться в результате
- Проектная документация — план проекта, техническое задание, резюме
- Статус проекта — степень выполнения
- Что делается сейчас — последние обещания клиенту
- Какая задача стоит перед менеджером — что нужно сделать, зачем ты здесь ?
Последний момент важен. Твоя роль может быть как курирующая — когда сотрудники общаются с представителем клиента напрямую, и нужно вмешиваться только когда что-то идет не так. Может быть репрезентативная — когда тебе нужно выстроить отношения с клиентом. Случается и когда передают заведомо проблемный проект — здесь нужно выяснить, в чем проблемы (“клиенту не нравится, что ему долго отвечают”) и направить силы на исправление этого момента.
Параметры доступа
Нужно получить параметры доступа к фронту, к админ-панели, всем тестовым/боевым ссылкам, репозиториям и ко всем подключенным сервисам. В зависимости от ситуации, пароли изменяются или остаются прежними. Если руководитель проекта уходит из компании, желательно доступы менять (как, впрочем, при уходе любого из участников проекта). В остальных случаях руководствуясь ситуацией.
Рабочее пространство
Рабочее пространство — то место, где происходит постановка и принятие задач. Это может быть доска трелло, проект в Jira или Redmine. Если вся коммуникация велась через почту или скайп — будь готов к сюрпризам, когда проект передадут тебе. В случае с почтой, прививкой может стать пересылка последних значимых писем с договоренностями.
В целом, файл должен содержать всю информацию, которая поможет новому менеджеру понять, что происходит в проекте. Конечно, все перечислить нереально, но получить базовую информацию поможет. В конкретные задачи лучше при передаче не закапываться — они лучше понимаются уже в процессе.
Резюме передачи проекта
Передачу проекта желательно осуществлять лично. В крайнем случае (например, при распределенности команды) — через скайпколл. Письмо с информацией отправляется вдогонку, как памятка. Второе письмо — письмо-знакомство, которое должен отправить предыдущий менеджер проекта.
Оно короткое, и основная его суть, дать понять заказчику, что руководитель проекта меняется, но клиенту не о чем переживать, потому что новый проджект достаточно квалифицирован, а предыдущий остается на связи, и поможет если что. Не так прямо конечно, но в целом задача — дать понимание того, что все окей. Разумеется, в конфликтных ситуациях это письмо пишется немного иначе. При конфликте можно подключать ресурс в виде руководства организации, но это уже другая история.
При приемке проекта управляй процессом. Ты — проджект, и твоя роль вступает в действие еще до того, как тебе его передали полностью. Фасилитируй процесс, не давай уводить разговор в праздную беседу без выполнения финальной точки — это самая большая проблема, с которой я сталкивался и сталкиваюсь фактически при каждой передаче проекта.
Составление резюме передачи проекта не так сложно, а польза, полученная от грамотной передачи проекта сэкономит с десяток человеко-часов, потраченных на прояснение базовых деталей в процессе. Как бы предыдущий проджект не обещал, что будет в процессе какое-то время, он так или иначе убежит решать свои задачи. Опять же, проект передают либо из-за загруженности менеджера, либо из-за проблем, возникших в процессе работы. Если руководитель проекта увольняется — здесь сценарий тоже вполне себе предсказуем.
P.S. Бонусом подготовил пример реального резюме передачи + бесплатный (!) шаблон резюме проекта в гуглдоке , который можешь скопировать себе, распечатать или заполнять прямо в онлайне. Он универсальный, потому не воспринимай его как директивный чек-лист, добавляя или удаляя свое. Надеюсь, документ тебе пригодится. А если вдруг столкнулся с паттерном, который можно было бы добавить в такой шаблон — велком ко мне в личку телеграма, буду благодарен за комментарии.
Источник: salakhmir.ru
Передача проекта в строительстве
При передаче проекта от аккаунт-менеджера к менеджеру проектов что-то нет-нет да потеряется. И как с этим жить студии и заказчику?
Разработка сайта — не тот случай, когда товар можно посмотреть, покрутить и положить в карман. Поэтому у нас есть аккаунт-менеджер, который выясняет пожелания потенциальных заказчиков, оценивает стоимость и сложность их хотелок и, по сути, продаёт услуги студии.
Сразу ремарка — мы понимаем под аккаунт-менеджером человека, который доводит проект до продажи, хотя в других компаниях его функции могут отличаться.
Аккаунт-менеджер прощупывает заказчиков от кепочки до шнурков, выясняя серьёзность их намерений и выпытывая каждую мелочь будущего проекта. Обсуждение сайта или приложения может длиться месяцами. И чем дольше, тем обиднее, когда при передаче проекта от аккаунт-менеждера к менеджеру, который рулит разработкой, теряется часть информации.
Когда заказчик слышит от руководителя проектов вопросы, на которые точно отвечал аккаунт-менеджеру пару месяцев назад, в нём начинают шевелиться неприятные мысли. «А в этой студии люди друг с другом совсем не общаются? А аккаунт-менеджер вообще ничего не рассказал менеджеру проектов?! Мне теперь что, всё сначала объяснять. 11!» — и другие вопросы с налётом паники грызут его.
Но вот печальная правда жизни — невозможно передать менеджеру проектов ВСЮ информацию, которую получил аккаунт-менеджер во время общения с заказчиком. Мы не умеем перекидывать данные из головы одного человека в голову другого, как через облачное хранилище. Что-то наверняка потеряется — это естественная погрешность при таких объёмах информации. И с этим фактом нужно уметь жить.
1. Аккаунт-менеджер собирает всю информацию по проекту. Прямо всю. Отчеты, резюме встреч, файлики от заказчика, визуальные материалы, брендбуки, выгрузки, чеклисты по выгрузкам и т.д. И складывает в папку проекта.
2. Аккаунт-менеджер составляет файл передачи. Фиксирует в нём, что где хранится. Где лежат договоры и приложения, смета и контакты заказчика. Вспоминает и описывает нюансы проекта.
3. Аккаунт-менеджер передаёт файл менеджеру проекта. Назначает дату и время разговора — пока внутри студии, без участия заказчика.
4. Вместе с менеджером обсуждают голосом все вопросы по проекту, отсекают те, которые уже были рассмотрены с клиентом.
5. Аккаунт-менеджер, менеджер проекта и заказчик созваниваются вместе, чтобы обсудить оставшиеся вопросы и уточнить нюансы.
Важная часть передачи — правильно представить заказчику менеджера проекта. Рассказать о его достижениях и плюсах для проекта заказчика без слащавых комплиментов и вранья. Клиент должен понимать, что попал в надёжные руки.
Наши аккаунт-менеджеры представляют руководителей проектов так:
Екатерина — эксперт в области продюсирования сайтов корпоративного сегмента и интернет-коммерции. Она вела такие проекты, как Dadim, Молочная культура и Ralf Ringer.
Во время разговора аккаунт-менеджер фиксирует результаты разговора в «Дневнике проекта» (файл, где кроме этого хранятся смета, таймлайн и график выплат).
Но даже записи переговоров и аккуратно собранные по папочкам документы не гарантируют, что какие-то детали не потерялись при передаче. Поэтому второй этап работы с проблемой — примирить с ней заказчика.
Для этого в последней редакции чеклиста по передаче проектов мы добавили большой и жирный комментарий, который нужно проговаривать клиентам:
«Может возникнуть ситуация, что на эти вопросы вы уже отвечали. И это нормально. Часть информации при передаче может теряться».
Чтобы при этом исключить манипуляции типа «А вот аккаунт-менеджер полгода назад обещал мне, что на сайте будет секретная страничка на 100500 уровне. Наверное, эта информация потерялась при передаче — сделайте всё равно», — после передачи проекта менеджер равняется чётко на смету. Что там написано, то и предполагается в проекте. Для идеального взаимопонимания заказчик, аккаунт-менеджер и руководитель проекта обсуждают смету вместе — так у всех сторон появится единое представление проекта.
И чтобы отследить детали, которые могли действительно потеряться, мы дотошно готовим агрегацию требований. Если в ней появилось то, чего нет в смете — актуализируем.
Тем, кто только изучает науку управления проектами, рекомендую потренироваться с фразой «За это вы не платили» — нужно научиться говорить её так, чтобы не обижать клиента и не вызывать негативных эмоций.
А также максимально прокачать навык активного слушания, но не на уровне «угу-ага», а на уровне понимания сути сказанного клиентом и эмоций, которые он вложил в слова или в молчание.
Так что сначала нужно смириться, что потери будут. А потом — минимизировать их. С теми, кто хочет уменьшить негатив и потерянные данные при передаче проектов, делимся нашим чеклистом.
1. Все документы (договор, приложения, счета) сохранены на Google Диск в папке «Проекты» у того менеджера, который прописан в договоре и ведёт проект.
2. Коммуникации на этапе пресейла зафиксированы в резюме и постоянно отправляются на email заказчику. Аккаунт-менеджер должен быть готов по запросу менеджера скинуть всю переписку или дать ссылку на записи переговоров (а также презентации смет, информацию о встречах, промежуточных обсуждениях).
3. В папке «Проекты» создана папка с названием проекта. В ней — файл-таблица «Дневник проекта», где есть следующие вкладки: смета, таймлайн, график выплат.
4. Прочие материалы хранятся в папке «Материалы по проекту»:
- коммерческое предложение;
6. В календаре запланировано обсуждение проекта внутри студии (заказчик не привлекается).
7. Аккаунт-менеджер обсудил проект с руководителем проекта. PM сформировал вопросы, на которых и у аккаунт-менеджера точно нет ответа/ информации.
8. Запланировано знакомство и разговор с руководителем проекта, аккаунт-менеджером и заказчиком. Важно вежливо представить и описать достижения менеджера, обозначить дальнейшие действия и передать ему слово. Параллельно необходимо фиксировать результаты обсуждения.
9. Составлено резюме разговора. Аккаунт-менеджер вместе с руководителем проекта проверил, что ничего не упущено — после этого резюме отправляется заказчику менеджером проекта.
10. Если договор с заказчиком не подписан, и необходимо подключение руководителя проекта на этапе согласования, аккаунт-менеджер присутствует на всех коммуникациях, берет на себя ответственность по согласованию Договора.
11. Проект можно считать официально переданным после передачи проекта менеджеру по чеклисту, получения оплаты и скана подписанного Договора и Приложения. Официально проданным — после получения акта за выполненные работы 🙂
Источник: blog.sibirix.ru