1. Введение
Поработав в нескольких крупных ИТ компаниях на позициях руководителя проектного офиса, я поучаствовал в реализации различных архитектур управления проектами и портфелями проектов. Важную и проблемную часть при этом составляли системы планирования – при кажущейся простоте и широком спектре решений на рынке.
Проблема заключается в том, что планирование в компании - это несколько процессов:
краткосрочное планирование (спринты),
планирование проектов\контрактов (календарный план),
планирование загрузки ресурсов (ресурсный план),
и наконец финансовое планирование (квартал, год и т.д.).
Все эти процессы связанны между собой, но в практике не реализуются в одной информационной системе. Поэтому хочу поделиться о своем опыте промышленного внедрения и использования систем, удачных архитектурных решениях, которые в итоге позволили сделать более эффективными процессы управления проектами, бюджетирования и финансового планирования, благодаря интеграции различных процессов планирования.
2. Про планирование
Планирование является одним из важнейших процессов при управлении проектами разработки программного обеспечения (ПО).
Как правило, в процессах управления производством ПО центральное место занимает какой-нибудь трекер (конечно я не рассматриваю в данной статье и не имею ввиду среды разработки). Поэтому и оперативное планирование опирается на функционал трекера. Последние годы на рынке доминирует JIRA, хотя другие – такие как Redmine не уступают в функциональности. Но рынок есть рынок.
Но для планирования проектов функционала системы трекеров не достаточно, поэтому в ИТ консалтинговых компаниях (особенно которые работают с внешними заказчиками на контрактных условиях) планирование строится на базе промышленных систем, а иногда и просто в excel.
В производстве ПО уже десятилетие культивируется Agile, но в инструментах автоматизации процессов планирования существует разрыв, сложившийся по какой-то причине в ходе развития рынка. Системы календарные планирования ориентированные на создание диаграммы Ганта, такие как MSProject, Primavera, Spider и т.п., существуют давно. В них достаточно развиты инструменты календарного и ресурсного планирования, но отсутствуют возможности, присущие трекерам таким как JIRA, Redmine, TeamTrack – например движение задачи по статусам, формирование оперативных планов (спринтов), панели и dashboard для команды, связи с другими задачами и т.д.
Поэтому разумно выделяется несколько уровней планирования – о них детально рассказываю ниже. На каждом уровне переплетаются процессы взаимосвязанные друг с другом: планирование производства, проектов и финансовое планирование.
А руководителям компании интересно контролировать финансовый план компании, который собирается из всех проектных и процессных активностей. И чаще всего просто в exсel.
3. Уровни планирования
Расскажу более детально о процессах\уровнях планирования. На практике выделяется несколько уровней которые необходимы для дальнейшего управления процессами командами, проектами, компанией.
Первый– самый детальный – уровень описания конкретных требований для аналитика, фичи для разработчиков, тестировщиков, документаторов. На этом уровне оперируют недельными планами, которые можно называть спринтами (не затрагивая в деталях идеологию agile). На этом уровне анализируется бэклог одного или нескольких проектов для формирования плана работ обычно для одной команды. В терминах PMBoK это разработка расписания для проекта. Ключевая специфика – это короткий горизонт планирования и планирование набегающей волной.
Второй – уровень проекта – здесь фиксируются ключевые вехи, планируются все активности и задачи, которые входят в проект, без детализации первого уровня.
Третий – планирование загрузки подразделения на период – обычно месяц, квартал, год. План собирается из всех проектов второго уровня и процессов, в которых задействованы ресурсы подразделения, включая обеспечение саппорта, процессы обучения, непроизводственные процессы и т.д. Специфика данного планирования заключается в необходимости формирования загрузки ресурсов подразделения близкой к 100%. На практике этот уровень резервирует ресурсы и показывает проблемные точки загрузки для решения вопросов утилизации.
Четвертый – финансовый план уровня компании, который собирается из планов третьего уровня, и формируется в разрезе подразделений. Ключевая особенность в том, что на этом уровне сводятся и сопоставляются доходы по проектам (второй уровень планирования) с расходами компании (третий уровень планирования).
4. Функциональные архитектуры систем планирования
Остановлюсь сегодня детально на рассмотрении вариантов архитектуры первого и второго уровня планирования, которые фактически являются основой для последующих.
Небольшая ремарка - JIRA плюс GIT c Bitbucket дают на текущий момент широкие возможности по организации процесса разработки и выпуска продукта. При этом в самой JIRA не очень развиты инструменты, нацеленные на планирование больших проектов.
Несколько реализаций в виде плагинов в JIRA, пытающихся повторить функционал, давно реализованный в системах планирования, таких как MSProject, Primavera, Spider и т.п. можно назвать лишь потугами. Да и смысл повторять функционал таких мощных специализированных систем на мой взгляд отсутствует.
Как уже рассказал выше первый уровень планирования в текущих ИТ компаниях прочно занимает какой-нибудь трекер, второй уровень – система календарного планирования. Эффективный процесс можно постройтесь, если интегрировать данные системы.
Хорошие варианты интеграции систем планирования и трекеров мне пришлось наблюдать и в разной степени принимать участие в реализации в таких компаниях интеграторах как БИС, БФТ и РСХБ. Расскажу об архитектуре, различиях и особенностях построения процессов.
4.1. Планирование проектов в трекере
В БФТ мы приняли решение разработать функционал планирования в виде плагина JIRA – это был интересный опыт. На тот момент, когда я уходил из компании в плагине был разработан функционал создания задач с ресурсным таймлайном на сотрудников на заданный период с заданной трудоемкостью. Первый шаг к MSProject -). Сильной стороной архитектуры была интеграция с 1С в части плановых и фактических ресурсных затрат по проектам – это позволяло шагнуть вперед в части формирования финансовых планов по компании в разрезе продуктов и ресурсных центров.
4.2. Централизованное планирование проектов трекер-MSP.
В БИС и РСХБ схему планирования реализовали, используя интеграцию трекера и MSProject. Это решение требует на 2 порядка меньше разработки и сразу дает возможность пользоваться функциями обеих систем и переходить к построению процесса разработки, а не прикладывать титанические усилия для внутренней автоматизации планирования.
В БИС в качестве трекера использовался TeamTrack, все задачи заводились в нем, а в MSProject вручную строилась иерархия и вручную вносились номера задач. После планирования конкретных задач сроки автоматически передавались в задачу TeamTrack. Информация об исполнении передавалась обратно в MSProject. Вот и весь процесс, который позволял централизованно планировать производственные ресурсы всей компании – все гениальное просто.
4.3. Трекер+локальный MSP
В РСХБ тоже используется интеграция JIRA <-> MSProject. При этом каждый руководитель ресурсного центра (являясь при этом РП конкретных проектов или программ\портфелей) создает свой локальный план в MSProject. Минусы такой системы поняты – нужно постоянно синхронизировать расхождения (по срокам, списку задач и загрузке), т.к. одни и те же ресурсы могут использоваться в различных проектах MSProject.
Теперь о плюсах - задачи из MSProject можно в автоматизированном режиме создавать в JIRA. При создании задач используется соглашение об иерархии основанное на структуре проектов в JIRA в РСХБ. Соответствие иерархии задач выглядит примерно так как на рисунке:
При этом всего три интеграционных сервиса позволяют выполнить все работы по планированию и контролю планов в связке MSProject<->JIRA:
Создание задач из MSProject в JIRA.
Это позволяет легко превращать план в MSProject в иерархически скомпонованный перечень задач в JIRA со сроками нужными для проекта и назначенными ресурсами, а так же при необходимости обновлять информацию процессом MSProject->JIRA.
Обновление конкретных задач JIRA ->MSProject.
Позволяет обновлять информацию в MSProject по фактическому исполнению назначенных задач по статусам, срокам, ресурсам, указанным в JIRA и в итоге - контролировать финальные сроки проекта.
Загрузка новых задач JIRA->MSProject.
Позволяет при необходимости выгружать в MSProject из JIRA перечень привязанных к выбранной задаче (или эпику) задач в виде иерархии.
Какая из описанных 1.-3. архитектур вам подойдет больше – нужно решать в зависимости от текущего бизнес и ИТ ландшафта, но для планирования проектов архитектура в которой интегрируются система трекинга и система календарного планирования оказалась максимально эффективной, т.к. позволила срастить современные agile подходы планирования работы команды и потребности проектного офиса в части планирования проектов.
