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

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

Определимся с терминологией

Спринт — интервал времени, на который создается план (термин взят из Scrum, и смысл его тот же самый).
Оперативный план сотрудника — перечень задач, назначенных на конкретного исполнителя на спринт.

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

В первую очередь необходимо понять — для кого нужен оперативный план и какая от него польза?

Оперативный план позволяет обеспечить работой сотрудников на небольшой интервал времени (мы используем спринт длительностью 1 неделя), предоставить ему доступ ко всему горизонту задач на этот период, что, несомненно, повышает веру сотрудников в адекватность, дальновидность и профессионализм менеджеров. Альтернатива — назначать задачи на исполнителей по одной-две, по мере их появления и готовности к работе. Это удобно для некоторых менеджеров, но не нравится исполнителям.

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

Предпосылки для успешного применения оперативных планов

Имеет смысл внедрять оперативное планирование, если:

Группа исполнителей выполняет однотипные специализированные задачи (как на конвейере). Пример — небольшие доработки ПО по заявкам пользователей в третьей линии техподдержки;
Задачи не являются сверхсрочными (могут некоторое время находиться в очереди);
Приоритет задач меняется редко;
Сверхважные задачи, которые автоматически встают в начало списка и сдвигают остальные задачи, приходят редко;
Длительность задач обычно не превышает времени спринта (в основном меньше).

Получается, что оперативный план нужен для

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

Почему для оперативных планов предлагается использовать Redmine, а не специализированный софт вроде MS Projects? Потому, что оперативные планы создаются во многом для исполнителей, а не для менеджеров. Кроме того, оперативное планирование в Redmine позволяет работать с максимально детализированными и декомпозированными задачами. Создать и, главное, поддерживать актуальность такого плана в MS Project сложно.

Техническая реализация

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

Необходимо:

Включить талон на выполнение задачи в план. т.е. в определенный спринт. Для этого создается настраиваемое поле «Спринт» типа «Список со множественными значениями». Перечень значений — номера недель, вроде «Неделя 35», т.к. у нас спринты недельные (множественность выбора нужна в случае, если задача выполняется в течение нескольких спринтов);
Указать, сколько времени в течение спринта предполагается потратить на выполнение данной задачи (поскольку задача, например, может иметь оценку трудоемкости в 50 чч, а спринт содержит всего 40 рабочих чч.). Для этого создается настраиваемое поле «Оценка времени на спринт» типа «Целое» или «С плавающей точкой», в зависимости от того, как точно вы оцениваете трудоемкость задач;
Определить последовательность выполнения задач. Для этого создается настраиваемое поле «Очередность выполнения» типа «Целое». В этом поле просто ставиться номер задачи в очереди на выполнение в рамках текущего спринта, т.е. для первой задачи на выполнение — 1, для второй — 2 и т.д. Далее происходит ранжирование перечня по этому полю стандартными средствами Redmine в списке задач.

Вот так выглядит талон с новыми полями:

Так выглядит оперативный план в Redmine:

При желании его легко можно выгрузить в MS Excel или PDF средствами Redmine:

К сожалению, как говорится, «простота требует жертв». И в данном случае эта жертва — неудобство сбора истории планирования задачи на спринты. Например, для ответа на вопрос «сколько планировали времени на эту задачу в каждом спринте на протяжении последнего месяца?», придется собирать эту информацию по сообщениям об изменении соответствующих полей в истории изменения талона, т.к. поля «Оценка времени на спринт» и «Очередность выполнения» каждую неделю будут перезаписываться. Однако опыт показал, что такая статистика требуется крайне редко — обычно весь анализ выполнения плана происходит единожды в конце спринта (на ретроспективе).

Теперь ответ на второй вопрос — какая же польза от таких оперативных планов?

Сотрудникам спокойнее и комфортнее выполнять задачи, когда они видят перечень на некоторое время вперед и знают, что этот перечень будет изменен только в крайнем случае;
Менеджерам проще сформировать такой план в начале спринта (например, раз в неделю), чем распределять каждую приходящую задачу;
На составление оперативного плана на неделю уходит 10-15 минут на каждого исполнителя, что несравненно менее трудоемко, чем актуализировать аналогичным образом план в MS Project;
Распределение задач по конкретным исполнителям можно делегировать тим лиду, обозначив ему общий перечень задач;
Повышается прозрачность планирования работ: любой сотрудник (менеджер или исполнитель) может зайти в Redmine и просмотреть оперативный план другого сотрудника без лишних вопросов и бюрократии;
Повышается общая культура управления: менеджерам и заинтересованным лицам доносится, что оперативный план может корректироваться только в крайнем случае с согласования, например, технического директора. Поэтому необходимо заранее готовить перечень задач и определять их приоритеты. Не успел к планированию задач на спринт — жди следующего распределения;

Некоторый «лайф-хак» при работе с оперативными планами (выяснилось также опытным путем)

В связи с динамикой поступления задач, возможными ошибками в оценке трудоемкости и другой непредвиденной головной болью имеет смысл планировать задачи не на всю длительность спринта, а оставлять некоторый буфер времени. У нас этот запас — 8 часов, т.е. планируем 32 чч для недельного спринта;
Первоисточником плана должен быть отфильтрованный перечень задач в Redmine (как на второй картинке). Однако для фиксации плана сразу после его создания лучше всего выгружать его snapshot (в формате MS Excel или PDF) — аналогично базовому плану MS Project. Далее этот зафиксированный оперативный план может быть разослан заинтересованным лицам, а также быть использован на ретроспективе в конце спринта;
Для удобства работы с оперативным планом по описанной концепции удобнее всего использовать типы трекеров и схемы переходов из моей предыдущей статьи.

Описанная концепция была разработана как временная, пока в компании не внедрится более совершенная система оперативного планирования. Но нет ничего более постоянного, чем временное — схема успешно работает уже более года.

Буду рад ответить на ваши вопросы и узнать ваш опыт по оперативному планированию.

Оперативные планы в Redmine без дополнительных плагинов