Скоро лето. А пора отпусков началась уже сейчас. Разработчиков не так сложно распределять по проектам, особенно когда работа построена как у нас — спринтами. Другой вопрос с менеджерами. ПМ на каждом проекте один. И он тоже хочет в отпуск. Проблема.

Ах, да. Проект же можно оставить в руках ПМа на время его отпуска. Пусть руководит работами с ноутбука, лежа на пляже. Только так не работает. У нас менеджеры ходят в полноценные отпуска. Так что приходится что-то делать с проектами (причем со всеми, поочередно) на это время.

Вообще, на случай, если проект очень большой, сложный (ну, или клиент такой) — у нас в договоре есть пункт:

«Сроки исполнения обязательств Подрядчика и Заказчика могут быть перенесены на время отсутствия (отпуска) ответственного лица с одной из Сторон в соответствии со следующим графиком, определенном в настоящем пункте.

Но в большинстве случаев проект все-таки передается на другого менеджера.

Как именно передавать проект — зависит от этапа на котором он находится.

Итак, фазы на которых может оказаться проект

Проект только принят в работу, прошло знакомство с менеджером

Действия: проект временно передается на аккаунт-менеджера (у нас эта должность также включает функции продажника), который заводил проект. Брифование заказчика до начала работ проводится руководителем проекта и аккаунт-менеджером совместно. Составляется график работ. По проекту могут выполняться работы по первому этапу (аналитика: агрегация требований, разработка прототипа, написание ТЗ).

Демонстрация результата работ заказчику обычно не проводится (если позволяют сроки) до выхода руководителя проекта из отпуска. Если сроки не позволяют — то промежуточные результаты контролируются дополнительно директором по юзабилити / арт-директором. Демонстрации проводит аккаунт-менежер совместно с аналитиком.

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

Действия: проект передается на одного из оставшихся в строю руководителей проектов. Составляется подробный план работ по проекту на месяц , в котором фиксируется:

какие работы должны быть сделаны и когда,

что и когда должно быть согласовано с заказчиком,

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

Задачи сразу проставляются в календарь и кор.портал всем исполнителям (захочешь — не забудешь).

Сложный проект с нестандартной логикой работы, техническим заданием на 200 страниц, по которому идет 12-ый спринт программирования. Отклонения от технического задания можно отследить только по бэклогам спринтов.

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

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

Проект на стадии сдачи и подписания итогового акта

Действия: Должен быть завершен до отпуска, если нет неоправданных тормозов на согласовании со стороны заказчика (например, директор тоже в отпуске, акт больше никто подписать не может). Если такие задержки есть, то проект может быть передан на аккаунт-менеджера, который заводил проект для подписания оставшихся документов.

Проект на стадии гарантийной и технической поддержки

Действия: аналогично большим и сложным проектам. Только решение неотложных проблем и сбор бэклога. Также такой проект может быть передан (навсегда) на кого-то из новых менеджеров. Мы зачастую используем проекты на техподдержке для прокачки их навыков.

Порядок действий при передаче проекта

1. Готовим транзишн-файл. У нас это таблица со следующими разделами:
   • Проект. Тут все просто — указываем название. Если у проекта отличается название от контрагента — это стоит тоже отметить.
   • Контакты. Полный список контактных лиц со стороны заказчика с указанием кто за что отвечает. По каждому контакту надо указать e-mail, телефон, скайп.
   • Статус. В каком статусе сейчас находится проект. Описываем текстом в свободной форме. Стараемся не забыть все важные детали.
   • Документы. В зависимости от статуса проекта, в общем случае надо указать, где искать следующее:
     • Договора и приложения.
     • Актуальная смета на текущий этап (спринт) и на следующие (если есть).
     • Счета и акты.
     • Таймлайн, График платежей.
     • Бэклог (на текущий спринт и общий на проект).
     • Техническое задание и прототип.
     • Дизайн (если сверстано не все — то список отрисованных и согласованных макетов надо подготовить отдельно).
     • Верстка (если сверстано не все — то список сверстанных страниц надо подготовить отдельно).
     • Багрепорт.
     • Инструкция по работе с админ-панелью и т.п.
   • Состав команды. Список разработчиков, участвовавших в проекте, с указанием кто и что делал.
   • Кому. Указываем нового ответственного с нашей стороны (главное не забыть предупредить его. На кого именно будет передан проект заранее согласуется с руководителем).
   • Задачи. Список задач на время отпуска либо ссылка на нужную страницу бэклога.
   • Клиент в курсе. Тут ставим галочку после того как уведомили клиента.
   
    
2. Обсуждаем голосом по каждому проекту с новым ответственным задачи и нюансы по проекту, а также линию поведения в ответ на те или иные действия заказчика.
    
3. Рассылаем уведомления заказчикам (временно ответственный ставится в копию)
   • В очередном еженедельном отчете.
   • Письмо-напоминание перед самым отпуском.
   
    
4. Пока менеджер в отпуске
   • ставим его в копию всей переписки с заказчиком.
   • ставим ему в календарь (у нас менеджеры планирую свои задачи в Google-календарях, у вас вполне может использоваться другая система) вопросы, которые он должен будет решить по проекту после возвращения.

Итак, проект успешно передан. Менеджер отдохнул и вернулся из отпуска, даже на работу уже пришел. Что дальше? Каждый ответственный в том же документе отдельной колонкой заполняет статус по проекту на момент обратной передачи + кратко обсуждает это с ПМом голосом. Клиенту уходит письмо «Здравствуй, Вася». Дальше все идет своим чередом.