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