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

.

И всё же, когда спонсор проекта спрашивает, успеваем ли мы к релизу, честный ответ звучит как «смотря что считать». Учёт задач показывает, чем занят каждый сотрудник. Но он не говорит, придёт ли к финишу вовремя проект в целом.

Учёт задач и планирование проектов в Redmine

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

Но по мере роста проектов появляются другие вопросы, и список задач на них не отвечает:

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

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

Redmine для планирования проектов: что есть из коробки

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

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

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

Где заканчиваются возможности диаграммы Gantt в Redmine

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

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

В этом и разница между тем, чтобы смотреть на график, и тем, чтобы им управлять. Смотреть — вопрос отображения. Управлять — значит менять план, видеть последствия изменений и согласовывать их с командой. Planner переносит редактирование графика, наглядные зависимости и проверку изменений прямо в диаграмму. Именно о такой альтернативе Redmine Gantt идёт речь в этой статье: диаграмма остаётся внутри Redmine, но её можно редактировать, и это не отдельный инструмент.

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

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

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

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

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

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

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

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

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

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

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

Критический путь в Redmine: какие задачи определяют дату завершения

Когда зависимости видны, возникает второй вопрос. Если всё связано, какие задержки важнее всего?

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

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

  • Полный резерв (total float) — на сколько задача может задержаться, не сдвигая дату завершения проекта.
  • Свободный резерв (free float) — на сколько задача может задержаться, не сдвигая начало следующей за ней задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более здоровая практика состоит из четырёх шагов:

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

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

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

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

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

RedmineUP Planner: альтернатива Redmine Gantt для планирования проектов

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

Практическая польза — не в какой-то одной функции. Изменения графика становится проще обсуждать, проверять и контролировать в одном месте, а Redmine остаётся источником истины для самой работы.

Planner объединяет редактируемую диаграмму Ганта, общий черновик с проверкой и применением изменений (Review и Apply), зависимости и Undo/Redo с расширенными возможностями планирования: анализом критического пути с полным и свободным резервом, базовыми планами со столбцом отклонений, группировкой, дополнительными колонками запросов, цветами полос и вехами версий. Подробности — на странице Planner и в документации.

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

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

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

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

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

Получить RedmineUP Planner