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 как мастер-систему для сущности проект и легко интегрироваться с другими системам – базы знаний, хранения документов и документооборота, бухгалтерского и финансового учета.
Поэтому такую схему рекомендую использовать для компаний, в которых количество проектов превышает несколько десятков.
Не коснулся в статье организации процессов работы со сводным реестром портфеля проектов, т.к. это больше касается функционала проектного офиса и выходит за рамки статьи. Однако очевидно, что в данной архитектуре предоставляются широкие возможности, если добавить ещё несколько элементов.
