Успешное планирование в ИТ консалтинге. Теория и практика использования JIRA и MSP

Поработав в нескольких крупных ИТ компаниях на позициях руководителя проектного офиса, я поучаствовал в реализации различных архитектур управления проектами и портфелями проектов. Важную и проблемную часть при этом составляли системы планирования – при кажущейся простоте и широком спектре решений на рынке.

Проблема заключается в том, что планирование в компании — это несколько процессов:

краткосрочное планирование (спринты),

планирование проектовконтрактов (календарный план),

планирование загрузки ресурсов (ресурсный план),

и наконец финансовое планирование (квартал, год и т.д.).

Все эти процессы связанны между собой, но в практике не реализуются в одной информационной системе. Поэтому хочу поделиться о своем опыте промышленного внедрения и использования систем, удачных архитектурных решениях, которые в итоге позволили сделать более эффективными процессы управления проектами, бюджетирования и финансового планирования, благодаря интеграции различных процессов планирования.

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 подходы планирования работы команды и потребности проектного офиса в части планирования проектов.

ИТ-стратегия

С точки зрения современного менеджмента под стратегией понимается долгосрочный (как правило, многолетний) план действий, направленный на развитие компании и достижение определенных результатов ее деятельности, как правило — тех или иных конкурентных преимуществ и финансовых показателей (то есть некоторого целевого состояния компании). Потребность в стратегическом планировании обычно возникает из-за быстрого изменения бизнес-условий.

Под ИТ-стратегией обычно подразумевается долговременный план действий по развитию информационных технологий в компании (то есть ее ИТ-инфраструктуры, информационных систем, ИТ-подразделения). ИТ-стратегия является важной частью корпоративной стратегии, однако современные реалии таковы, что обычно ее разработке уделяется очень мало внимания, и только после некоторого количества сделанных ошибок и впустую потраченных средств руководство компании начинает задумываться о стратегическом планировании в области ИТ.

Подходы к планированию развития ИТ

Существует несколько различных подходов к разработке ИТ-стратегий — от полнейшего отсутствия четких планов и финансирования ИТ по остаточному принципу до взвешенного увязывания планов развития ИТ с планами развития бизнеса.

Наиболее распространенным подходом является, пожалуй, планирование наращивания мощности технических средств без четкого определения целей подобных действий. Не будучи стратегией в прямом смысле этого слова, указанный подход более или менее оправдан для компаний, имеющих стабильные и неизменные процессы и не сталкивающихся с угрозой вытеснения их с рынка конкурентами (например, для государственных предприятий, имеющих монополию на определенные виды деятельности).

Несколько реже применяется подход, также не являющийся стратегическим и основанный на попытках внедрять новейшие технологии без учета реальной потребности в них и без планирования как такового. Этот подход может оказаться весьма рискованным и дорогостоящим в реализации, поэтому позволить его себе могут лишь немногие компании.

Еще один подход, намного более взвешенный и менее экстремальный, нежели предыдущий, заключается в выявлении наиболее значимых сфер деятельности компании и в первоочередном осуществлении их автоматизации. При указанном подходе очень важно выделить самые главные области (при этом далеко не всегда у руководства компании есть полное согласие по этому вопросу). Указанный подход получил широкое распространение в некоторых западных странах в начале и середине 1990-х годов. Одним из классических подходов к формированию ИТ-стратегии является ее создание на основе уже имеющейся бизнес-стратегии. В этом случае для ИТ-подразделения, точно так же как и для других подразделений компании, разрабатывается план, поддерживающий стратегию всей компании, с учетом того, что ИТ-подразделение является вспомогательной службой, поддерживающей основные бизнес-процессы компании.

Более прогрессивным и эффективным в последнее время считается подход, основанный не просто на рассмотрении ИТ-подразделения как одного из отделов компании, но и на учете влияния информационных технологий на развитие бизнеса как фактора, способного предоставить бизнесу дополнительные стратегические преимущества. Именно этот подход рекомендован в книгах библиотеки ITIL Information Technology Infrastructure Library. В рамках этого подхода разработка ИТ-стратегии представляет собой анализ бизнес-процессов компании и необходимость их автоматизации, формулируется миссия, цели и задачи ИТ-подразделения и на их основе производится определение основных направлений развития в областях оказания ИТ-услуг, ИТ-инфраструктуры и бизнес-приложениq, кадрового состава и оргструктуры информационной службы.

Что дает компании создание ИТ-стратегии

Отсутствие ИТ-стратегии чаще всего приводит к тому, что ИТ-подразделение занимается в основном выполнением проектов, не связанных напрямую ни со стратегическими целями компании, ни друг с другом и решающих узкоспециализированные локальные задачи, а также «латанием дыр» (именно на это чаще всего уходит большая часть ИТ-бюджета многих компаний), образующихся в результате уже завершенных подобных проектов и сформировавшегося с их помощью «зоопарка» технологий. При этом отдача от инвестиций в подобные проекты, поскольку таковые выполняются без учета требований развития бизнеса, может оказаться более чем сомнительной. Кроме того, подобная ситуация вызывает негативное и пренебрежительное отношение сотрудников компании к специалистам ИТ-подразделений и их деятельности, а сами они, какими бы высококвалифицированными ни были, начинают рассматриваться как обслуживающий персонал, а не как полноправные участники развития бизнеса.

Наличие ИТ-стратегии, представленной в виде формализованного документа, позволяет эффективно развивать ИТ-инфраструктуру на основе корректного представления требований, которые следует реализовать для успешного развития бизнеса компании, а также выполнять заранее запланированные шаги, продвигаясь к достижению намеченных целей. Стратегия должна быть инструментом принятия тактических решений, соответствующих бизнес-целям компании.

Отметим, однако, что в условиях постоянно изменяющегося рынка ИТ-стратегия также может модифицироваться, при этом данный процесс также желательно формализовать.

В подобной ситуации в штате ИТ-подразделения должны быть не только системные администраторы и разработчики, но и бизнес-аналитики, способные оценивать текущее состояние дел компании, прогнозировать развитие ее бизнеса, описывать бизнес-процессы компании, предлагать способы их усовершенствования и на основе этих сведений формулировать требования к будущим ИТ-проектам.

Естественно, для реализации ИТ-стратегии ИТ-подразделение нуждается в понимании и поддержке со стороны руководства компании. Основная проблема в данном случае заключается в том, что реализация ИТ-проектов очень часто воспринимается как очередное выбрасывание средств на ветер, любые ошибки сотрудников ИТ-подразделений сразу замечаются другими сотрудниками, тогда как при наличии успешно работающей ИТ-инфраструктуры и бизнес-приложений работа, проводимая по их поддержке, обычно остается незамеченной. Обоснование ИТ-бюджета и, что более существенно, доказательство реальной отдачи инвестиций в ИТ, сейчас считается чуть ли не искусством, доступным далеко не каждому руководителю ИТ-подразделения. Критерии оценки успеха того или иного ИТ-проекта зачастую плохо формализуются, и это увеличивает их субъективность — ведь корректно оценить вклад информационных технологий как таковых в успех всего бизнеса не всегда представляется возможным.

Что должно быть определено в ИТ-стратегии

В первую очередь в документе, отражающем ИТ-стратегию, должны быть сформулированы цели и задачи бизнеса компании, реализуемые с помощью информационных технологий, на их основе должны быть определены долгосрочные цели и направления развития информационных технологий в компании и функций ИТ-подразделения. В этом же документе должны быть отражены концептуальные подходы к реализации различных стратегических задач (например, какие из задач отдаются на аутсорсинг). Наконец, на основе анализа современного состояния информационных технологий и ИТ-подразделения следует определить план достижения их целевого состояния и сформулировать критерии оценки успешности реализации этапов этого плана.

При этом стоит заметить, что ИТ-стратегия — это концептуальный документ, который не должен содержать излишних технических подробностей, поскольку его аудиторией являются не только ИТ-специалисты. Все технические детали реализации проектов, описание организационных процедур, спецификации технических средств могут содержаться в приложениях к ИТ-стратегии или в иных документах [1] .

В заключение отметим, что затраты на разработку ИТ-стратегии независимо от того, выполняется она самими сотрудниками компании или специалистами сторонней консалтинговой фирмы, оказываются значительно ниже, чем расходы на решение проблем, связанных с ее отсутствием. Однако разработка ИТ-стратегии вряд ли имеет смысл без участия в этом процессе ИТ-директора и руководства компании. Бессмысленна она и при отсутствии бизнес-стратегии — в этом случае, возможно, стоит ограничиться рассмотренным в начале статьи подходом, основанным на планировании роста вычислительных мощностей, или выбором наиболее приоритетных областей деятельности для автоматизации.

Хронология событий

2020: Abbyy: более половины российских компаний изменили ИТ-стратегию в 2020 году

18 декабря 2020 года ABBYY, мировой разработчик решений в области интеллектуальной обработки информации и анализа бизнес-процессов, сообщил о завершении исследования «Как изменились бизнес-процессы российских компаний в 2020 году». По его результатам оказалось, что в течение года 57% компаний были вынуждены изменить ИТ-стратегию. 65% респондентов отметили, что целью большинства инновационных проектов в 2021 году станет повышение эффективности бизнеса, а 51% подчеркнули важность привлечения новых клиентов и увеличения продаж. При этом, несмотря на декларируемую цифровую трансформацию, большинство компаний используют для подготовки к внедрению технологий традиционные методы: 54% респондентов опрашивают сотрудников. Только 9% российских компаний используют для этой задачи интеллектуальный анализ бизнес-процессов. Больше всего таких респондентов – среди представителей банков и телекоммуникаций.

Опрос респондентов проводился в ноябре 2020 года, в исследовании участвовали руководители и сотрудники более 300 промышленных предприятий, телеком-операторов, банков, ритейлеров и других компаний. Одной из наиболее перспективных технологий оказалась роботизация бизнес-процессов (Robotic Process Automation, RPA). Более половины респондентов сообщили, что уже внедрили роботов или планируют использовать RPA в ближайшее время. Это соответствует и результатам глобального исследования ABBYY, по данным которого 46% сотрудников крупных организаций используют роботов не менее 2 часов в день для задач классификации документов и обработки информации. При этом 30% опрошенных ABBYY компаний отмечают, что одним из ключевых препятствий для внедрения роботов является невозможность оценить потенциальную эффективность проекта.

Несмотря на возросшую роль технологий во всех бизнес-процессах, заметен неоднородный характер цифровизации российских компаний. Так, более 32% респондентов сообщили о планах по развитию CRM-систем, а еще 22% – ECM-систем. Больше всего таких респондентов было среди представителей малого и среднего бизнеса. Крупные компании отметили в качестве приоритетных решений RPA, решения на базе NLP, корпоративный поиск и платформы Process Intelligence.

Источник https://habr.com/ru/post/571862/

Источник https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%98%D0%A2-%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D1%8F

Источник

Источник