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

.

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

Учёт задач в Redmine

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

По мере роста проектов возникают вопросы, на которые приходится отвечать:

  • Действительно ли мы укладываемся в график?
  • Какие задачи тормозят работу?
  • Что будет, если кто-то из команды сорвёт срок?
  • Повлияет ли эта задержка на финальный релиз?
  • Следуем ли мы по-прежнему первоначальному плану проекта?

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

Redmine для планирования проектов

Прежде чем что-либо добавлять, полезно чётко понимать, что уже предлагает стандартная установка Redmine. Этого более чем достаточно для многих команд:

  • Даты начала и конца и оценки трудозатрат в каждой задаче, а также родительские и дочерние задачи для декомпозиции работ.
  • Связи между задачами. Связи «предшествует» и «следует за» означают, что одна задача не может начаться до окончания другой, причём можно задать задержку. Когда предыдущая задача сдвигается на более поздний срок, Redmine сдвигает за ней и следующую.
  • Версии со сроками, которые служат вехами релизов и показывают прогресс в оперативном плане.
  • Диаграмма Ганта, которая размещает задачи и версии на шкале времени и показывает связи стрелками.
  • Сохранённые запросы и экспорт в CSV — этого хватает для отчётов о статусе и ручной копии плана.

Для небольшой команды этого уже достаточно, чтобы использовать Redmine для планирования проекта. Пробелы появляются, когда график разрастается. Redmine не рассчитывает критический путь (запрос на его отображение в диаграмме Ганта открыт на redmine.org с 2013 года), в нём нет механизма хранить утверждённый план рядом с текущим, а любое изменение дат проходит через редактирование задачи.

Ограничения диаграммы Ганта в Redmine

Диаграмма Ганта — это инструмент визуального планирования и управления проектами, который отображает задачи проекта на временной шкале. Однако в Redmine это не интерактивный инструмент: для изменения дат требуется редактировать задачи, а чтобы понять последствия предлагаемого изменения, требуются дополнительные действия. Руководитель проекта, сдвигающий версию на неделю, в итоге открывает дюжину задач, а изучение зависимостей в длинном списке задач занимает время. Кроме того, остаются открытыми два вопроса: какие задачи определяют дату завершения и как текущий график соотносится с утверждённым.

Плагин Planner позволяет редактировать график, просматривать зависимости и проверять изменения прямо в диаграмме. Именно о такой альтернативе диаграмме Ганта в Redmine и пойдёт речь в этой статье. Всё начинается с хорошего обзора. Когда исполнители, даты и продолжительность задач отображаются на одной временной шкале проекта, вы можете оценить ход проекта. Вот план релиза из десяти задач в RedmineUP Planner — плагине, к которому мы вернёмся позже в этой статье.

Диаграмма Ганта в Redmine — график проекта, задачи и назначенные исполнители

Наглядный обзор графика проекта, задач и зон ответственности в одной диаграмме Ганта в Redmine.

Зависимости между задачами: как одна задержка сдвигает график всего проекта

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

Возьмём типичный релиз программного обеспечения: разработка бэкенда → интеграция → тестирование QA → релиз. Работа над бэкендом была запланирована на две недели, но заняла три. Интеграция не может начаться до завершения бэкенда, поэтому её сроки сдвигаются. Тестирование не может начаться до завершения интеграции, поэтому его сроки тоже сдвигаются. Дата релиза, обещанная заказчику в прошлом месяце, сдвигается вместе с ними. Никто не допустил ошибки после первого срыва сроков. График просто пошёл по пути, который ему проложили зависимости.

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

Именно поэтому проектный менеджер должен понимать зависимости, прежде чем менять срок или давать обещания по сдаче. Каждый раз, когда дата сдвигается, спрашивайте: «Что ждёт выполнения этой задачи?» Функция «связи» в Redmine позволяет фиксировать ответ, а визуальная диаграмма упрощает его восприятие.

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

Диаграмма Ганта для планирования проектов в Redmine — зависимости задач и конфликты в расписании

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

Критический путь для проекта в Redmine

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

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

Запас времени (float) бывает двух видов:

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

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

Вот почему это меняет приоритеты. Представьте две задачи, обе с приоритетом «Высокий» в Redmine. Первая — интеграция, она на критическом пути. Вторая — настройка тестовой среды, от которой ничего срочного не зависит. Если интеграция задержится на два дня, релиз сдвинется на два дня, если только команда не наверстает это время за счёт других задач. Если настройка тестовой среды задержится на неделю, дата релиза не изменится. Метки приоритета не могут этого показать, но критический путь — может. Без него команды склонны направлять своих лучших специалистов на самые «горячие» задачи или на те, у которых ближайший срок выполнения, вместо тех, которые определяют сроки сдачи.

Стандартная версия Redmine не включает анализ критического пути, поэтому многие команды либо пропускают этот анализ, либо ведут его в отдельном инструменте, который со временем устаревает. На скриншоте критическая цепочка выделена красным, и у каждой задачи указан запас времени. Тестовая среда и вебинар для клиентов имеют 12 рабочих дней запаса времени. Экраны фронтенда показывают отрицательное значение: они заканчиваются позже, чем позволяет следующая за ними задача — тот же конфликт, отмеченный на предыдущем скриншоте, и он требует внимания.

Диаграмма Ганта в Redmine с выделенным критическим путём и запасом времени задач

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

Базовый план проекта: как его использовать?

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

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

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

Это обеспечивает три вещи, которых обычно не хватает командам:

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

На скриншоте команда сохранила базовый план под названием «Initial plan» на старте проекта. Тонкая линия под каждой полосой отмечает исходное плановое положение, а в отдельном столбце видно, на сколько рабочих дней сдвинулась каждая задача. Тестовая среда ровно там, где и планировалось. Лендинг отстаёт на пять рабочих дней, экраны фронтенда — на шесть, развёртывание релиза — на четыре. Это реальное состояние проекта в цифрах.

Сравнение с базовым планом проекта в Redmine — плановые и текущие сроки задач

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

Совместное планирование проектов: проверяйте изменения до их введения

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

Более эффективная практика состоит из четырёх частей:

  1. Изменение предлагается, а не сразу применяется.
  2. Те, кого оно затрагивает, видят, что именно изменится.
  3. Менеджер проекта оценивает последствия, прежде чем утвердить изменение.
  4. Только после этого новый график становится рабочим планом.

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

Скриншот показывает этот подход на практике. Planner рисует стрелки зависимостей и подсвечивает нарушения в графике. Если предложенное изменение затрагивает последующие задачи, таблица Review показывает итоговые изменения дат до того, как они будут применены в Redmine. Здесь предложенное изменение для экранов фронтенда ждёт в общем черновике (Draft): старые и новые даты стоят рядом, указан автор. В диалоге также отмечено, что в результате Redmine перенесёт задачу интеграции на конец месяца. В реальные задачи пока ничего не записано, и команда может решить, что применять.

Общий черновик в Redmine Planner для проверки изменений в расписании проекта

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

RedmineUP Planner: альтернатива диаграмме Ганта в Redmine

RedmineUP Planner — это инструмент для планирования проектов, который объединяет эти практики внутри Redmine. Вы планируете в интерактивной диаграмме Ганта, где зависимости показаны стрелками, а нарушения подсвечены. Предложенные изменения ждут в общем черновике, пока кто-то их не проверит и не применит, а критический путь, базовые планы и вехи версий находятся на той же диаграмме.

Изменения графика становится проще обсуждать, проверять и контролировать в одном месте. Planner также работает вместе с другими продуктами RedmineUP. Команды, которые работают спринтами, могут вести доски в плагине Agile, а менеджеры, которым нужно распределять людей между проектами, могут добавить плагин Resources.

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

Как сделать планирование проектов частью рабочего процесса в Redmine

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

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

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

Получить RedmineUP Planner