Оперативное планирование в Redmine

Оперативное планирование в Redmine - 1

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

Как мы планируем

Вкратце расскажу о процессе оперативного планирования, которое работает в нашем IT-отделе.

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

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

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

В последнюю пятницу месяца происходит нечто похожее на планирование спринта Scrum (я как-то переболел этой методологией). Принципиальная разница в том, что у нас много заказчиков присутствует на согласование плана, а в Scrum со стороны заказчика только Product owner.

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

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

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

К этому процессу мы пришли опытным путем, не сразу, и он живет в компании, достаточно давно.

Оперативное планирование в Redmine - 2

Что мы сделали в Redmine

Стандартный Redmine позволяет объединять задания в версии, проставлять сроки исполнения и оценочные часы. Наверное, на этом стандартные возможности планирования заканчиваются.

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

В свободном доступе имеется ряд плагинов для более глубокого планирования. Большинство из них заточено под гибкие методологии разработки (Scrum, Kanban и т.д.). Но гибкие методологии не всегда подходят для большой компании. Тем более, у нас есть разные программистские отделы со своей спецификой, есть куча заказчиков и нет желающих становиться Product owner-ом, нужно было внедрять оперативное планирование и не в программистских отделах.

Мы пользовались около квартала плагином «Advanced roadmap», а затем мы стали делать свой и вот что сделали.

Постановка в план

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

Для руководителей проектов сделали кнопку «Назначить», которая ставит задачу в план.
Оперативное планирование в Redmine - 3

Ввели понятие самого плана, в который может входить несколько версий. Т.е. в плане октября, например, может быть две версии самой программы. При этом в сторонних не программистских отделах, для прозрачности работы с планом, сделали автоматическую привязку задачи к плану по дате завершения. А также, сделали автоматическое создание плана и версии, если их не существовало. Это сделало планирование более прозрачным для специалистов далеких от ИТ.

По исполнителю и по версии (с возможностью переключения в интерфейсе) стали формировать план. Последнюю, кстати, переименовали в этап. Это было понятнее пользователям.

Оперативное планирование в Redmine - 4

Приоритезация

Довольно быстро возникла проблема приоритезации. У руководителей была необходимость показывать исполнителю в каком порядке необходимо выполнять задачки.

Стандартные текстовые приоритеты Redmine не очень подходили, поскольку не задавали четкой последовательности выполнения задач.

Еще в Redmine есть возможность связывать задачки в последовательные цепочки. Это тоже не подошло, так как смена приоритетов превращается в нетривиальную задачу. Действие иногда блокировались, и скрытое автоматическое изменение сроков во всей цепочке не всегда было к месту.

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

Оперативное планирование в Redmine - 5

Распределение задач

Для того, чтобы эффективно распределять задачи по исполнителям, мы прикрутили несколько счетчиков, которые показывали насколько заполнен план по сотруднику, на сколько исполнитель его выполнил и т.д.

Оперативное планирование в Redmine - 6

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

Согласование плана

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

Теперь, руководитель просто нажимает ссылку «Согласовать план». После этого делается слепок плана и можно смотреть все изменения, которые с ним происходят: как меняется оценка часов, какие задачи вылетают из плана, а какие появляются в нем и даже то, как меняются заголовки задач. Это дает удивительную гибкость руководителю проекта, а контроль над планом остается высоким.

Оперативное планирование в Redmine - 7

Где зависают задачки и почему

У нас есть как большие, так и маленькие отделы по разработке ПО. В больших отделах есть полный набор должностей, связанных с разработкой ПО: аналитики, программисты, тестировщики и руководитель. Бывало так, что аналитики писали требования «в ящик», а программисты не успевали писать код. Это не очень хорошо, чтобы контролировать такие ситуации мы придумали аналог Scrum-доски (мой руководитель называет ее WIP(Work in progress)-доской). Каждую колонку этой доски можно гибко настроить на основе стандартных запросов задач Redmine. Т.е можно сказать, что задачи этого запроса попадают вот в эту колонку, а запросы этого — в другую.

Оперативное планирование в Redmine - 8

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

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

Оперативное планирование в Redmine - 9

Оперативное планирование дало много дополнительных преимуществ:

  • Перестали теряться работа и ответственность.
  • У исполнителей появилась фокусировка на достижение плана.
  • Контроль над работой подразделения вырос.
  • Появилось какое-то взаимопонимание между внутренними заказчиками и программистами. Заказчики стали видеть, что IT-отдел это не только статья расхода. Исполнителям же стало проще объяснять свою загруженность.

Интересно было бы узнать, какие средства для оперативного планирования использует Habra-сообщество, и какие есть у них преимущества?

Автор:

Источник

Оставить комментарий