Горизонт планирования
Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе — порядка пяти недель. В переложении на спринты — 3-5 спринтов (зависит от опыта конкретной команды).
Я использую два монитора, Google-календарь, Scrumban, общую тетрадь и песочные часы. Сам способ постоянно дорабатывается, но общие принципы остаются неизменными: держать под рукой все проекты в рукописном виде + управлять движением проектов на виртуальной канбан-доске.
Сама процедура занимает 2 часа в неделю. Этого времени достаточно, чтобы распланировать нагрузку примерно на 35-50 человек. Удобно делать либо рано утром в понедельник, либо в пятницу, во второй половине дня, либо в воскресенье вечером.
Шаг 1. Концентрация на планировании. Разлиновка
Планирование — одна из самых муторных задач, которые я не могу делегировать. Я ее ненавижу. Вдобавок, я достаточно ленив, и всегда пытаюсь отложить планирование на самый последний момент. Однако я знаю, что взамен получу ясность и контроль над ситуацией. Это подстегивает начать. Примерно в воскресенье, часов в 6 вечера.
Хотя вся информация по проектам есть в электронном виде — я намеренно переписываю ее на бумагу. Это дает полную картину по загрузке команд и позволяет восстановить чувство контроля — обычно оно покидает меня полностью за две недели (если я пропустил планерку) или за одну командировку.
Итак, в общей тетради перво-наперво я записываю в столбец сотрудников, которые занимаются продакшном. Если в отделе есть команды (у нас это разработка), то группирую по командам. Если команд внутри отдела нет — группирую целиком по отделу, например, дизайн или копирайтинг.
Вверху листа пишу даты и отчеркиваю через каждые пять рабочих дней (в тетрадке клеток хватает ровно на 5 недель — совпадает с длиной нашего горизонта планирования). Получается вот так:
Время от времени появляются ребята, которые делают проект сольно или кочуют между командами. Это плохо, и я про это знаю.
Если попадаются праздничные дни — штрихую.
Кроме производства, есть отдел клиентского сервиса и продаж. Их я записываю на другой стороне тетрадного разворота. Итак, что там будет:
- Фамилии руководителей проектов, под каждым две колонки — в одной проекты в работе, в другой будущие проекты, но под которые уже нужно планировать ресурсы.
- Под списком проджект-менеджеров записаны мои аккаунт-менеджеры (отвечают за первоначальную работу с клиентом, выяснение требований к проекту и сбором прочих «входных данных»). Рядом с ними я буду вести список сделок, которые они курируют на этой неделе.
Шаг 2. Планирование того, что гарантированно случится
Следующее, что я делаю — запускаю Google Calendar и последовательно открываю рабочие календари команд. В календаре проставлены плановые спринты и проекты, на которые уже зарезервированы люди (это текущие проекты, по которым уже идет работа).
Эту информацию я переношу в свою табличку. Таким образом, я вижу гарантированную загрузку. Сразу же закрашиваю отпуска сотрудников, чтобы случайно не запланировать это время на проекты.
Шаг 3. Составление списка проектов
Для этого я открываю на втором мониторе Scrumban, в котором у меня хранятся карточки проектов по всем фазам. Карточка — это паспорт проекта. Их я обновляю раз в неделю, по понедельникам, на менеджерских планерках (об этом как-нибудь в следующий раз).
Я читаю карточку, переношу название проекта в таблицу к менеджеру проектов (на бумагу), изучаю чеклисты проекта (это список типовых действий, которые должны быть сделаны на каждой фазе — типа «выставить счет», «взять отзыв» и проч.), вспоминаю, были ли сделаны эти действия, если нет — ставлю соответствующие задачи в план менеджерам проектов. Если по каким-либо проектам я знаю, что будут необходимы ресурсы — я бронирую их в Google Calendar на соответствующую команду. Для каждого проекта или спринта указывают ориентировочную трудоемкость.
Если прямо сейчас я не могу запланировать ресурсы, например, не знаю на 100% статус проекта или не уверен, какая команда подойдет лучше — я переношу его в специальный календарь «Новые проекты».
В результате я формирую список текущих проектов у проджект-менеджеров, создаю часть задач, которые будут нужны при ведении проекта, более плотно заполняю горизонт планирования и гуглкалендарь по конкретным командам.
Шаг 4. Обработка сделок из CRM
Далее я открываю сделки из CRM и прохожусь по ним последовательно. Часть из них — передана проджект-менеджерам (я записываю такие сделки в первом столбце, возле фамилии проджект-менеджера). Но большая часть из них назначена на аккаунтов. Эти потенциальные сделки я заношу в соответствующий список возле фамилии аккаунта.
Те проекты, которые с большой вероятностью пойдут в работу и требуют особого внимания — помечаю у себя в тетради.
Шаг 5. Планирование «дырок»
В результате у меня получается запланированный календарь команд, благодаря которому я знаю точную нагрузку на каждого разработчика, дизайнера или менеджера. Но остается некоторое количество «дырок» в их работе.
Руководствуясь опытом и интуицией, в пустые места я добавляю проекты из календаря «Новые проекты». Например, карандашом. Удаляю проект из календаря «Новые проекты» и ставлю задачу на конкретную команду.
Если таковая есть (например, внезапно продано очень много аналитики) — уходит минут 40. В основном на то, чтобы понять, как скомбинировать работу, чтобы не было недовольных, а отгрузка шла в намеченные сроки.
Шаг 6. Внутренние задачи
Если остаются какие-либо «дырки» в календарях команд — самое время поставить туда внутренние задачи компании либо запланировать обучение.
Результат
После 2-х часов анализа получается почти ясная картина по загрузке студии. Однако все равно остается место вариативности и остаются «пустоты» в рабочем графике команд. Заполняем их мы уже совместно с менеджерами проектов на еженедельной планерке, в понедельник. Расскажу об этом как-нибудь в следующий раз.