1. Введение Поработав в нескольких крупных ИТ-компаниях руководителем проектного офиса, я принимал участие во внедрении различных архитектур управления проектами и портфелей проектов.
Важной и проблемной частью было системы планирования – несмотря на кажущуюся простоту и широкий выбор решений, представленных на рынке.
Проблема в том, что планирование в компании состоит из нескольких процессов: 
- краткосрочное планирование (спринты),
- планирование проекта/контракта (график),
- планирование загрузки ресурсов (ресурсный план),
- и, наконец, финансовое планирование (квартал, год и т. д.).
Поэтому хочу поделиться своим опытом промышленное внедрение и использование систем удачных архитектурных решений, что в конечном итоге позволило сделать процессы управления проектами, бюджетирования и финансового планирования более эффективными, благодаря интеграции различных процессов планирования.
2. О планировании
Планирование является одним из наиболее важных процессов при управлении проектами разработки программного обеспечения ( К ).Как правило, в процессах управления производством ПО центральное место занимают некоторые трекер (разумеется, в этой статье я не рассматриваю и не имею в виду среды разработки).
Поэтому оперативное планирование основывается на функциональности трекера.
В последние годы на рынке доминирует JIRA, хотя и другие, например Redmine, по функциональности не уступают. Но рынок есть рынок.
Но для планирования проектов функциональности системы не хватает трекеров Поэтому в ИТ-консалтинговых компаниях (особенно тех, которые работают с внешними заказчиками на договорных условиях) планирование ведется на основе промышленных систем, а иногда и просто в Excel. В производстве К Agile культивируется уже десять лет, но в инструментах автоматизации процессов планирования.
есть пробел , образовавшийся по каким-то причинам в ходе развития рынка.
Системы планирования, ориентированные на создание диаграммы Ганта, такие как MSProject, Примавера, Паук и так далее.
, существуют уже давно.
У них есть достаточно развитые инструменты календаря и планирования ресурсов, но им не хватает возможностей, присущих трекерам, таким как JIRA, Redmine, TeamTrack — например, перемещение задачи по статусу, формирование операционных планов (спринтов), панелей и дашбордов для команды, связи с другими задачами и т. д. Поэтому он выделяется разумно несколько уровней планирования – О них я подробно рассказываю ниже.
На каждом уровне переплетаются взаимосвязанные процессы: планирование производства, проектное планирование и финансовое планирование.
А менеджеры компании заинтересованы в контроле финансового плана компании, который собирается по всем проектным и процессным мероприятиям.
И чаще всего просто в Excel.
3. Уровни планирования
Расскажу подробнее о процессах/уровнях планирования.На практике существует несколько уровней, которые необходимы для дальнейшего управления процессами командами, проектами и компаниями.
Первый – наиболее подробный – уровень описания конкретных требований для аналитика, возможностей для разработчиков, тестировщиков и документаторов.
На этом уровне они оперируют еженедельными планами, которые можно назвать спринтами (не касаясь подробно идеологии Agile).
На этом уровне анализируется отставание одного или нескольких проектов для формирования плана работы, обычно для одной команды.
В терминах PMBoK это разработка графика проекта.
Ключевые особенности – короткий горизонт планирования и планирование накатывающей волной.
Второй — уровень проекта — здесь фиксируются ключевые вехи, планируются все мероприятия и задачи, входящие в проект, без детализации первого уровня.
Третий — планирование загрузки отдела на период — обычно месяц, квартал, год. План составляется из всех проектов и процессов второго уровня, в которых задействованы ресурсы подразделения, включая обеспечение поддержки, процессы обучения, непроизводственные процессы и т.д. Специфика этого планирования заключается в необходимости создания единичной ресурсной нагрузки, близкой до 100%.
На практике этот уровень резервирует ресурсы и показывает проблемные точки погрузки для решения вопросов утилизации.
Четвертый – финансовый план уровня компании, который собирается из планов третьего уровня и формируется по подразделениям.
Ключевой особенностью является то, что на этом уровне доходы проекта (второй уровень планирования) объединяются и сравниваются с расходами компании (третий уровень планирования).
4. Функциональные архитектуры систем планирования.
Сегодня я подробно остановлюсь на рассмотрении вариантов архитектуры первого и второго уровней планировки, которые собственно и составляют основу последующих.
Небольшое замечание — JIRA плюс GIT с Bitbucket на данный момент предоставляют широкие возможности для организации процесса разработки и выпуска продукта.
При этом сама JIRA не имеет сильно развитых инструментов, направленных на планирование крупных проектов.
Несколько реализаций как плагины в JIRA , пытаясь повторить функционал, давно реализованный в системах планирования, таких как MSProject, Primavera, Spider и др.
можно назвать только попытками .
И на мой взгляд нет смысла повторять функционал столь мощных специализированных систем.
Как уже было сказано выше Первый уровень планирование в нынешних ИТ-компаниях прочно занято некоторыми трекер , второй уровень – система планирования .
Эффективный процесс можно построить, если интегрировать эти системы.
Мне приходилось наблюдать хорошие варианты интеграции систем планирования и трекеров и в той или иной степени принимать участие во внедрении в таких компаниях-интеграторах, как БИС, БФТ и РСХБ .
Расскажу об архитектуре, отличиях и особенностях процессов сборки.
4.1. Планирование проекта в трекере
В БФТ мы решили разработать функционал планирования в виде Плагин JIRA - Это был интересный опыт. На момент моего ухода из компании в плагине был развит функционал по созданию задач со сроками ресурса для сотрудников на заданный период с заданной трудоемкостью.Первый шаг к MSProject -).
Сила архитектура была интеграция с 1С по плановым и фактическим затратам ресурсов по проектам – это позволило сделать шаг вперед в плане формирования финансовых планов компании в разрезе продуктов и ресурсных центров.
4.2. Централизованный трекер планирования проектов-MSP.
В БИС и РСХБ схема планировки была реализована с использованием интеграция трекера и MSProject .Данное решение требует на 2 порядка меньше разработки и позволяет сразу использовать функции обеих систем и перейти к построению процесса разработки ПО, а не прилагать титанические усилия по внутренней автоматизации.
Используется как трекер TeamTrack , в нем запускались все задачи, а в МСПроект Иерархия строилась вручную, номера задач вводились вручную.
После планирования конкретных задач сроки автоматически переносились в задачу TeamTrack. Информация о выполнении была передана обратно в MSProject. Вот и весь процесс, позволивший централизованно планировать производственные ресурсы всей компании – все гениальное просто.
4.3. Трекер+локальный MSP
В РСХБ интеграция также используется ДЖИРА <-> МСПроект .
В этом случае каждый менеджер ресурсного центра (являющийся RP конкретных проектов или программ/портфелей) создает в MSProject свой локальный план.
Минусы такой системы очевидны — нужно постоянно синхронизировать расхождения (по срокам, списку задач и загруженности), ведь одни и те же ресурсы могут использоваться в разных MSProjects. Теперь о плюсы - задания из МСПроект может быть автоматически создан в ДЖИРА .
При создании задач используйте соглашение об иерархии на основе структуры проектов в JIRA в РСХБ.
Соответствие иерархии задач выглядит примерно так: 
При этом всего три сервиса интеграции позволяют выполнить всю работу по планированию и мониторингу планов в MSProject.<-> Соединение JIRA:
- Создание задач из MSProject в JIRA.
- Обновление конкретных задач JIRA -> MSProject.
- Загрузка новых задач JIRA-> MSProject.
Что из описанного 1.-3. архитектуры вам подойдут больше - решать нужно в зависимости от текущего бизнеса и ИТ-ландшафта, но для планирования проекта архитектура, объединяющая систему отслеживания и систему планирования, оказалась наиболее эффективной, т.к.
позволила объединить современные гибкие подходы к планированию работы команды и потребности проектного офиса в плане планирования проекта.
Теги: #Управление разработкой #Управление проектами #проекты #ИТ-компании #ИТ-компании #agile #планирование #Jira #atlassian #msproject
-
Знакомство С Vmware Vcloud Director
19 Oct, 24 -
Алгоритм Жизни С Техническим Складом Ума
19 Oct, 24 -
Скажите Caps Lock «Нет»
19 Oct, 24
