Комментарии
Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в «Сибириксе» — порядка пяти недель. В переложении на спринты — 3–5 спринтов (зависит от опыта конкретной команды).

наши процессы

Горизонт планирования

Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе  порядка пяти недель. В переложении на спринты  35 спринтов (зависит от опыта конкретной команды).
Владимир Завертайлов
СПАЙК | Agile Marketing Agency, координатор,
Сибирикс, scrum-студия, генеральный директор
Я использую два монитора, Google-календарь, Scrumban, общую тетрадь
и песочные часы. Сам способ постоянно дорабатывается, но общие принципы остаются неизменными: держать под рукой все проекты в рукописном виде + управлять движением проектов на виртуальной канбан-доске.
Сама процедура занимает 2 часа в неделю. Этого времени достаточно, чтобы распланировать нагрузку примерно на 3550 человек. Удобно делать либо рано утром в понедельник, либо в пятницу, во второй половине дня, либо
в воскресенье вечером.

Шаг 1. Концентрация на планировании. Разлиновка

Планирование  одна из самых муторных задач, которые я не могу делегировать. Я ее ненавижу. Вдобавок, я достаточно ленив, и всегда пытаюсь отложить планирование на самый последний момент. Однако я знаю,
что взамен получу ясность и контроль над ситуацией. Это подстегивает начать. Примерно в воскресенье, часов в 6 вечера.

Хотя вся информация по проектам есть в электронном виде  я намеренно переписываю ее на бумагу. Это дает полную картину по загрузке команд
и позволяет восстановить чувство контроля  обычно оно покидает меня полностью за две недели (если я пропустил планерку)
или за одну командировку.
Итак, в общей тетради перво-наперво я записываю в столбец сотрудников, которые занимаются продакшном. Если в отделе есть команды (у нас это разработка), то группирую по командам. Если команд внутри отдела нет  группирую целиком по отделу, например, дизайн или копирайтинг.

Вверху листа пишу даты и отчеркиваю через каждые пять рабочих дней
(в тетрадке клеток хватает ровно на 5 недель  совпадает с длиной нашего горизонта планирования). Получается вот так:
Время от времени появляются ребята, которые делают проект сольно или кочуют между командами. Это плохо, и я про это знаю.

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

  • Фамилии руководителей проектов, под каждым две колонки  в одной проекты в работе, в другой будущие проекты, но под которые уже нужно планировать ресурсы.
  • Под списком проджект-менеджеров записаны мои аккаунт-менеджеры (они отвечают за первоначальную работу с клиентом, выяснение любых требований к проекту и сбор прочих «входных данных»). Рядом с ними я буду вести список сделок, которые они курируют на этой неделе.
Разлиновка занимает примерно 20 минут и позволяет мне сконцентрироваться на задаче.
Шаг 2. Планирование того, что гарантированно случится

Следующее, что я делаю  запускаю Google Calendar и последовательно открываю рабочие календари команд. В календаре проставлены плановые спринты и проекты, на которые уже зарезервированы люди (это текущие проекты, по которым уже идет работа).
Эту информацию я переношу в свою табличку. Таким образом, я вижу гарантированную загрузку. Сразу же закрашиваю отпуска сотрудников,
чтобы случайно не запланировать это время на проекты.

Шаг 3. Составление списка проектов

Для этого я открываю на втором мониторе Scrumban, в котором у меня хранятся карточки проектов по всем фазам. Карточка  это паспорт проекта.
Их я обновляю раз в неделю, по понедельникам, на менеджерских планерках (об этом как-нибудь в следующий раз).

Я читаю карточку, переношу название проекта в таблицу к менеджеру проектов (на бумагу), изучаю чеклисты проекта (это список типовых действий, которые должны быть сделаны на каждой фазе  типа «выставить счет», «взять отзыв» и проч.), вспоминаю, были ли сделаны эти действия, если нет  ставлю соответствующие задачи в план менеджерам проектов. Если по каким-либо проектам я знаю, что будут необходимы ресурсы  я бронирую их в Google Calendar на соответствующую команду. Для каждого проекта или спринта указывают ориентировочную трудоемкость.

Если прямо сейчас я не могу запланировать ресурсы, например, не знаю
на 100% статус проекта или не уверен, какая команда подойдет лучше 
я переношу его в специальный календарь «Новые проекты».
В результате я формирую список текущих проектов у проджект-менеджеров, создаю часть задач, которые будут нужны при ведении проекта, более плотно заполняю горизонт планирования и гуглкалендарь по конкретным командам.

Эта операция примерно на 40 минут.

Шаг 4. Обработка сделок из CRM

Далее я открываю сделки из CRM и прохожусь по ним последовательно. Часть из них  передана проджект-менеджерам (я записываю такие сделки в первом столбце, возле фамилии проджект-менеджера). Но большая часть из них назначена на аккаунтов. Эти потенциальные сделки я заношу
в соответствующий список возле фамилии аккаунта.

Разбор заявок из CRM занимает порядка 10 минут.

Те проекты, которые с большой вероятностью пойдут в работу и требуют особого внимания  помечаю у себя в тетради.
Шаг 5. Планирование «дырок»

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

Руководствуясь опытом и интуицией, в пустые места я добавляю проекты
из календаря «Новые проекты». Например, карандашом. Удаляю проект
из календаря «Новые проекты» и ставлю задачу на конкретную команду.

Это занимает еще минут 20, если нет жесткой нехватки ресурсов.
Если таковая есть (например, внезапно продано очень много аналитики)  уходит минут 40. В основном на то, чтобы понять, как скомбинировать работу, чтобы не было недовольных, а отгрузка шла в намеченные сроки.

Шаг 6. Внутренние задачи

Если остаются какие-либо «дырки» в календарях команд  самое время поставить туда внутренние задачи компании либо запланировать обучение.

Результат

После 2-х часов анализа получается почти ясная картина по загрузке студии. Однако все равно остается место вариативности и остаются «пустоты» в рабочем графике команд. Заполняем их мы уже совместно с менеджерами проектов
на еженедельной планерке, в понедельник. Расскажу об этом как-нибудь
в следующий раз.