В статье рассматриваются ключевые аспекты управления программным проектом, способствующие контролю его реализации, оптимизации расходов ресурсов, достижению конечных целей. Менеджмент IT проектов обусловлен необходимостью реализации практических методов планирования работ на основе проектного управления и средств мониторинга организационных процессов.
Постановка проблемы и ее связь с важными научными или практическими заданиями. В настоящее время в сфере информационных технологий нередко возникает ситуация, когда запланированные сроки и бюджет проектов не соответствуют реальным. Неэффективное планирование работ вызывает увеличение временных и материальных затрат проекта, усложняет процесс его течения и приводит к возникновению разногласий и конфликтов с заказчиком. Основными в данном случае являются процессы планирования и мониторинга, которые определяют состояние текущих процессов в проекте и способы достижения целей. Применение средств менеджмента для управления проектом способствует контролю процесса его реализации, расходов ресурсов, достижению конечных целей [1, с.4].
В то же время, следует отметить, что применение зарубежных методик в Казахстане не всегда может оказаться эффективным. Приходится констатировать, что Республика Казахстан еще достаточно отстает от зарубежных стран по уровню менеджмента, несмотря на наблюдающиеся положительные тенденции. Возрастает необходимость применения методологий управления IT проектами в организации работ, а также реализации практических методов планирования работ на основе проектного управления и средств мониторинга организационных процессов, которые отвечали бы современным требованиям к обеспечению качества.
Анализ последних публикаций по проблеме.
В целом вопросы комплексной автоматизации организаций, в том числе вопросы риска нашли свое отражение в отечественной и зарубежной литературе, однако, часто предложения авторов носят общий характер или ориентированы на внедрение корпоративных информационных систем управления ресурсами предприятия (ERP), недостаточно учитывают российскую специфику ведения подобных проектов [2, с.67].
Актуальность и неоднозначность решения проблемы управления ИТ-проектов, недостаточная разработанность проблемы в литературе определили выбор темы научного исследования, его цель и задачи.
Определение отдельных открытых вопросов. В силу относительно недавнего появления и высоких темпов развития информационных технологий, практика управления рисками бурно развивающихся и совершенствующихся систем, которые используют предприятия для повышения собственной конкурентоспособности, значительно опережает теорию.
Анализ опубликованных работ свидетельствует о том, что проблема управления рисками при автоматизации предприятия в той или иной степени получила отражение в сравнительно небольшом количестве научных трудов. Их основу составляют фундаментальные работы в области теории риска, отдельные аспекты отражены в научных исследованиях в области экономики предприятия, финансового менеджмента и ряда экономикоматематических дисциплин.
Основные особенности управления программными проектами заключаются в следующем:
- - программный продукт не материален, его нельзя увидеть в процессе конструирования и, следовательно, оперативно повлиять на его реализацию;
- - жизненный цикл ПП в существующих стандартах описан в общем виде и прямо не ориентированы на специфику конкретного продукта, необходимо адаптировать их к виду и типу проекта и разработать методики их выполнения исполнителями;
- - программные продукты как результаты творческого труда не поддаются точному оцениванию, как по времени создания, так и по требуемому бюджету.
Следует различать следующие понятия: цели, результаты, ограничения и допущения.
Цель проекта описывает, какие задачи должны быть решены в результате проекта, желаемый результат, достигнутый в пределах некоторого интервала времени, другими словами отвечать на вопрос, зачем данный проект нужен, какие потребности бизнеса он удовлетворяет [3, с.34].
Например, целями проекта могут быть:
- - разработка программного обеспечения под потребности бизнеса конкретного заказчика;
- - доработка программного продукта в целях приведения его в соответствие с изменениями в законодательстве.
Цели должны быть значимыми, конкретными, измеримыми и достижимыми. Четкое определение бизнес-целей важно, поскольку существенно влияет на все процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Например, если реальные затраты на проект будут превосходить будущие доходы от его реализации.
Результаты проекта отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять: какой продукт или услуга будут получены по окончании проекта; краткое описание и при необходимости ключевые свойства и/или характеристики продукта/ услуги.
Следует помнить, что результаты проекта должны быть измеримыми. Это означает, что при оценке результатов проекта должна иметься возможность сделать заключение достигнуты оговоренные в концепции результаты или нет.
Ограничения являются неотъемлемой частью проекта и сокращают возможности проектной команды в выборе решений. В частности они могут содержать:
- - требования обязательной сертификация продукта, услуги на соответствие определенным стандартам;
- - требования на использование конкретной заданной программно-аппаратной платформы;
- - специфические требования к защите информации.
Допущения, как правило, тесно связаны с управлением рисками, о которых заказчик должен знать заранее, например, оценивая проект по схеме с фиксированной ценой, можно записать в допущении предположение о том, что стоимость лицензий на ПО приобретаемое на стороне не изменится до завершения проекта [4, с.27].
Цели и задачи исследования. Основной целью диссертационного исследования является разработка теоретических, организационных и методических положений по управлению ИТ- проектами повышения эффективности функционирования в целом.
Для достижения поставленной цели, были поставлены и решены следующие основные задачи:
- - выявить тенденции в развитии рынка ИТ- проектов, систематизировать. и описать рискообразующие факторы при их реализации;
- - на основе исследования существующих подходов к классификации рисков ИТ-проектов предложить их классификацию для предприятий малого и среднего бизнеса;
- - провести комплексный анализ причин возникновения рисков при реализации ИТ-проектов в организациях, на основе которого определить их особенности, а также условия предотвращения.
- - разработать и обосновать теоретические основы управления ИТ-проектами в организациях;
- - предложить метод оценки эффективности внедрения ИТ-проектов в организациях;
Основные результаты исследования и их обоснование. Каждый программный продукт, даже если он повторяет уже существующий, является в чем-то уникальным. И каждый проект по разработке ПО также является уникальным. В настоящее время нет единой правильной организации разработки программ. Процесс в каждом новом проекте в соответствии с "Законом 4-х П" (рис.1) должен быть определен заново, в зависимости от персонала, проекта и продукта.
Конечно, проект зависит от количества участников в нем, и совершенно по-разному должны быть организованы процессы в проектах, в которых участвуют 5 человек и в тех, в которых задействованы 100 человек.
Управление проектом - это руководство действиями команды исполнителей проекта для выполнения проекта с использованием общих методов планирования и мониторинга работ (видение будущего продукта, начальные операции, планирование итераций, мониторинг и отчетность), планирование и управление рисками, эффективной организацией работы команды и коммуникационными потоками в команде исполнителей.
В соответствии с действующими стандартами выделяют 9 процессов по управлению проектами.
Каждый процесс состоит из некоторого набора работ. Кроме того, выделяют пять фаз жизненного цикла проекта. К ним относятся: инициация, планирование, исполнение, мониторинг и управление, завершение. Все процессы по управлению проектом связаны друг с другом. Фазы процессов проекта могут накладываться по времени [5, с.27].
В государственном стандарте приведены 9 процессов (областей знаний) по управлению проектами, каждый из которых состоит из определенного набора работ, и пять этапов (фаз) жизненного цикла проекта: инициация, планирование, исполнение, мониторинг и управление, завершение. При этом процессы взаимосвязаны, а этапы проекта могут накладываться во времени друг на друга.
На этапе инициации проекта осуществляется выбор и обоснование вида производимого программного продукта. Необходимо определить сферу распространения программного продукта, после чего разрабатывается и утверждается концепция проекта. Этот этап является одним из важнейших и недостаточное внимание к нему может повлиять на планирование, реализацию и завершение проекта.
Планирование программного проекта является вторым этапов после его инициации. Планирование является подготовкой к деятельности по разработке программного продукта. Оно включает в себя определение структурного состава работ по проекту, распределение ресурсов в зависимости от объемов финансирования и временных затрат всего проекта и отдельных видов его работ. Как правило, планирование ведется на основе двух методов - метод критического пути - CPM (Critical Path Method) и метод анализа и оценки программ PERT (Program Evaluation and Review Technique).
Конечно, спланировать течение проекта полностью не представляется возможным и большая редкость, когда проект реализуется в соответствии с первоначальными планами. Для контроля хода выполнения проекта важной составляющей является мониторинг состояния проекта, который должен осуществляться периодически. В рамках мониторинга необходимо производить анализ причин отклонения от первоначального плана выполнения работ и разрабатывать корректирующие воздействия. Одним из способов мониторинга является периодический опрос руководителей проекта о состоянии работ.
Завершение проекта представляет собой фиксацию результатов после передачи разработанного программного продукта в эксплуатации. Этот этап включает в себя опытную эксплуатацию или приемо-сдаточные испытания программы с целью доказательства соответствия ее свойств требованиям заказчика. Критерии приема готового программного продукта должны свидетельствовать о достижении целей проекта. Они должны отражать числовые значения характеристик программы, чтобы можно было сделать однозначные выводы о соответствии их необходимым требованиям. Процедура приема- сдачи программы должна оформляться с помощью специальных документов - программы и методики испытаний программы. Завершение проекта наступает в двух случаях. Первый - когда цели проекта достигнуты, второй - когда ситуация показывает, что цели проекта не могут быть достигнуты или проект потерял свою актуальность и необходимость в реализации.
Структура декомпозиции работ проекта (Work Breakdown Structure, WBS) является ключевым элементом борьбы со сложностью программных систем. Сложные проекты выполняются коллективами разработчиков а это значит, что необходимы определенные методики декомпозиции проекта на отдельные работы (задания) выполняемые командой проекта и распределение работ и ответственность между членами коллектива. Основной операцией декомпозиции является разбиение целого на части. При этом работа определяет достижение промежуточного результата, а задачи являются комплексами действий для достижения этих результатов. Глубина детализации зависит от конкретного проекта, культуры управления, стандартов жизненного цикла, специфики и масштабов проекта, а также других факторов, уникальных как в контексте конкретной организации, так и конкретного проекта.
В существующих стандартах нет четких рекомендаций по тому, как при декомпозиции выделять элементы следующего уровня. Переход от чисто эмпирического умозрительного подхода деления целого на части к формализованному, возможен при использовании формальных моделей декомпозиции [6, с.84].
Формирование состава элементов целесообразно производить, основываясь на отечественных и международных стандартах на разработку программных систем.
Так основываясь на ГОСТ (СТ СЭВ) 19.101-77 (1626-79) ЕСПД, виды программ и программных документов в качестве содержательной модели состава проекта целесообразно использовать следующие элементы:
- программный продукт - совокупность двух и более программных компонентов, реализующих конкретный бизнес-процесс;
- программный компонент - совокупность программных кодов, реализующих элементарную функцию бизнес-процесса и применяемая самостоятельно или в составе программного продукта.
Компонентами могут быть как прикладные подсистемы, так и инфраструктурные, например, подсистема безопасности, библиотека визуальных компонентов и т. д.
Содержательные модели жизненного цикла разработки программного проекта могут быть представлены в нескольких вариантах. Например, ГОСТ 19.102-77 предусматривает следующие стадии разработки: техническое задание, эскизный проект, технический проект, рабочий проект, внедрение.
ГОСТ (СТ СЭВ) 19.201-78 (1626-79) ЕСПД "Техническое задание. Требования к содержанию иоформлению подготовка технического задания" предусматривает проведение предпроектного обследования, разработку функциональных требований, требований к базовому ПО, оборудованию и системному ПО, определение сроков и ресурсов на реализацию проекта, согласование и утверждение ТЗ.
Согласно ГОСТ Р ИСО/МЭК 12207-99 "Процессы жизненного цикла программных средств" модель жизненного цикла -это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования .
В [4] отмечается, что при составлении плана реализации проекта не стоит его максимально детализировать. Если проект содержит слишком много уровней, менеджеры проекта сталкивается с проблемой размерности.
В методологии по управлению IT-проектами Microsoft Solu-tions Framework (MSF) компании Microsoft под риском проекта понимается событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта, отмечается, что риски не есть проблемы.
Управление рисками начинается с исследования понятий, способствующих одобрению программного проекта. Хороший менеджер проекта должен хорошо справляться с оценкой и управлением рисками. Возникающими при разработке программ. Управление рисками охватывает весь жизненный цикл разработки вплоть до сдачи проекта.
Цель управления рисками - максимизировать их положительное влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки). К минимизации рисков стремятся все потенциальные участники проекта: разработчики (поставщики) ПП, заказчики (потребители), а также предполагаемые инвесторы. Управление рисками - это определенная деятельность, которая выполняется в проекте от его начала и до завершения. О положении дел в проекте нужно судить не по количеству рисков, связанных с его выполнением, а по степени проработанности процедуры их выявления, анализа и управления ими.
Управление рисками включает ясное понимание внутренних и внешних причин, влияющих на проект, которые могут привести к его срыву. Главной целью управления рисками является идентификация и контроль за редко встречающимися факторами, которые приводят к вариациям проекта. Подобный подход отражается в формальном процессе, когда факторы риска систематически идентифицируются, оцениваются и поддерживаются.
Можно выделить следующие категории риска:
- внутренний, который находится в сфере влияния менеджера проекта;
- внешний, находящийся вне сферы влияния менеджера проекта.
На рисунке 2 показаны возможные проявления риска в проекте, приведена классификация рисков, а также особенности проекта, идентифицирующие риски и определяющие смягчение их влияния.
Процесс управления рисками состоит из следующих логически взаимосвязанных этапов:
идентификация рисков, анализ рисков, планирование рисков, мониторинг и управления рисками.
Необходимо отметить, что описанные этапы являются логическими шагами и не обязательно должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализа- планирования по мере обнаружения дополнительных факторов, влияющих на проект.
Результаты проведенного исследования. Чтобы эффективно управлять рисками, менеджер проекта должен иметь достаточно высокий уровень подготовки по следующим компетенциям: выполнение начальных оценок, составление графика, проведение эффективных собраний и презентаций. Определение рисков осуществляется в ходе начального оценивания.
Содержательная модель структуры работы или задачи проекта, как специфического вида деятельности состоит из описания трудовых ресурсов, оборудования и инструментальных средств, необходимых для выполнения определенной работы.
Практическое использование данной модели, например, при планировании работы "Подготовка объекта к внедрению", позволяет менеджеру включать в проект следующие задачи:
1) поставка и монтаж оборудования (разработка спецификации на оборудование; закупка и поставка оборудования; монтаж оборудования; установка и настройка оборудования);
2) поставка и установка общесистемного ПО (разработка спецификаций на общесистемное ПО; закупка общесистемного ПО; развертывание и настройка общесистемного ПО);
3) обучение пользователей (подготовка учебных курсов; обучение непосредственных пользователей; обучение руководства; обучение администраторов системы).
Список литературы:
1. Мамаева ГА., Ильина О.П. Управление информационными технологиями // Современные информационные технологии обработки и защиты информации. - СПб.: СПбГИЭУ, 2005.
2. Мазур И.И., Шапиро В.Д. Управление проектами. Под ред. проф. И.И.Мазура. М.: Высшая школа, 2001.
3. Разу М.Л., Воропаев В.И. и др. Управление программами и проектами:17-Модульная программа для менеджеров "Управление развитием организации". Модуль 8. - М.:ИНФРА-М, 2000.
4 Рапопорт Б.М. Оптимизация управленческих решений. М.,ТЕИС, 2001.
5 Бушуев С.Д., Морозов В.В. Динамическое лидерство в управлении проектами. Украинская ассоциация управления проектами. К., 2000.
6 Уокер Ройс. Управление проектами по созданию программного обеспечения. М., "ЛОРИ", 2002.
7 Мамаева Г.А., Ильина О.П. Моделирование эффекта бизнес-системы в результате реализации ИТ- проектов по созданию ИТ-сервисов // Современные аспекты экономики. №4 (152) - СПб.: Центр оперативной полиграфии, 2010
