В статье Успешное планирование в ИТ консалтинге. Теория и практика использования JIRA и MSP / Хабр (habr.com) я рассказал про несколько уровней планирования проектов: краткосрочное планирование (спринты), планирование проектов\контрактов (календарный план), планирование загрузки ресурсов (ресурсный план), и наконец финансовое планирование (квартал, год и т.д.). А также коснулся реализации функциональной архитектуры систем календарного планирования первого и второго уровня. Опишу подробно как построен процесс календарного и оперативного планирования в связке JIRA<->MSProject на примере реализации в одном российском банке. Схема календарного планирования ИТ проектов в банке следующая – планы проектов сохраняются в локальных файлах MSProject, задачи из которых синхронизируются с задачами в одном экземпляре JIRA. Задачи в свою очередь, агрегируясь на рабочих панелях\в спринтах, представляют собой оперативные планы работ. Как организационно и технологически работает такая схема планирования наглядно показано на схеме. Продуктовые\проектные подразделения формируют у себя планы по своим проектам\портфелям проектов в локальном файле MSProject, каждый из которых состоит из нескольких тысяч строк и сотен проектов, что позволяет говорить о промышленном использовании решения. В таком файле настроена интеграция с единой JIRA, задачи в которой (или эпики) связаны по определенному соглашению об иерархии, которая детально описана в разделе «структура проектов в JIRA».  Ресурсные подразделения, являясь «наблюдателями» планов, контролируют сводную загрузку сотрудников по отчетности выгружаемой из JIRA в excel. Оперативные задачи сотрудников отслеживаются на рабочих столах\дашбордах – каждый может настроить себе самостоятельно. Выравнивание загрузки и решение ресурсных конфликтов проходит вместе с менеджерами продуктовых\проектных подразделений в MSProject. Информация сразу после этого загружается в JIRA, что обеспечивает актуальность отчетности. Сотрудники работают со своими задачами в JIRA и информация о результатах их деятельности (% выполнения, статус задачи, запрошенные новые сроки…) периодически загружается в MSProject, обеспечивая таким образом отслеживание динамики исполнения как по одному проекту, так и по всем проектам продуктового портфеля. Отчетность в данной схеме лучше всего получать из 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 и привязываются к эпикам продуктового проекта. Какие можно сделать выводы… Всё выглядит немного громоздко, однако в в схеме нет ничего лишнего, так как она содержит лишь необходимый набор инструментов для РП, ресурсных руководителей, руководителей компании - в части планирования работ и контроля процесса исполнения.   Однако есть возможность упрощения  – от локальных файлов можно перейти к MSProject Server. Как-нибудь расскажу о специфике построения такой системы на примере консалтинговой компании, связанной с банковской автоматизацией. Что касается настройки проектов JIRA - схема очень хороша с точки зрения дальнейшего построения системы управления проектами – лично мне это очень нравится, так как я сформировал несколько проектных офисов и при настройке процессов проектного управления каждый раз возникали проблемы с определением сущности проект в JIRA.  В данной схеме для задач в «проекте JIRA» настроена статусная модель советующая проектам – инициация, планирование и т.д. вплоть до закрытия. Это позволяет использовать JIRA как мастер-систему для сущности проект и легко интегрироваться с другими системам – базы знаний, хранения документов и документооборота, бухгалтерского и финансового учета. Поэтому такую схему рекомендую использовать для компаний, в которых количество проектов превышает несколько десятков. Не коснулся в статье организации процессов работы со сводным реестром портфеля проектов, т.к. это больше касается функционала проектного офиса и выходит за рамки статьи. Однако очевидно, что в данной архитектуре предоставляются широкие возможности, если добавить ещё несколько элементов. Управление проектным офисом, управление проектами.