Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Анализ контекста деятельности в управлении высокотехнологичными проектами. Учебное пособие
.pdf
Человек должен научиться управлять тремя группами сил: самим собой,
другими людьми и природой.
Э. Берн
2. ПРОЕКТЫ КАК УПРАВЛЯЕМЫЕ СИСТЕМЫ
Существует неоднозначность в понимании многочисленными
участниками реализации ИТ-проекта (руководителями, менеджерами
и специалистами) большинства терминов, используемых в системном
представлении реализуемых ими ролей в проекте. Ведь каждому
ИТ-проекту свойственны определенные типические и уникальные характеристики. Не только руководителям и менеджерам проекта, но
и ИТ-специалистам важно понимать системное представление продукта
и процессов проекта, которые используются в выбранной модели его
реализации. Заметим, что все модели управления проектами базируются
на парадигме рационального подхода к выработке управленческих решений. При этом бизнес-контексты деятельности заказчика и исполнителя проекта обычно представляются как актуализированные факторы
внешней и внутренней среды деятельности различных внутренних
и внешних заинтересованных
Сам термин «проект» также имеет неоднозначную трактовку в практике и рекомендациях по управлению проектами [5, 34]. Будем в дальнейшем использовать следующее определение понятия «проект». Проект – это комплекс действий, состоящий из взаимосвязанных задач, выполняемых различными функциональными организациями (подразделениями, сотрудниками), с четко определенными целями, расписанием
и
бюджетом [5]. Проект при таком его понимании представляет собой
организацию (предприятие), создаваемую на четко определенный срок
для достижения конкретных целей.
Все многообразие организаций, где используются проектные струк-
туры в организации управления, можно разделить на два класса [5].
Проектно-ориентированные организации. В таких организациях
основной бизнес составляют проекты. К ним относятся все фирмы,
продающие
ИТ-продукты или услуги на контрактной основе, а также
лиц ИТ-инициативы.
31
организации – разработчики программного обеспечения. Суть их
бизнеса – выполнение одного проекта за другим.
Проектно-зависимые организации. Такие организации вынуждены
использовать проекты с целью обеспечения выживания или реализации
появившихся возможностей для их бизнеса. Нас интересует тот аспект
их развития, когда они осуществляют стратегическое развитие посредством заказа ИТ-проекта проектно-ориентированной организации.
В
этом случае они выступают в качестве заказчика, с бизнес-целями ко-
торого будут прямо связаны цели и продукты проекта.
Для понимания бизнес-контекста ИТ-проекта следует снять неопределенность, взаимодействуя с заказчиком и другими заинтересованными лицами на его стороне, относительно стратегических целей управления, на достижение которых повлияет продукт
ИТ-проекта после его
внедрения в практику.
На любом предприятии существует используемая системой управления модель явных и неявных основных целей деятельности [13, 20].
На рис. 7 показаны основные цели организации как управляемой системы. Результат ИТ-проекта будет касаться в определенной степени
этих целей.
Удовлетворять
потребности клиентов
Экономично
использовать
ресурсы
ОРГАНИЗАЦИЯ
Действовать
рационально
Выпускать
продукцию
Приобретать
ресурсы
Рис. 7. Комплекс основных целей управления организацией
Развивать
организацию
Заметим, что для управления высокотехнологичным ИТ-проектом
как временной организацией также следует в явном виде формулировать эти цели.
32
Термином «программа» при таком понимании проекта обозначают
выполнение двух или более взаимосвязанных проектов, требующих координации при их исполнении. При этом для проектов программы могут быть определены разные исполнители, сроки и бюджеты.
В управлении проектами следует выделять три базовых концепции [5].
1. Концепция обязательного установления центров ответственности
за ходом работы
над проектом. Могут быть следующие уровни ответ-
ственности:
высшее исполнительное руководство организации;
менеджер / координатор проекта;
руководители функциональных подразделений;
функциональные лидеры проекта.
2. Концепция интегрального и комплексного планирования и контроля в проекте. Планированием и контролем должны быть охвачены все
задействованные в проекте функциональные подразделения или субподрядные
организации на всех этапах жизненного цикла проекта. При этом
учитывают все аспекты проекта: расписание, риски, бюджеты и др.
3. Концепция создания команды проекта, которая включает всех сотрудников функциональных подразделений, участвующих в реализации
проекта, а также членов офиса проекта, если он создается.
При формировании штата команды проекта используют сочетание
трех моделей:
передача задач проекта для их решения персоналу функциональ-
ных подразделений;
делегирование сотрудников организации в непосредственное рас-
поряжение менеджера проекта для работы с полной занятостью в управляемом им проекте;
заключение контрактов на работы по проекту с субподрядчиками.
На практике невозможно формирование команды высокотехнологичного проекта, в которой все
сотрудники работают с полной занято-
стью под руководством менеджера проекта. Причин несколько:
1) на разных этапах жизненного цикла проекта требуются специа-
листы с различными компетенциями;
2) менеджер будет отвлекаться на решение второстепенных для
проекта задач от выполнения процессов, связанных с реализацией им
интегрирующей роли в проекте – управлением взаимодействием внутри
команды проекта
в ходе его реализации;
33
3) специалистам в конкретной области комфортно работать в
группе профессионалов их профиля и под руководством специалиста,
понимающего их предметную область;
4) как будет показано ниже, в управлении проектами всегда существует неопределенность и связанные с ней риски прекращения проекта
или изменения требований к проекту.
Основные функции, реализуемые командой проекта:
управление проектом
;
проектирование и разработка продукта проекта;
поставки, закупки, заключение контрактов с субподрядчиками;
операции по вводу продукта проекта в эксплуатацию и др.
Заметим, что термин «продукт» относится ко всем результатам
ИТ-проекта, которые будут использованы как внутри команды проекта,
так и организацией – заказчиком проекта. Для характеристики продук-
особенностей управления их производством можно использовать
тов и
матричный классификатор продуктов [37], приведенный на рис. 8.
Инновационность продукта
Инновационный вещественный
продукт
Инновационный интеллектуальный
продукт
Вид продукта
Инновационная услуга Функциональная услуга
Рис. 8. Классификатор возможных продуктов проекта
Функциональный вещественный
продукт
Функциональный интеллектуальный
продукт
Признак инновационности означает, что продукт имеет уникальное
ценностное предложение, т. е. он имеет потребительские свойства, созданные командой проекта на основе собственной идеи. Для него не существует готовой бизнес-модели. В производстве функционального
продукта используют известные и доступные другим бизнес-модели.
Особенностью услуги как продукта деятельности является невозможность ее
производства впрок и сложность производства «духа сервиса»,
который воспринимает и оценивает ее потребитель.
В данном классификаторе не учтены нематериальные блага. Это
важный для ИТ-проектов класс продуктов, к нему относятся такие продукты, как деловая репутация, доверие, право авторства, достоинство
личности и др. Этот продукт имеет свою специфику в каждой
34
команде
проекта. Он существенно влияет на социально-психологический климат
в команде проекта и на взаимодействия с заинтересованными лицами
проекта в организации-заказчике.
Таким образом, в качестве продукта проекта следует рассматривать
программные и аппаратные средства, документацию, услуги по обучению, защите прав на интеллектуальную собственность и др.
2.1. ТИПИЧЕСКИЕ ХАРАКТЕРИСТИКИ ПРОЕКТОВ
Рассмотрим типические
характеристики любого ИТ-проекта.
1. Проект предназначен для получения определенного продукта, соответствующего требованиям конкретного заказчика и других прямо
или косвенно заинтересованных в нем лиц.
2. Каждый проект может быть уникальным как по продукту, так и
по условиям среды, в которой продукт разрабатывается и используется
на практике.
3. Проект планируется как целостный (
сквозной) бизнес-процесс
получения определенных результатов.
4. Проект имеет начало, определенные фазы (этапы) развития и конец, которые однозначно привязаны к временной шкале.
5. Переходы от одной фазы проекта к другой во многих случаях
четко не определены. Возможны ситуации, когда переходы от одной
фазы к другой (т. е. моменты и условия) четко
определены. Такие ситуации характерны для тех проектов, в которых фазы жизненного цикла
проекта разделены необходимостью получения предложения и (или) получения разрешения на продолжение проекта. Определение условий
продолжения означает, что после окончания каждого этапа принимается
решение о продолжении проекта.
Условия продолжения проекта зависят от следующих факторов:
полученного на
этапе результата, так как результат (продукт)
фазы служит исходным материалом для следующей фазы;
изменения контекста использования продукта заказчиком;
изменения требований к продукту ИТ-проекта.
На рис. 9 представлена модель жизненного цикла процесса выполнения ИТ-проекта, когда переходы от одной фазы к другой (моменты
и условия) четко определены. Это модель
типичного ступенчато-шлю-
зового процесса [5].
35
Замысел
проекта
1
Формиро-
вание
концепции
5
Инсталля-
ция / Внед-
рение
Опреде-
ление
2
проекта
3
Проекти-
рование
4
Разработ-
ка / Произ-
водство
– шлюз
Рис. 9. Представление проекта моделью ступенчато-шлюзового процесса
На рисунке цифрами обозначены следующие шлюзы: 1 – отбор
идей; 2 – вторичное просеивание идей; 3 – переход к проектированию;
4 – переход к разработке; 5 – переход к внедрению.
Типичный ступенчато-шлюзовой процесс соответствует каскадной
(водопадной) модели жизненного цикла управления проектом. Основные фазы каскадной модели жизненного цикла проекта показаны на
рис. 10.
Формирование
концепции
Определение
Начало
проекта
Развитие
проекта
Рис. 10. Основные фазы жизненного цикла проекта в рамках каскадной
Проектирование
модели
Разработка /
производство
(внедрение, установка)
Завершение
проекта
Инсталляция
Главный недостаток представленной на рис. 10 каскадной (водопадной) модели реализации проекта состоит в том, что она не позволяет
оперативно реагировать на изменения. В реальности потребности заказ-
36
чика могут измениться, приоритеты требований могут быть пересмотрены, финансовая ситуация может стать другой и т. д. Может также измениться и среда. Например, могут быть приняты существенные правки
в законодательство, что потребует внесения критических изменений во
всю идеологию проекта. Каскадная (водопадная) модель этого не позволяет, хотя она внешне очень
логична. Поэтому следование ей в управлении высокотехнологичным ИТ-проектом всегда создает большие
риски для него [22, 46].
6. Для высокотехнологичных проектов, как было отмечено выше,
характерно изменение состава и характера потребления ресурсов в различных фазах жизненного цикла проекта. Персонал, его роли и квалификация, организации-субподрядчики и другие ресурсы, задействованные
в проекте, могут существенно измениться при переходе к следующей фазе. Как следствие этого – существенно изменится контекст
управления проектом.
7. Многим проектам присуща существенная неопределенность
в определении сроков и бюджета на этапе определения проекта, когда
решается задача их бизнес-планирования [5]. На рис. 11 качественно
представлен уровень неопределенности в определении времени выполнения
и стоимости проекта на фазах формирования концепции и определения проекта. Заметим, что для выполнения этих двух фаз требуется
определенное время и ресурсы, но неопределенность полностью не снимается.
Фаза 1
Стоимость
завершена
Стоимость
t
– зона неопределенности в определении времени и стоимости проекта
Рис. 11. Неопределенность в представлении проекта
Фаза 2
завершена
t
8. Решение об основном объеме финансирования проекта и сроках
его выполнения обычно принимается после завершения фазы определения. При качественной реализации первых фаз проекта может быть существенно уменьшена неопределенность в его дальнейшей реализации.
37
Основной продукт этих этапов – сформированное, согласованное заинтересованными сторонами проекта и документированное представление сторон о целях, функциональных и нефункциональных требованиях
проекта, границах проекта, особенностях бизнес-контекста, контекста
будущей деятельности пользователей ИТ-приложения, сложности проекта и приоритетах проекта. В зависимости от полученных результатов
проект может быть остановлен или завершен. Экономия
и низкое каче-
ство реализации этих этапов обычно приводят к провалу проекта.
9. Для ИТ-проектов разработки программного обеспечения существенна проблема формулирования требований. Требования, скорее
всего, будут [43]:
неполными;
большей частью ошибочными;
противоречивыми;
не полностью описывающими поставленную задачу.
Практика показывает, что требования к программному обеспечению
часто меняются
в ходе выполнения ИТ-проекта. Инициатором изменений может быть как сторона заказчика, так и сторона исполнителя проекта. Такие решения обычно вызваны тем, что изменились взгляды заказчика и пользователей на представление своих моделей деятельности
или проявились не учтенные прежде факторы контекста их деятельности. Они адаптируют модели к
новым возможностям, предоставляемым
разрабатываемым приложением, или изменившимся условиям. Может
также измениться представление разработчиков о предметной области
деятельности пользователей продукта, поскольку разработчики начинают более глубоко понимать особенности условий деятельности пользователей. Таким образом, меняется бизнес-контекст проекта в целом
и контексты деятельности заинтересованных лиц. Необходимость адаптации проекта к изменяющимся требованиям
указывает на важность
роли системного или бизнес-аналитика в команде проекта.
При анализе влияния продукта ИТ-проекта на основные цели организации следует выяснить предпочтительный со стороны заказчика способ внедрения результатов ИТ-проекта. Возможны два способа управления нововведениями.
Первый способ предполагает скачкообразное развитие потенциала
организации. Внедрение начинается только
после полного завершения
ИТ-проекта посредством задействования всех доступных факторов влияния, которые рекомендуются бизнес-моделью по руководству и управлению ИТ на предприятии (COBIT5*) [49]. К этим факторам относятся
38
принципы, политики и подходы; процессы; организационная структура;
р
культура, этика и поведение; информация; услуги, инфраструктура
и приложения; персонал, навыки и компетенции.
Второй способ предполагает активное участие в деятельности команды проекта представителей заинтересованных лиц и будущих пользователей, на создание средств информационной поддержки которых
будет направлен ИТ-проект. Изменение условий их деятельности
приведет после внедрения продукта проекта к необходимости формирования ими новых моделей своей деятельности.
На рис. 12 и 13 качественно показано изменение уровня неопределенности в использовании результатов (продукта) ИТ-проекта для указанных способов управления развитием и затрат на формирование
опыта использования продукта проекта на практике. На рисунках: Тн –
момент
начала проекта; Тв – начало внедрения (использования) резуль-
татов проекта персоналом организации.
Неопределенность
Скачкообразное
развитие
Активное
участие
t
Тн
Рис. 12. Характеристика уровней неопределенности влияния ИТ-проекта
на деятельность персонала организации
Тв
Затраты
Скачкообразное
азвитие
Активное
участие
t
Тн
Рис. 13. Характеристика затрат на снятие неопределенности в деятельности
персонала организации продукта ИТ-проекта
В руководстве PMBOK выделены 10 отдельных областей знаний,
составляющих профессиональную область деятельности – область
Тв
39
управления проектами [50]. Знания из этих областей деятельности на
практике используются в большинстве высокотехнологичных проектов.
Поэтому в команде проекта должны быть сотрудники, имеющие компетенции в следующих областях:
1) управление интеграцией проекта;
2) управление содержанием проекта;
3) управление сроками проекта;
4) управление стоимостью проекта;
5) управление качеством проекта;
6) управление человеческими ресурсами проекта;
7) управление
коммуникациями проекта;
8) управление рисками проекта;
9) управление закупками проекта;
10) управление заинтересованными сторонами проекта.
Чтобы у менеджера проекта была возможность эффективно управлять его реализацией, заинтересованные лица должны иметь согласованное представление о приоритетах проекта. Как показано на рис. 11,
после завершения фазы определения проекта и принятия решения
об окончательных сроках и
бюджете проекта остается неопределенность, в том числе относительно функциональных и нефункциональных
требований. Она может быть снята только в процессе более детальной
разработки опыта деятельности пользователей будущего продукта
ИТ-проекта. Однако всегда остается вероятность изменения представления о продукте проекта заинтересованных лиц при получении ими
данных о результатах юзабилити-тестирования или
проявления факторов окружения, которые не были учтены в оценке бизнес-контекста
на этапе разработки концепции проекта и определения его границ. Менеджер проекта должен иметь согласованное представление о следующих факторах [26]:
ключевых факторах проекта: функциях (объеме, сложности) про-
дукта проекта; качестве продукта и процесса; графике; затратах; кадрах;
факторах, понимаемых менеджером как ограничения;
ограниченно гибких, в случае изменения контекста проекта, фак-
торах, понимаемых менеджером как факторы успеха проекта в целом;
факторах, влияющих на успех реализации проекта, в отношении
которых у менеджера есть определенная степень свободы в рамках ограничений.
Таким образом, в результате реализации фаз концепции и
определе-
ния конкретного ИТ-проекта формируется согласованный сторонами
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]