1. Введение

В статье Успешное планирование в ИТ консалтинге. Теория и практика использования JIRA и MSP / Хабр (habr.com) я рассказал про несколько уровней планирования проектов:

• краткосрочное планирование (спринты),

• планирование проектов\контрактов (календарный план),

• планирование загрузки ресурсов (ресурсный план),

• и наконец финансовое планирование (квартал, год и т.д.).

А также коснулся реализации функциональной архитектуры систем календарного планирования первого и второго уровня.

Опишу подробно как построен процесс календарного и оперативного планирования в связке JIRA<->MSProject на примере реализации в одном российском банке.

2. Архитектура с использованием локальных файлов MSProject

Схема календарного планирования ИТ проектов в банке следующая – планы проектов сохраняются в локальных файлах MSProject, задачи из которых синхронизируются с задачами в одном экземпляре JIRA. Задачи в свою очередь, агрегируясь на рабочих панелях\в спринтах, представляют собой оперативные планы работ.

Как организационно и технологически работает такая схема планирования наглядно показано на схеме.

• Продуктовые\проектные подразделения формируют у себя планы по своим проектам\портфелям проектов в локальном файле MSProject, каждый из которых состоит из нескольких тысяч строк и сотен проектов, что позволяет говорить о промышленном использовании решения. В таком файле настроена интеграция с единой JIRA, задачи в которой (или эпики) связаны по определенному соглашению об иерархии, которая детально описана в разделе «структура проектов в JIRA».

• Ресурсные подразделения, являясь «наблюдателями» планов, контролируют сводную загрузку сотрудников по отчетности выгружаемой из JIRA в excel. Оперативные задачи сотрудников отслеживаются на рабочих столах\дашбордах – каждый может настроить себе самостоятельно. Выравнивание загрузки и решение ресурсных конфликтов проходит вместе с менеджерами продуктовых\проектных подразделений в MSProject. Информация сразу после этого загружается в JIRA, что обеспечивает актуальность отчетности.

• Сотрудники работают со своими задачами в JIRA и информация о результатах их деятельности (% выполнения, статус задачи, запрошенные новые сроки…) периодически загружается в MSProject, обеспечивая таким образом отслеживание динамики исполнения как по одному проекту, так и по всем проектам продуктового портфеля.

• Отчетность в данной схеме лучше всего получать из JIRA, т.к. там аккумулируется вся значимая информация. Основные виды отчетов и показателей представлены на рисунке.

3. Структура проектов в JIRA

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

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

Что бы не возникало путаницы - сущность проект в JIRA буду так и называть - «проект JIRA», а проекты в определении PMI «Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата» – просто проектом.

И так, какие «проекты JIRA» были созданы и активно используются? Перечислю важнейшие для процессов производства ПО:

3.1. «Проект JIRA» с бизнес инициативами.

В этом «проекте JIRA» каждая задача называется бизнес-инициативой и проходит все стадии присущие проекту в «классическом» понимание управления проектами (я ориентируюсь в первую очередь на PMBoK). Несмотря на другую терминологию принятую в банке, фактически бизнес-инициатива является проектом.

В MSProject создается верхнеуровневая задача (проект) и устанавливается связь с бизнес-инициативой (задача «проекта JIRA»). Схематично представил на рисунке.

Эта реализация на мой взгляд оказалась очень удобной для формирования процессов управления проектами как в самой JIRA, так и для интеграции с процессами в других системах.

3.2. Продуктовые проекты в JIRA

Для каждого продуктового направления создан отдельный «проект JIRA» в котором компонуются эпики по этапам работ бизнес инициативы и задачи в разбивке по продуктовым направлениям. В MSProject этому эпику соответствует задача, иерархически связанная с проектом. Какие взаимосвязи у простого монопродуктового проекта показано на рисунке.

3.3. Сложные интеграционные\мультипродуктовые проекты.

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

Если нужно несколько этапов в рамках одной продуктовой команды – это обыгрывается отдельными эпиками в одном продуктовом проекте JIRA.

В MSProject это выглядит следующим образом – в нескольких продуктовых файлах создается отдельный проект и его этапы связываются с соответствующими эпиками.

Взаимосвязи такой реализации продемонстрированы на рисунке.

3.4. Ресурсные проекты в JIRA.

Отдельный вид проектов JIRA – это проекты подразделений, которые сами не реализуют бизнес-инициативы, но предоставляют свои ресурсы – тестировщиков, документаторов и т.д. Что бы их включить в план проекта – создаются задачи в MSProject, для которых автоматически генерируются задачи в JIRA и привязываются к эпикам продуктового проекта.

4. Итоги

Какие можно сделать выводы…

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

Однако есть возможность упрощения – от локальных файлов можно перейти к MSProject Server. Как-нибудь расскажу о специфике построения такой системы на примере консалтинговой компании, связанной с банковской автоматизацией.

Что касается настройки проектов JIRA - схема очень хороша с точки зрения дальнейшего построения системы управления проектами – лично мне это очень нравится, так как я сформировал несколько проектных офисов и при настройке процессов проектного управления каждый раз возникали проблемы с определением сущности проект в JIRA.

В данной схеме для задач в «проекте JIRA» настроена статусная модель советующая проектам – инициация, планирование и т.д. вплоть до закрытия. Это позволяет использовать JIRA как мастер-систему для сущности проект и легко интегрироваться с другими системам – базы знаний, хранения документов и документооборота, бухгалтерского и финансового учета.

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

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