http://habrahabr.ru/post/245065/



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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



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

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



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

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

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