11
поведение и работу структурных единиц оказывает значительное влияние и
горизонтальные, неадминистративные коммуникации.
Для проекта характерно наличие понятных целей, ограниченных
ресурсов, повышенного уровня неопределенности основных параметров,
значительная вероятность реализации непредвиденных ситуаций, наличие
конкретных сроков начала и конца проекта. Его выполнение требует
понятной координации в рамках реализации. Также, принципы реализации
организационных структур управления проектами, указанные И. И.
Мазуром, - следование организационной структуры системе
взаимоотношений, составляющих проекта, самому проекту, соответствие
организационной структуры ожиданиям внешнего окружения – позволяет
говорить о том, что функционально-ориентированный подход к выделению
организационных структур не может применяться в специфике проектного
управления.
Сейчас значительное распространение получает процессно-
ориентированный подход (ПОП) к построению организационных структур.
В ПОП к управлению лежит такое понимание процесса: это совокупный
набор повторяемых действий (функций), образующих исходный материал и
данные в конечный продукт (услугу) в рамках указанных правил. Ключевым
в понимании процессного подхода становится перемена вертикального
построения организационной структуры на горизонтальное. Начинателями
процессного подхода считают авторов пионерской работы «Перестроение
корпорации. Манифест революции в бизнесе» М. Хамера и Дж. Чампи. В
данной книге были показаны недостатки управления организацией на
примере функционального подхода, а также показано, что в XXI в.
компании с такой структурой определяет «негибкость, неадаптивность,
минимальная ориентация на клиента, помешанность на деятельности, а не
ее результатах, бюрократия, минимальный процент инноваций,
повышенные накладные расходы». Изменившиеся условия бизнеса требуют
от компаний нового подхода к управлению.
12
Т.к. сама деятельность организации определяется в рамках
интегрированного взаимосвязанного процесса, то переход на процессное
управление показывает переход на управление деятельностью в отличие от
управления структурами, которое более характерно для функционального
управления. Но структуры как раз и должны служить для управления
работой. Функциональный подход тут просто выводиться из процессного:
чтобы четко построить наборы функций для управления, надо знать
процессы. И тут возникают главные преимущества процессного подхода -
он всегда имеет в виду цепочки действий (процессы), направленные на
итоговый результат, и помогает:
• Оперативно реагировать на изменения, поскольку наборы
функций, не видя связи между ними, отлаживать гораздо сложнее;
• Настраивать рабочих на результат процессов (продукт, услугу);
при функциональном подходе работа отделов направлена на достижение
требований руководителя, а не клиента;
• Лучше минимизировать затраты, поскольку работа с
процессами помогает миновать дублирования и затраты, ненужных для
завершения процесса.
Выделим некоторые результаты, которые достигаются при
реализации процессно-ориентированного подхода.
1) Минимизация время работы процесса при взаимном повышении
качества выполняемых работ за счет оптимизации операций передачи
данных по иерархии управления. Работа руководителей направлена на то,
чтобы «склеить» функции в процессы, при этом изменяются отправляемые
данные, падает качество результата.
2) Имеется возможность оценки производительности функций,
реализуемых в рамках процесса, относительно эффективности самого
процесса. При функциональном подходе итоги работы сотрудников
рассматриваются, исходя из субъективного представления руководителя о
13
качестве результата операции, а не с точки зрения совокупной цены
конечного результата процесса.
3) Поддержка согласованности результатов в рамках процессов.
Функциональный подход определяется противоречиями в действиях и
интересах функциональных подразделений организации, что в итоге
минимизирует качество процессов.
4) Понижаются накладные расходы, а также стоимость
результатов процесса. При функциональном подходе траты увеличиваются
за счет большого количества операций, происходящих из-за необходимости
частой передачи данных и промежуточных результатов между отделами,
так и из-за большого числа ненужных операций, возникающих из-за
непонимания исполнителей свой роли в процессе.
5) Доступность реализации системы мотивации персонала,
основывающуюся на поощрении сотрудников в процессе достижения
результатов в работах, в которых они участвуют. При функциональном
подходе интерес сотрудников в конечном результате минимален, поскольку
главными потребителями итогов их работ становятся функциональные
руководители.
ПОП к управлению помогает наладить деятельность таким образом,
чтобы она была гибкой, направленной на обязательное улучшение качества
конечного продукта, минимизацию стоимости и удовлетворение клиента.
1.2 Специфика проектной деятельности в сфере
информационных технологий
Среди общераспространенных проблем процесса разработки
программного обеспечения встречаются следующие:
Изменение требований непосредственно в процессе разработки.
Нечеткое распределение ответственности за выполняемую
работу и ее результат.
14
Наличие непрерывного потока мелких, «быстрых»,
наваливающихся требований, отвлекающих разработчиков и менеджеров от
основного направления работ.
Как следствие, срыв сроков, раздувание бюджетов, потеря
качества.
Для решения задачи успешной организации процесса разработки ПО
была создана гибкая методология разработки проектов.
Принципы, методы, модели и процессы «гибкого» проектного
управления получили свое развитие в отрасли высоко-технологических
проектов, связанных с созданием и внедрением сложных программных
комплексов. Гибкое проектное управление можно рассматривать как
концептуально-практическую платформу, лежащую в основе целого
семейства методик управления инновационными, в первую очередь
информационно-технологическими проектами. Основные принципы
гибкого проектного управления изложены в работах Дж.Хайсмита [7,44],
Г.Аллемана [8, 11], Г.Чина [17,44]. Сравнительный анализ различных
прикладных методик гибкого управления инновационными проектами
можно найти в работах К.Лармана [27,34] и П.Абрамсона и других [5, 10].
Ситуационный подход к выбору оптимальной методики гибкого проектного
управления изложен в книге А.С.Коха [3,12].
Дж.Хайсмит описывает основное качество данного подхода
следующим образом. «Гибкость (agility) - это способность одновременно
создавать и отвечать на изменения, создавая прибыль в турбулентных
экономических условиях. Гибкость есть способность балансировать между
хаосом и стабильностью» [16, 45]. Он продолжает, что «многие ошибочно
полагают, что подвижность означает отсутствие структуры. Но отсутствие
структуры или стабильности означает хаос. С другой стороны, избыток
структурной упорядоченности создает жесткость. Теория сложности
говорит, что инновации, т.е. создание чего-то нового методами, которые
сложно заранее определить, возникают часто в точке баланса между хаосом
15
и порядком, между гибкостью и стабильностью. Ученые полагают, что
возникновение и создание нового имеет место на границе хаоса (edge of
chaos)» [16, 34]. На поиск, казалось бы, невозможного баланса между
порядком и хаосом направлены все усилия гибкого проектного управления.
Причем идет оно от упорядоченности процессов, методов и
инструментария, предлагаемых традиционными школами проектного
управления в сторону деструктуризации, деконструкции избыточно
упорядоченных организационных условий осуществления проектов, к
выработке простых и «мягких» (ориентированных на людей методов и
инструментов, обеспечивающих способность гибко адаптироваться к
постоянно меняющимся условиям. Если традиционными функциями
управления проектами рассматривались планирование, оптимизация и
контроль, то гибкое управление проектами видит в качестве главных усилий
естественную эволюцию и адаптация.
В 2001 году создатели и приверженцы нескольких близких по духу и
направленности методик управления ИТ-проектами сформулировали
«манифест» гибкого управления инновационными проектами. Манифест
закрепляет 4 основные идеи и 12 принципов [17,34]. Разработчики
манифеста, представители таких методик как «Экстремальное
программирование» (Extreme programming) [9], «Скрам» (Scrum) [6],
«Адаптивная разработка программного обеспечения» (Adaptive Software
Development) [17,44] и другие, сознательно не пожелали сводить гибкое
управление проектами к моделям, средствам и инструментам, но
представили его в виде гибких и адаптивных принципов и идей,
предназначенных для свободного и творческого воплощения в контексте
конкретной ситуации. Идеи и принципы гибкого управления проектами не
следует рассматривать как сложившиеся законы и правила.
Основные идеи гибкого проектного управления состоят в следующем:
- личности и их взаимодействия важнее, чем процессы и
инструменты;
16
- работающее программное обеспечение (в общем случае -
ценный для пользователя продукт или услуга) важнее, чем полная
документация (или исполнение планов и бюджетов);
- сотрудничество с заказчиком важнее, чем контрактные
обязательства;
- реакция на изменения важнее, чем следование плану.
Принципы гибкого управления проектами включают в себя
следующие:
- удовлетворение клиента за счёт быстрой и надежной разработки
продукта, обладающего ценностью для клиента;
- положительное отношение к изменению требований к продукту,
даже в конце разработки, если это создает ценность для клиента и приводит
к повышению конкурентоспособности продукта;
- частая разработка и поставка работающих модулей или версий
продукта (каждый месяц или неделю или ещё чаще);
- тесное, ежедневное общение заказчика с разработчиками на
протяжении всего проекта, выходящее за рамки контрактных отношений;
- высокий уровень мотивации участников проекта, которые
обеспечены нужными условиями работы, поддержкой и доверием;
- личный разговор, как основной метод передачи информации в
рамках проекта;
- работающий и ценный для клиента продукт есть лучший
измеритель успеха проекта;
- участники проекта, в первую очередь разработчики и
пользователи, должны иметь возможность поддерживать постоянный темп
работы на неопределенный срок;
- постоянное улучшение технического мастерства исполнителей
и совершенствование продукции;
- стремление к простоте, искусство НЕ делать лишней работы;
17
- автономия и самоорганизация на уровне команды проекта,
лучшие технические требования, дизайн и архитектура получаются у
самоорганизованной команды;
- постоянная адаптация к изменяющимся обстоятельствам.
Общей схемой гибкого проектного управления может быть признана
циклическая модель жизненного цикла проекта (рис. 2), разбивающая
проект на большое количество итераций. «Каждая итерация сама по себе
выглядит как программный проект в миниатюре, и включает все задачи,
необходимые для выдачи мини-прироста по функциональности:
планирование, анализ требований, проектирование, кодирование,
тестирование и документирование. Хотя отдельная итерация, как правило,
недостаточна для выпуска новой версии продукта, подразумевается, что
гибкий программный проект готов к выпуску в конце каждой итерации. По
окончании каждой итерации, команда выполняет переоценку приоритетов
разработки» [14,56].
18
Оценка
Выявление
требований
Проектирование
Создание
Последняя версия
Вторая версия
Первая версия
Завершающее
проектирование
Физическое
проектирование
Логическое
проектирование
Концептуальное
проектирование
Одобрение
концепции
Анализ риска
Экспертиза
Экспертиза
Тестирование
Требования бизнеса
Системные
требования
Требования единиц
техники
Выпуск в
производство
Производство и
поддержка
Требования
подсистем
Рисунок 2 Циклическая модель жизненного цикла гибкого проекта
Модель на рис. 2 предполагает, что проект разворачивается как
неопределенное количество циклов (итераций), каждый из которых
проходит через четыре фазы - выявление требований, проектирование,
создание и оценка. Каждый последующий цикл приводит к уточнению
требований, пересмотру содержания, улучшению продукта и процессов
реализации проекта. В реальности итерационная природа гибкого проекта
более сложна и предполагает возможность любого перехода между этапами,
что иногда отображается в виде так называемой хаотической модели
жизненного цикла проекта (рис.3).
19
Определение требований
Проектирование архитектуры
Детальное проектирование
Создание и тестирование
модулей
Интеграция
Тестирование системы
Поддержка
Рисунок 3 Хаотическая модель жизненного цикла проекта
Такие представления о жизненном цикле проекта предполагают
нетрадиционный взгляд на содержание проекта. Действительно, в отличие
от традиционного проектного управления с его жестким закреплением
требований к результату и границ содержания, гибкое управление
рассматривает требования и содержание как динамически изменяемые
[10,11]. Во многом представления о гибком управлении проектом
соответствуют концепциям развивающихся и открытых проектов [7;6]. Если
традиционные терминальные проекты предполагают четкое определение
границ жизненного цикла и содержания проекта, достижение которых
автоматически означает завершение проекта, то развивающиеся проекты
оставляют содержание всегда открытым для дальнейших изменений и
развития. Открытые проекты вообще определяют содержание только лишь
в виде общих ориентиров и индексов, постоянно изменяя его в ходе
выполнения.
20
«Гибкость» содержания проекта связана также с ориентацией
проектов на ценность для клиента (и команды), а не на формальные
результаты. Гибкое управление отходит от традиционного «железного»
треугольника «качество-время-затраты» и от представлений о проекте, как
о механизме выполнения работ, и предлагает новый «подвижный»
треугольник «ценность-ограничения-качество» [16,34]. Данные взгляды
полностью совпадают с идеями М.Винтера [14,45] и другими участниками
инициативы по «Переосмыслению проектного управления» [7,44]. Также
они практически совпадают с общими взглядами представителей
ситуационного подхода к управлению проектами Д.Двира и А.Шенхара,
изложенными в их концепции «переизобретения проектного управления»
[14,12].
Итерационная природа гибкого проекта предполагает совмещение и
соединение многих этапов разработки новой продукции и даже работ по
проектированию, планированию и созданию продукции, что во многом
сходно с параллельным проектированием [4, 23]. Гибкое управление
проектом базируется на многократном циклическом параллельном
проектировании, что предполагает использование межфункциональных
команд и эффективные коммуникации между всеми участниками проекта.
В этом аспекте «подвижное» проектное управление вобрало в себя многие
подходы, предлагаемые методикой интегрированной разработки продукции
(IPD - Integrated product development) [17,24].
Гибкость и открытость в составе и структуре работ предполагает
высокий уровень свободы от формальных процедур и процессов. Гибкое
проектное управление всячески подчеркивает необходимость минимизации
документальной работы, формальных процессов и процедур, заведомо
определенных методов и подходов к решению задач и управлению.
Формальные стандарты и процедуры рассматриваются как серьезные
ограничители «подвижности» в управлении проектами. Акцент в
управлении делается на неформальных методах и связях, личностных