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



    В прошлой статье я рассказывал, как мы в 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-сообщество, и какие есть у них преимущества?
    Поделиться публикацией

    Похожие публикации

    Комментарии 14
      0
      Давно задумываемся над оперативным планированием в редмайне. Но инструментария не хватает, особенно туго с отчетами. Подскажите, какие конкретно плагины вы используете в сабже, если не секрет.
        –1
        В личку ответил
        +3
        Мы пользовались около квартала плагином «Advanced roadmap», а затем мы стали делать свой и вот что сделали.

        И что же вы сделали?
        Не нашел ссылки на плагин…
        Где можно посмотреть и/или попробовать?

        P.S.
        За статью спасибо.
        Используем Redmine, поэтому интересно применить ваш опыт…
          0
          Присоединяюсь, было бы очень интересно посмотреть на данную разработку, так как нахожусь в стадии перехода на Redmine, но катастрофически не хватает инструментария управления.
            0
            Первая мысль: после «и вот что сделали» должна была быть ссылка на github (который уже разблокировали!) — весь остальной текст можно было вставить в readme.md…
              0
              Тоже этого ожидал. Но учитывая этот комментарий
              habrahabr.ru/post/227507/#comment_7716527
              сомневаюсь что будут исходы изменений.
                0
                Тогда это все не имеет смысла читать, увы. Раз воспользоваться нельзя.
            0
            Вот тут можно попробовать оперативное планирование redmine3.demo.rmplus.pro/clear_plan/by_project/it. Логин PushkinAS, пароль 1111

            Если есть вопросы по использованию redmine (передаче опыта), то могу попробовать помочь консультацией :)
            0
            Redmine — вещь! Но я перешел на YouTrack года полтора назад.

            Во времена использования Redmine об оперативном планировании речи не шло, а сейчас пробую наладить этот процесс в YouTrack. Судя по скриншотам из статьи нечто аналогичное можно настроить!
              0
              В чем причина перехода с Redmine на YouTrack?
                +1
                Причина одна: удобство и скорость интерфейса.

                Тут надо оговориться, что я использовал Redmine «из коробки», практически без плагинов (был один плагин для вставки скриншотов), т.е. по сути как реестр задач со статусами, сроками и фильтры/поиск по ним в небольшой команде из 5 человек. Никаких замороченных отчётов или хитрых workflow у нас не было.

                Для примера, помню, надо было целой пачке тикетов поменять статус. В Redmine в списке тикетов выделяю их галочками один за одним, чтобы потом воспользоваться контекстным меню и тут бац! промахнулся при очередном клике мимо чекбокса — все отметки слетели и вместо этого выделилась одна строка :(

                Выделив несколько строк галочками нельзя было через контекстное меню изменить сразу несколько полей, например, статус и приоритет. А если делать в два прохода — галочки сбрасываются после первого обновления. Посмотрел сейчас свежее demo.redmine.org: в контекстом меню появилась опция «Редактировать» — да, это то что мне было нужно. Но опять же, получается полная смена экрана, а хочется меньше перезагрузок, больше ajax, больше скорости!

                Однажды, наткнувшись на видео про YouTrack, сразу понял — вот оно!

                Для полноты картины, добавлю, что около года использовал Trello — со скоростью и «аяксовостью» интерфейса там ок, но в итоге всё превратилось в кашу, сложно было увидеть общую картину, всё-таки хотелось иметь ещё и табличный вид задач, помимо карточек.

                На одном из проектов использовал встроенные issues на Bitbucket — ну это слишком примитивно.

                Видел со стороны как работают с Jira — система-монстр! Скорее всего для моей команды из 5 человек это было бы излишне. Хотя сам не пробовал, не могу аргументировать.
                  0
                  Для примера, помню, надо было целой пачке тикетов поменять статус. В Redmine в списке тикетов выделяю их галочками один за одним, чтобы потом воспользоваться контекстным меню и тут бац! промахнулся при очередном клике мимо чекбокса — все отметки слетели и вместо этого выделилась одна строка :(

                  Выделив несколько строк галочками нельзя было через контекстное меню изменить сразу несколько полей, например, статус и приоритет. А если делать в два прохода — галочки сбрасываются после первого обновления. Посмотрел сейчас свежее demo.redmine.org: в контекстом меню появилась опция «Редактировать» — да, это то что мне было нужно. Но опять же, получается полная смена экрана, а хочется меньше перезагрузок, больше ajax, больше скорости!

                  Да, коробочный Redmine не очень удобно использовать местами, было над чем поработать. Но в целом пользоваться системой можно.
              0
              Интересно было бы узнать, каким образом у Вас организована работа с требованиями.
                0
                Через частично описанный тут модуль заявок. Заказчики пишут заявки и в них частично указывают требования, потом аналитик или руководитель проясняет требования по заявкам. Можно делать это устно или в рамках заявок. Когда требования определены, то руководитель ставит исполнителю формализованную задачу (в терминах понятных конечному исполнителю). К этой задаче крепится заявка, что бы исполнитель не терял фокус (понимал, для чего он делает задачу, что просил заказчик).

                Примерно вот так.

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

              Самое читаемое