Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

1. Основные понятия системы управления проектами

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

· Система - это комплекс взаимосвязанных элементов, рассматриваемых как единое целое;

· Системе присуща определенная структура;

· Системе присуща обособленность от других объектов внешней среды [3, c. 30].

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



Рисунок 1. Общее представление о системе управления

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

Эффективное функционирование существующей системы управления проектами в компании очень важно. От того, каким образом организован процесс управления проектами, зависит эффективность реализации проектов. Разработано и предложено много моделей, оценивающих эффективность системы управления проектами в компании (Project Management Performance) [33]. Традиционно, система управления в компании организованна таким образом, чтобы реализуемые проекты находились в рамках известного проектного треугольника - время, качество, стоимость [23; 25]. Такой общепринятый подход ориентирован на удовлетворение ожиданий всех стейкхолдеров проектов, ведь все заинтересованные стороны хотят, чтобы проекты реализовывались в срок, были надлежащего качества и не выходили за рамки утвержденного бюджета. Однако такой подход, хоть и является универсальным, однако, не учитывает особенности компании и факторы внешней среды. [26; 27; 32] Таким образом, начали появляться модели, применяющие различные подходы к формированию системы управления проектами в компании и анализу ее эффективности. В большинстве моделей за основу были взяты принципы TQM, так, например, Project Excellence Model [44, c. 412], которая оценивает 12 ключевых «организационных сфер», качество организации которых влияет на успех реализации проектов и достижение стратегии компании в целом [34; 28]. Другие исследования в основу системы управления проектами закладывают модель зрелости управления проектами, (PM MaturИТy models), которая, в свою очередь, базируется на своде знаний по управлению проектами (PM Body of Knowledge, PMBOK Guide, PMI, 2004). Аналогично Bryde (2003) предложил модель PMPA (Project Management Performance Assessment), в которую включены 5 «системообеспечивающих факторов» и один фактор «результативный». Схематично модель Брайда изображена ниже, на рис. 2. [29; 30; 31]

Рисунок 2. Модель системы УП Брайда [29, c. 231]

Первым системообеспечивающим фактором является «Лидерство проектного подхода» (PM Leadership), который отражает позиционирование подхода управления проектами в компании, отношение сотрудников к проектному подходу и всеобщее осознание важности и значимости управления проектами в компании. Наличие проектной культуры, использование проектной терминологии, применение проектного подхода к управлению изменениями автор модели определяет необходимыми условиями для существования «лидерства проектного подхода» в компании. Вторым системообеспечивающим фактором является «Человеческий капитал в управлении проектами» (PM Staff), который определяет компетентность кадрового состава компании в сфере управления проектами, а также, отражает отношение компании к формированию человеческого капитала, базы знаний для постоянного улучшения компетентности сотрудников. Следующий фактор - «Политика и стратегия» (PM Policy and Strategy) - отражает как развитие УП в компании соотносится со стратегией компании. Отвечают ли стратегическим целям компании реализуемые проекты, является ли портфель проектов в компании инструментом достижения стратегии. Еще одной составляющей системы УП по модели Брайда является «Партнерство и ресурсы» (PM Partnerships and Resources), которая отражает каким образом выстроены взаимоотношения с поставщиками и партнерами при реализации проектов. Этот фактор показывает важность применение стратегии «выиграл-выиграл» (win-win strategy) при взаимодействии со всем стейкхолдерами. Последний системообеспечивающий фактор - «Управление по стадиям жизненного цикла проекта» (Project Lifecycle Management Processes). Эта составляющая системы УП показывает важность и необходимость применения подхода к управлению проектами в соответствии с их стадиями развития. Брайд выделил единственный результирующий фактор в своей модели системы УП - «Оценка деятельности по ключевым показателям» (PM KPIs) [30 c. 229].

Систему управления отдельными проектами выглядит следующим образом [4, c. 13]:

Рисунок 3. Система управления отдельными проектами [4, c. 13]

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

Рисунок 3. Корпоративная система управления проектами [4, c. 14]

Основными компонентами КСУП являются: методология УП, программно-аппаратный комплекс или информационная система УП (ИСУП), персонал и организационная структура. Стандартные компоненты КСУП представлены ниже, на рис. 4.



Рисунок 4. Компоненты КСУП [4, c. 15]

Особенности системы управления ИТ-проектами

Управление проектами, как самостоятельная область знаний, зародилась в 1955-1957 гг., когда появились и начали успешно использоваться такие методы управления проектами, как CPM (CrИТical Path Method) и PERT (Program Evaluating and Review Technique) [6, c. 35; 7, c. 123]. С момента зарождения проектного подхода в управлении, методы, инструменты и технологии постоянно развивались, и, на сегодняшний день, управление проектами широко применяется в практике компаний из абсолютно разных областей, работающих по всему миру. Для повышения своей эффективности, компании используют проектный подход в управлении [17]. Исследование, проведенное в 2011 г. показывает, что популярность проектного подхода растет из года в год со стремительной скоростью [35; 43]. Из области строительства, в которой начали применять инструменты управления проектами, проектный подход распространился на другие сферы и, на сегодняшний день, применяется в организациях повсеместно.

Существует ряд научных работ, подтверждающих, что проектный подход в управлении может быть более эффективным, чем традиционный функциональный подход [24; 38]. Успешная реализация проектов, программ и портфелей проектов, приводящая к достижению стратегических целей компании, во многом обусловлена существующей системой управления проектами в компании, ее зрелостью и способностью создавать и поддерживать необходимые процессы для успешной реализации проектов. Множество исследователей занимаются изучением проблемы взаимосвязи эффективности системы управления проектами и успешной реализацией проектов, как результат - создания дополнительной стоимости для компании. Например, международная организация PMI (Project Management InstИТute) проводили исследование, в котором, на протяжении четырех лет, на примере 65 кейсов в компаниях из 14 различных стран, изучали, каким образом управление проектами приносит добавочную стоимость компаниям [40; 44]. Результаты исследования подтвердили значимость и оценили вклад управления проектами в результаты деятельности компании, однако доказали, что управление проектами в различных компаниях имеет ряд особенностей, характерных для специфики каждой компании. Такие факторы, как внутренняя культура организации, наличие или отсутствие отлаженных бизнес-процессов, способы организации проектной деятельности, влияют на существующую систему управления проектами в компании, и, в конечном счете, влияют на результаты реализуемых проектов. Существуют исследования, демонстрирующие, что компания с эффективно-выстроенной системой управления проектами более успешна в реализации сложных проектов [32; 38].

ИТ-проекты получили свое распространение благодаря развитию информационных технологий, появлению различных видов программного обеспечения и повсеместной автоматизации деятельности различных организаций. Термин «ИТ-проект» в самом общем смысле можно определить, как проект, целью которого является использование или создание некоторой информационной технологии [5. c. 120; 42]. Разработка программных приложений, создание информационных систем, развертывание ИТ-инфраструктуры и др. является примерами ИТ-проектов.

Система управления ИТ-проектами должна учитывать особенности проектов такого типа. Во-первых, при реализации ИТ-проектов, часто происходит разделение на уровне идеологии заказчика и исполнителя. Заказчиком является бизнес или государственное учреждение, а исполнителем - ИТ-специалисты. В коммуникации часто возникают трудности на этапе выявления требований, ожиданий от проекта и формировании технического задания. При реализации ИТ-проекта ответственность за результат несет как исполнитель, так и заказчик. Чаще всего именно неэффективные коммуникации, неподходящие условия для взаимодействия сторон, являются виной неуспехов в проектах. Зачастую реализация ИТ-проекта включает в себя изменения в структуре предприятия, вовлеченность множества подразделений, что повышает вероятность конфликтов и непониманий между руководителем проекта, высшим руководством, руководителями подразделений и персоналом организации. При реализации ИТ-проектов, очень велико влияние человеческого фактора, сроки и качество выполнения проекта в основном зависят от непосредственных исполнителей и коммуникаций между ними. Работу в ИТ-проектах можно отнести к творческой деятельности, поэтому возникают трудности в планировании, стандартизации деятельности, определении нормативов и т.п. [5. c. 120].

Из-за большой доли неопределенности в работе, постоянных запросов на изменение и огромной стоимости выполнения проектов в сфере информационных технологий, ИТ-проекты признаны одними из наиболее сложных типов проектов с точки зрения управления и достижения поставленных целей. Существует статистика результатов реализации ИТ-проектов и она свидетельствует о том, что большинство из них не завершаются в срок, превышают бюджет или сдаются с недостаточной функциональностью [22, c. 85-92]. Согласно отчету Chaos Report, выполненному компанией Standish Group, каждый пятый ИТ-проект заканчивается неудачно, каждый второй не укладывается в срок, выполняется с худшим качеством или неполным функционалом. Ниже на графике представлена характеристика успешности выполнения ИТ-проектов с 1998 г. по 2012 гг. [47]



Рисунок 5. Статистика реализации ИТ-проектов с 1998 г. по 2012 г. [22, c. 85]

2. Применение теории ограничений к системе управления ИТ-проектами

Каждая система имеет свою цель, для достижения целей системы УП, необходимо постоянное ее совершенствование. Теория ограничений Годдратта базируется на выявлении ограничений в системах, определении ключевых проблем и их устранении. Автор теории предлагает использовать пятишаговый алгоритм при выявлении «слабого звена цепи» [8]. Ниже представлен алгоритм процесса непрерывного совершенствования по ТОС.

Рисунок 6. Алгоритм процесса непрерывного совершенствования по ТОС [14, c. 132]

Помимо пяти направляющих шагов, Голдратт предложил использовать последовательные методы логических рассуждений по ТОС, представленные ниже на рис. 7.

Рисунок 7. Последовательный метод рассуждений по ТОС [14, c. 135]

Для того чтобы понять что необходимо поменять, чтобы система стала лучше, необходимо проанализировать текущую реальность. Построение дерева текущей реальности поможет в определении ключевого конфликта системы. Дерево строится исходя из связей «если, то», и читается снизу-вверх. Если рассматривать управление проектами как систему то, иногда, то, что может в ней не нравится, не всегда является самой проблемой, а может быть лишь сигналом о ее существовании. Сама проблема кроется в первопричинах конфликтов, существующих в системе. Выявление и ликвидация ключевой проблемы не только устраняет все связанные с ней нежелательные эффекты, но и предотвращает их появление. Построение ДТР начинается с выявления нежелательных явлений (НЯ), которые ведут к определению ключевого конфликта [9].

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



Рисунок 8. Диаграмма разрешения конфликтов «Грозовая туча» [14, c. 140]

Дерево будущей реальности (ДБР) является инструментом, позволяющим удостовериться, что действия, которые собираются внедрить для устранения проблемы, приведут к желаемым результатам. Кроме того, ДБР позволяет определить, какие негативные последствия могут вызвать задуманные действия.

Рисунок 9. Дерево будущей реальности [14, c. 142]

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

3. Применение метода критической цепи к управлению ИТ-проектами

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

В управлении проектами одним из самых распространенных методов является метод критического пути. В PMBOK метод критического пути определяется как «метод анализа сети расписания, используемый для определения возможной гибкости при планировании (возможного временного резерва) в различных логических путях в сети расписания проекта и определяющий минимальную общую длительность проекта. Ранний старт и ранний финиш рассчитываются с помощью прямого прохождения, исходя из указанной даты начала. Поздний старт и поздний финиш рассчитываются с помощью обратного прохода, исходя из указанной даты завершения, которой иногда бывает ранний финиш проекта, рассчитанный с помощью прямого прохождения» [21]. Основным отличием метода критической цепи от метода критического пути является то, что при МКЦ не нужно определять точное время исполнения операций, в МКЦ важно, чтобы весь проект завершился в срок.

Метод критической цепи был впервые описан Голдраттом в книге «Критическая цепь» в 1997 г. [10], МКЦ в управлении проектами совмещает в себе классический подход в управлении проектами, в соответствии с самым распространенным стандартом по управлению проектами - PMBOK, теорию ограничений (theory of constraints), основы бережливого производства и шесть сигм.

Рисунок 10. Схема взаимодействия МКЦ и системы УП [11, c. 112]

Исследования показывают, что в большинстве случаев, для каждой задачи в проекте закладывают резерв времени примерно 100-200%, однако доля проектов, которые все равно не завершаются в срок очень большая. Исполнители и руководители проектов закладывают такой большой резерв времени для минимизации рисков неопределенности, в которой реализуется проект.

Рисунок 11. Вероятность распределения времени [14. c. 112]

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

1. Студенческий синдром - выполнение задания откладывается до последнего момента, так как исполнитель знает о имеющемся у него резерве времени.

2. Мультизадачность выражается в постоянном выполнении нескольких задач одновременно, что приводит к увеличению времени выполнения каждой из задач.

3. Так как задания в проекте имеют зависимость, то опоздания всех задач аккумулируется.

Голдратт делает вывод о том, что существующая подстраховка не защищает проект от риска срыва сроков его исполнения и предложил метод оценки длительности работ, исходя из минимизации срока исполнения всего проекта. Длительность работ в МКЦ берется исходя из наиболее реалистичных сроков выполнения работ, без подстраховки. После того, как определена правдивая длительность проекта, добавляются буферы в качестве подстраховки. Существует несколько видов буферов:

1. Питающие. Используются в таких местах расписания, где некритические работы соединяются с критическими, для предупреждения задержки длительности проекта вследствие задержки некритической работы.

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

3. Ресурсные. Данный тип буфера не является временным, он не изменяет срок выполнения проекта, а используется для защиты критической цепочки от возникновения ситуации отсутствия ресурсов. Этот буфер отражает то время, за которое необходимо предупредить ресурс, участвующий в выполнении работы критической цепочки о том, что он может приступить к работе раньше назначенного срока (имеется в виду трудовой ресурс). То есть, появляется возможность компенсации потерь времени при задержке одних работ более быстрым выполнением других [14].

Существует несколько подходов к расчету длины буферов. Рассмотрим наиболее популярные из них.

– Первый метод «вырезать-вставить» C&PM является классическим - 50% от длины критической цепи. Необходимо сложить длительность всех операций цепи и разделить пополам - это и будет размер буфера. Питающие буферы равны половине цепочек, составленных из некритических работ, влияющих на критическую цепь. Ресурсные буферы не имеют продолжительности. Этот метод является одним из наиболее популярных и самый простой в применении, не требующий сложных вычислений. Однако у этого метода расчета буферов есть свои недостатки. При использовании этого метода в больших проектах размер буфера, вычисленный этим путем, получается довольно большим.

– Метод квадратического отклонения. Данный метод предполагает более точное определение размера буферов. Для начала необходимо определить два оценочных значения каждой работы цепи: завышенную длительность и наиболее вероятную, или среднюю. Тогда неопределенность выполнения данной работы в срок можно выразить через: , где Si - пессимистическая, завышенная оценка длительности работы i, а di - средняя длительность. Автор этого метода полагает, что стандартное отклонение работы i определится как Ui/2. Тогда стандартное отклонение всей цепи можно рассчитать как:

у =,

где n - число работ цепи.

При расчете буфера в данном случае принимается допущение, что сроки выполнения работ являются независимыми величинами. В таком случае, размер буфера будет равен 2 среднеквадратическим отклонениям.

Буфер = 2у =

– Метод, адаптивный к недостатку ресурсов. В некоторых проектах количество ресурсов, необходимых для его выполнения приближается к доступному количеству ресурсов. В данном случае, при каком-либо происшествии, ресурсов может стать недостаточно, и работа будет задержана. В такой ситуации необходимо создавать буферы, учитывая эту особенность проекта, то есть таким образом, чтобы буфер поглотил возможную задержку. Степень ограниченности ресурсов вычисляется через коэффициент использования ресурсов, который равен отношению необходимого количества ресурса для выполнения проекта к доступному количеству ресурса. Расчет размера буфера производится через среднеквадратическое отклонение и вышеописанный коэффициент использования ресурсов. Пусть RF(q) - коэффициент использования ресурса q.

–

, где

r (i, q) - необходимость в ресурсе q для выполнения работы i,

di - длительность работы i,

AV(q) - доступность ресурса q,

T - длина критического пути.

Затем необходимо выбрать максимальный из всех коэффициентов: ,

Буфер = ,

где у2i - дисперсия длительности работы i.

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

Буфер = (1+коэффициент сложности сетевого графика)*sqrt(у2i).

Руководителю проекта важно следить за критической цепью и за состояниями буферов. Считается, что если буфер проекта исчерпан на половину, то необходимо принимать соответствующие управленческие решения.

Критический путь не является ограничением проекта, ограничением является ресурсная зависимость между выполняемыми задачами. Метод планирования проекта по ТОС снимает ресурсные ограничения в ходе нахождения критической цепи. Таким образом, если предположить, что в проекте ресурсы неограниченные, то критическая цепь в будет совпадать с критическим путем проекта. Одним из достоинств МКЦ является то, что он учитывает взаимосвязи между длительностью работ, отношениями предшествования, потребностью в ресурсах и доступностью ресурсов, которые и определяют всю длительность проекта [14, c. 214].

Успешная работа по МКЦ реализуема только в условиях высокой культуры проектного управления в компании. Переоценка буферов, использование только возобновляемых ресурсов и изматывание участников проекта являются причинами критики МКЦ.

4. Обзор подходов к управлению ИТ-проектами

К управлению ИТ-проектами подходят с позиции управления их жизненными циклами. Наиболее известными и широко используемыми из таких подходов можно назвать следующие: каскадная модель, V - образное эволюционное ускоренное прототипирование, быстрая разработка приложений, инкрементная и спиральная модели [15].

Каскадная модель жизненного цикла ИТ-проекта

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



Рисунок 12. Классическая каскадная модель с обратной связью

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

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

V-образная модель жизненного цикла ИТ-проекта

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

Рисунок 13. V - образная модель жизненного цикла [15]

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

Модель прототипирования жизненного цикла ИТ-проекта

Модель прототипирования жизненного цикла ИТ-проекта появилась в 1975 г. и является широко используемой на сегодняшний день. В основе модели лежит концепция построения экспериментальной или прототипной системы. Появилась эволюционная модель быстрого прототипирования (RAD) и спиральная модель, автором которой является Фред Брукс (Fred Brook). Автор модели утверждает, что наиболее важной функцией, которую выполняет руководитель ИТ-проекта - это итеративное извлечение и уточнение требований к продукту. Бернард Боар дал определение прототипированию: «Метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конечной системы - быстро и в требуемом контексте» [16, c. 220]. Другими словами, модель подразумевает создание «макета», прототипа рабочей модели системы.

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



Рисунок 14. Эволюционная модель быстрого прототипирования [15]

«Быстрая» частичная реализация системы в виде создания ее прототипа реализуется на этапе определения требований, включает в себя апробирование модели заказчиком, когда клиент пробует модель и путем обратной связи сообщает о результатах, уточняя требования к системе. Такой подход имеет множество преимуществ, решающих проблему предыдущих моделей - размытость требований заказчика к конечному продукту. К недостаткам этой модели относят ее мало стандартизированный подход и недостаток документации, критики модели часто называют его «разработанный на скорую руку». Весомым недостатком модели является факт, что прототипирование может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование - устранение ошибок» (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипирования [12, c. 114].

Спиральная модель жизненного цикла ИТ-проекта

Спиральную модель можно рассматривать как усовершенствование итеративной модели. Спиральная модель включает в себя преимущества каскадной модели, но при этом также включает анализ и управление рисками, процессы поддержки и менеджмента. Модель была разработана Барри Боэмом в 1986 году. В основе модели лежат циклы, представляющие собой набор операций, которым соответствует такое же количество стадий, как в каскадной модели.

Рисунок 15. Спиральная модель жизненного цикла [12]

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

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

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

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

5. Гибкие методологии в управлении ИТ - проектами

В настоящий момент, в сфере управления ИТ проектами наибольшее распространение в применении на практике имеет гибкий подход к управлению проектами. Так как проекты в ИТ сфере подвержены большому числу изменений во время их реализации, необходимо подбирать подходы и инструменты в управлении, дающие наилучший результат. Гибкие методологии в управлении ИТ-проектами проявили себя как наиболее успешные. Гибкие методологии можно отнести к современным подходам управления проектами, сам термин «Agile», как и основные принципы методологии зародились в 2001 году, когда 17 специалистов (консультантов и практиков) разработали документ «Манифест гибких методологий разработки». «Гибкая» методология - это итеративный процесс, использующий уникальные практики для получения нового функционала программного обеспечения каждые 1-4 недели» [18].

Тогда же в 2001 году были созданы два основополагающих документа: «Манифест гибких методологий разработки» и «Принципы гибкой разработки». В первом из них четко прописаны высокоуровневые ценности, которым уделяется внимание в процессе управления ИТ-проектом: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану» [46].



Рисунок 16. Сравнение гибких методологий с водопадной моделью [46]

Принципы гибкой разработки из «Манифеста» определяют основополагающие двенадцать ценностей, на которых строится реализация ИТ-проектов по гибким методологиям. Во многом эти ценности совпадают с принципами итеративной и спиральной моделей. Гибкие методологии позволяют организовать эффективные взаимодействия между участниками команды и между командой проекта и заказчиком. В основе методологии лежит гибкий процесс управления ИТ-проектами по итерациям, используя промежуточные тестирования и уточнения требований заказчика. Гибкие методологии будут работать только в том случае, если есть дисциплинированная, самоорганизующаяся команда, постоянно осуществляющая коммуникации с заказчиком. Безусловно, не всем ИТ-проектам необходимо использовать гибкие методологии. Существуют научные работы, целью которых является выявление факторов и признаков ИТ-проектов, указывающих на то, что необходимо применять гибкие методологии для их успешной реализации. Например, Грэг Чин определил такие факторы, путем разделения предпосылок на две группы - внутренние неопределенности и внешние неопределенности [18].



Рисунок 17. Факторы неопределенности как предпосылки применения гибких методологий [18]

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

На практике пользуются популярностью следующие гибкие методологии:

1. Экстремальное программирование (XP);

2. Скрам (Scrum);

3. Бережливая разработка (lean);

4. Разработка, управляемая функциональностью (fdd);

5. Канбан;

6. Crystal Clear.

Экстремальное программирование - это методология, позволяющая разрабатывать качественный продукт более эффективно благодаря постоянному корректированию проекта для повышения его адаптивности к изменениям. Впервые экстремальное программирование было описано Кентом Бэком в 1999 г. в книге «Extreme Programming Explained» [19]. Изменения к требованиям продукта в XP являются желательной и неизбежной частью разработки. Парное программирование, 40-часовая рабочая неделя и постоянное присутствие заказчика в команде, первостепенное внимание тестированию являются наиболее известными чертами XP. Эта методология предполагает работу в небольших командах, ежедневные совещания, неформальный тип коммуникаций и минимум документации. Такой тип гибких методологий больше подходит для индивидуальных практик, чем для управления в крупных ИТ-проектах [19; 13, c. 213].

Семейство гибких методологий Crystal максимально просты в использовании, ориентированы на человеческие привычки и требует минимальных усилий для внедрения. Основные характеристики Crystal Clear:

· итеративная инкрементная разработка;

· автоматическое регрессионное тестирование;

· пользователи привлекаются к активному участию в проекте;

· состав документации определяется участниками проекта;

· как правило, используются средства контроля версий кода.

Методология «бережливая разработка» происходит из Lean Management и включает в себя ее основные принципы. Используются визуализирующие инструменты, ключевыми функциями продукта проекта являются те, которые представляют наибольшую ценность для заказчика, используются инструменты постоянного мотивирования команды проекта. В данной методологии также используется разработка через тестирование и применение коротких итераций.

Разработка, управляемая функциональностью (future driven development) является еще одним примером гибких методологий. Методология фокусируется на проектировании и внедрении, использует объектное моделирование и проста в применении. В основе FDD лежат пять этапов:

1. Построение модели;

2. Создание списка функций;

3. Планирование реализации функций;

4. Создание архитектуры для функций;

5. Реализация функций.

Методология предполагает разработку различных функций различными отдельными небольшими командами разработчиков во главе с ведущим разработчиком. Разделение функций происходит на этапах 3-4.

Канбан представляет собой эффективный инструмент для визуализации производственного процесса. Методология проста для внедрения, включает в себя три базовых правила, которым должна следовать команда разработчиков. Во-первых, для визуализации производственного процесса, необходимо использовать доску, включающую в себя разделение работы на задачи, разбитые на этапы работ. Во-вторых, необходимо ограничивать количество незавершенных работ. Для этого у каждого столбца-состояния необходимо указывать максимально количество задач, которые могут находиться на этом этапе. В-третьих, необходимо оптимизировать процесс, путем отслеживания среднего времени задачи и уменьшать его [46].

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



Рисунок 18. Популярность гибких методологий [20]

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

Рисунок 19. Схема гибкой методологии SCRUM [46]

Методология предполагает наличие ролей: владелец продукта, команда разработчиком и скрам-мастер. Владелец продукта определяет его требования, осуществляется планирование спринта и формируется беклог спринта. Sprint backlog - резерв, список требований, выбранных из резерва проекта для реализации, резервом всего проекта является список требований (user stories) к результату проекта. Длительность спринта строга ограничена 1-4 неделями. Планирование спринта длится не больше восьми часов и включает в себя обсуждение работ, которые предстоит сделать за спринт, создается резерв спринта с оценкой в человеко-часах. В первых четырех часах встречи участвует владелец проекта и SCRUM команда, выбираются задачи из резерва продукта. Последующие четыре часа происходит обсуждение технических деталей реализации требований уже внутри команды, наполняется резерв спринта. Применение методологии SCRUM включает в себя проведение ежедневных встреч, длительностью не более 15 минут, на которых участники отвечают на три вопроса: что было сделано, что будет сделано, какие есть проблемы. По окончанию спринта происходит обзор итогов спринта, когда команда демонстрирует результаты проделанной работы. В конце проводят ретроспективное совещание, на котором каждый участник команды высказывает мнение о прошедшем спринте, отвечают на вопросы: что было сделано хорошо и что нужно улучшить. В обязанности SCRUM Мастера входит создание атмосферы доверия, устранение препятствий, формулировка проблем и открытых вопросов, соблюдение практик и технологий методологии SCRUM [46].

6. Теоретическая модель системы УП

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

Рисунок 20. Теоретическая модель системы управления ИТ-проектами

управление информационный каскадный

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

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

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

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

Управление сроками проектов с использованием метода критической цепи позволяет завершать проекты как можно раньше. Завершение проектов в максимально короткие сроки позволяет сократить общие потери. МКЦ способствует гибкости организаций в части их реакции на изменяющиеся потребности и может служить дополнением ко всем гибким методологиям.

При применении методов, сокращающих длительность проектов до минимально возможных, необходимо постоянно контролировать качество проекта. Система управления проектами в ИТ-компании должна включать в себя эффективные инструменты контроля качества. Одним из подходов, доказавших свою эффективность на практике является концепция шести сигм, разработанная в компании Motorola. Основанная на использовании статистических методов, концепция шести сигм может быть отличным дополнением к системе УП, основанной на гибких методологиях и МКЦ [11, c. 212].

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

Список используемой литературы

1. Постановление Правительства Москвы от 09.08.2011 №349-ПП «Об утверждении государственной программы города Москвы «Информационный город» на 2012-2018 годы».

2. Аньшин В.М., Демкин И.В., Никонов И.М., Царьков И.Н. Модели управления портфелем проектов в условиях неопределенности. М.: МАТИ, 2008. 110 с.

3. Балашов А.И., Рогов Е.М., Тихонова М.В., Ткаченко Е.А. «Управление проектами. М.: Юрайт, 2013. 383 с.

4. Богданов В. Управление проектами: корпоративная система - шаг за шагом» М.: Манн, Иванов и Фербер, 2012. 248 с.

5. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Методические основы управления ИТ-проектами. - Интернет-университет информационных технологий, 2011. 392 с.

6. Ильина О.Н. Методология управления проектами: становление, современное состояние и развитие. М.: ИНФРА - М, 2011.

7. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учебное пособие / Под общ. ред. И.И. Мазура. - 2-е изд. М.: Омега-Л, 2004. 664 с.

8. Голдратт Э. Критическая цепь; Пер. с англ. М: ТОС Центр, 2006. 272 с.

9. Голдратт Э.М., Кокс Дж. Цель. Процесс непрерывного совершенствования. М.: Попурри, 2009. 172 с.

10. Голдратт Э.М., Кокс Дж. Цель-2. Дело не в везенье. М.: Попурри, 2009.

11. Детмер, У., Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию // Пер. У. Саламатовой, М.: Альбина Паблишер, 2010. 448 с.

12. Кантор Марри. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. М.: Вильямс, 2002 г. 176 с.

13. Кент А., Миллер Рой. Экстремальное программирование: постановка процесса. С первых шагов и до победного конца Planning Extreme Programming. Серия: Библиотека программиста. М.: Питер, 2003 г. 368 с.

14. Лич Л. Вовремя и в рамках бюджета. Управление проектами по методу критической цепи. М.: Альпина Паблишерз, 2010. 353 с.

15. Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными проектами. М.: Вильямс, 2004 г. 1136 с.

Размещено на Allbest.ru

...