Планировать нельзя сойти с ума: как не забыть ни про проекты, ни про людей

Привет, я Вика Синельникова — руководитель отдела спецпроектов в KTS. Рассказываю, как еженедельно планировать команду на большой объем проектов и не сойти с ума.

Большая часть команд разработки, даже внутри нашей компании, занимается проектами, длительность которых начинается как минимум от месяца, а то и трёх.

Когда общий срок проекта исчисляется месяцами, принято планировать работу спринтами. Например, в других отделах нашей компании, работают двухнедельными спринтами. Менеджеру и руководителю это даёт заранее известный и прогнозируемый загруз команды на месяцы вперед. Объём планирований при этом сокращается.

При работе спринтами основная часть планирования приходится на пре-старт самой разработки. Дальше весь объём задач нескольких месяцев планомерно разбивается этапами по пару недель. В процессе работы менеджер и руководитель следят за выполнением плана и при необходимости актуализируют его.

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

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

Также помимо проектной работы у нас есть дейлики, менторские встречи и внутренние задачи. Следовательно важно учитывать все эти задачи при планировании, чтобы не получилось так, что время разработчиков забронировано только на разработку новых проектов. И распределять всё это в рамках восьмичасового рабочего дня.

Пять лет назад я была единственным менеджером, который вёл разработку проектов с короткими сроками в KTS. Весь объём задач, сроки запусков проектов, загрузку разработчиков я хранила в чертогах своего разума и изредка выписывала их на бумагу.

Когда менеджеров стало больше, мы столкнулись с проблемой планирования разработчиков. Один и тот же разработчик мог отвечать за разные стадии проектов — например, и разработка и поддержка — у двух разных менеджеров. Мы попробовали решить эту проблему, создав по чату с менеджерами на каждого разработчика. Это было не идеально, но помогало и нам, и ребятам понимать приоритетность задач и время их решения.

Чем дальше мы росли, тем больше мы понимали, что нужна система планирования. Сначала мы попробовали отталкиваться от планирования контрольных точек на проекте. Это было нужно, чтобы знать, кто должен сделать что-то на определённом проекте в конкретный день и не быть загруженным другими задачами. Тогда, в 2019 году появилась наша первая таблица с говорящим названием «День грядущий». Ожидаемо, что сразу идеала не получилось и быстро стало ясно, что сам подход ошибочный.

В 2020-й год мы вошли с новой табличкой и постарались сделать распределение загрузки более наглядной. Тогда казалось, что достаточно лишь добавить в неё разработчиков.

Это помогло, но не решило все проблемы планирования. Самым полезным в этой таблице было то, что мы стали заранее вносить проекты, которые могут подтвердиться.

Уже по таблице 20-го года можно заметить тизер надвигающейся проблемы: наслоение задач по разным проектам на одного человека. Мы немного изменили саму таблицу в 21-м году, стало получше, но она до сих пор не могла полноценно решить наших целей при планировании.

После предыдущего опыта мы поняли, что:

То, что у нас получилось может подойти командам, где необходимо вести работу над всеми проектами одновременно, например, небольшим агентствам.

У таблицы есть два формата: свёрнутый вид с графиками для быстрого анализа загруженности отдела и развёрнутый вид, где показаны детали по каждому из ребят в отделе.

Свернутый вид

На картинке ниже видно, что мы освоили графики внутри ячеек и, что большинство ребят в отделе распланированы. Их запланированные часы суммируются и подсвечиваются зелёным внутри диаграммы. Красный остаток рассчитывается относительно рабочего времени, учитывая разный формат работ (фуллтайм/парттайм). Также, сразу видно сводную информацию по загрузке всего отдела, кто и когда идет в отпуск. Этот вид помогает быстро принять решение о подтверждении сроков для новых заявок и сверять соответствие бизнес-плану.

Здесь в первую неделю декабря большая часть часов уже распланирована, а остальная часть месяца, ещё нет.

Развёрнутый вид

В развёрнутом виде представлена разбивка возможных типов задач по каждому отдельному разработчику. Все задачи разбиваются на проектные — это разработка, поддержка и ревью — и непроектные. К последним относится обновление статусов, менторские встречи и внутренние задачи по отделу.

В своем планировании мы стараемся уделять время на развитие, но так как это внутренние расходы, нам важно, чтобы их объем не превышал 10% в месяц.

Справа — столбец с именем сотрудника и перечнем проектов, над которыми он работает. Сверху — количество рабочих часов.

Помимо оперативного доступа к структурированным данным в таблице есть и опция с быстрым анализом. Там указаны запланированные часы, незапланированные и их процентное соотношение.

Главными результатами работы с нашим «космолётом» стали:

Конечно, эта таблица не панацея и есть много других сервисов для планирования (их мы тоже рассматривали, даже внутри нашего таск-трекера), но они не до конца решали наши задачи, поэтому мы сделали удобный «инструмент»и под себя, который заметно упростил работу с планированием.

После перехода на почасовое планирование в рамках дня, мы наглядно стали видеть, какие задачи могут влиять друг на друга, и точнее определять срок их сдачи.

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

Предыдущие таблицы были слишком неструктурированные, поэтому подключить тимлидов к работе в них было тяжело.

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

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

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

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

Хотя.. Если у вас есть своя боль и решение такой же задачи — буду очень рада, если поделитесь.

***

Если вам нужна помощь с решением ваших бизнес-задач, можно написать мне в телеграм и наша команда поможет придумать игровое решение.