Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Анализ контекста деятельности в управлении высокотехнологичными проектами. Учебное пособие
.pdf
на основе результатов экспертизы и текста договора ответить на следующие вопросы.
1. Что и от кого требовалось в процессе реализации проекта?
2. Что, кому, в каком виде и в какой срок должно быть передано?
3. Какие предусмотрены последствия, если это не выполнено?
Остановимся на еще одном важном факторе, существенно влияю-
щем
на деятельность менеджера проекта и команды проекта в целом.
Это фактор необходимости работы с конфиденциальной информацией,
если сторонами заказчика и (или) разработчика проекта установлен для
нее специальный режим – режим тайны. Тайна – это конфиденциальная
информация, за разглашение которой предусмотрена юридическая ответственность. Виды конфиденциальной информации устанавливаются
действующим законодательством. В разработке конкретного проекта
может быть необходимость работы с различными видами информации.
На доступ и работу с определенной информацией – государственной,
служебной, профессиональной, коммерческой, личной – может устанавливаться режим тайны. Необходимость работы с такой информацией –
существенный фактор контекста.
Рассмотрим установление режима тайны на конфиденциальную
коммерческую информацию. Используем установленные Федеральным
законом следующие определения понятий коммерческой тайны
и ин-
формации, составляющей коммерческую тайну [52]:
1) коммерческая тайна – режим конфиденциальности информации,
позволяющий ее обладателю при существующих или возможных обстоятельствах увеличить доходы, избежать неоправданных расходов, сохранить положение на рынке товаров, работ, услуг или получить иную
коммерческую выгоду;
2) информация, составляющая коммерческую тайну, – сведения любого характера (производственные, технические, экономические, орга
низационные и другие), в том числе о результатах интеллектуальной деятельности в научно-технической сфере, а также сведения о способах
осуществления профессиональной деятельности, которые имеют действительную или потенциальную коммерческую ценность в силу неизвестности их третьим лицам, к которым у третьих лиц нет свободного
доступа на законном основании и
в отношении которых обладателем та-
ких сведений введен режим коммерческой тайны.
Стороны договора – разработчик и (или) заказчик проекта – по своему усмотрению могут устанавливать в рамках действующего законодательства режим тайны на обращение с определенными коммер-
-
61
ческими данными. Заметим, что введение на определенные данные, которыми сторона владеет на законном основании, режима коммерческой
тайны существенно повышает их защиту. Но одновременно этот режим
создает массу неудобств в работе команды проекта – вводит дополнительную неопределенность в планирование сроков выполнения этапов
проекта; затрудняет проведения командного обсуждения проблемных
ситуаций, возникающих в
ходе реализации проекта; требует введения
дополнительных правовых, организационных, технических и психологических мер по защите от утечек конфиденциальной информации.
На рис. 20 показан процесс защиты от утечек конфиденциальной информации, который должен быть организован для работы команды проекта
с данными.
Разработка регламента по защите конфиденциальной информации. Следует указать:
информацию (данные) которые нельзя разглашать
правила работы с конфиденциальной информацией
Ознакомление с регламентом сотрудников, которые будут работать в проекте
с конфиденциальной информацией.
Обучение работе с конфиденциальной информацией.
Подписание соглашений о неразглашении
Контроль соблюдения требований регламента по защите конфиденциальной информации.
Мониторинг и использование технических средств защиты информации
Расследование инцидентов и уточнение (внесение изменений) требований регламента:
выявление и регистрация утечек
применение санкций к нарушителям регламента
Рис. 20. Процесс защиты от утечек информации
Заметим, что заказчик может потребовать заключения отдельного
соглашения о неразглашении даже с потенциальными разработчиками
проекта, которые участвуют в обсуждении ИТ-инициативы или технического задания на проект.
В качестве еще одного фактора контекста следует рассматривать
указание в договоре на наличие возможности безопасного отказа от его
продолжения в одностороннем порядке. Законодательно прописаны
случаи такого отказа, но при использовании методологии гибкого
управления реализацией проекта желательно в договоре детализировать
62
дополнительные случаи отказа от продолжения договора в одностороннем порядке. Здесь важно указывать на следующие возможные последствия такого расторжения:
кто будет владельцем авторских прав на ранее переданный заказ-
чику и оплаченный код или владельцем частично разработанного программного обеспечения;
предусмотрен ли возврат выданного аванса на реализацию про-
екта
;
какова процедура возмещения сторонам понесенных убытков и др.
Для максимального снятия неопределенности формирования концепции проекта следует рассмотреть входные и выходные интерфейсы
задач проекта. Они должны пониматься как существенные факторы контекста будущей деятельности разработчиков продукта проекта и деятельности субъектов системы управления проектом. Формирование согласованного представления этих
интерфейсов и экосистемы проекта в
целом на этапе разработки концепции проекта – одна из ключевых задач
управления проектом. В таком случае менеджер проекта управляет коммуникациями разработчиков задач проекта. Качественная реализация
этой роли позволит значительно уменьшить неопределенность реализации проекта в целом. Цель такой деятельности – выделить интерфейсные события и еще на
этапе определения проекта согласовать их
внутри команды проекта с разработчиками задач проекта. Затем следует
согласовать предложения по разработке продукта проекта с заказчиком.
Подчеркнем, что эти работы желательно проводить на этапе формирования концепции проекта. На рис. 21 схематично представлена реализация описанного процесса командой проекта.
Как показано выше, на этапе разработки
концепции проекта (технического задания) желательно учесть уровень неопределенности в модели бизнес-контекста организации, где будет внедряться продукт проекта, на процесс разработки этого продукта. Следует также учесть неопределенность бизнес-контекста деятельности команды проекта.
Поэтому, говоря о контексте разработки ИТ-проекта, будем выделять
следующие контексты.
1. Бизнес-контекст ИТ-
проекта. Он содержит две компоненты, которые должны быть согласованы. Это контекст продукта ИТ-проекта
в организации – заказчике проекта и бизнес-контекст реализации ИТпроекта как разового предприятия, имеющего определенную организационную структуру управления проектом.
63
Определение целей, содержания и границ проекта в качестве предложений
для включения в техническое задание
Презентация целей и содержания проекта ведущим членам команды проекта
или руководителям задач проекта
Использование модели черного ящика для анализа необходимых входов для
решаемой задачи (что должно быть на входе?) и понимания выходов (что будет
получено на выходе?). Руководитель задачи может провести декомпозицию задачи и согласовать интерфейсы элементов задачи с разработчиками задачи
Анализ согласованности интерфейсных событий в разработке продукта проекта.
Оценка возможности сборки образа целого – предложения по концепции проекта
для согласования с заказчиком
Нет Да
Интерфейсы согласованы?
Предложение по корректировкам
моделей задач
Предложение для согласования
(утверждения) заказчиком
Рис. 21. Процесс согласования ключевых интерфейсных событий
2. Контекст пользовательской деятельности. Количество его компо-
нент определяется количеством пользовательских профилей или персонажей, на которых рассчитан продукт проекта. Понимание его принципиально важно в разработке пользовательских интерфейсов – решении
задач UХ-дизайна.
3. Контекст деятельности команды проекта. Он определяется, как
было показано выше, сложностью проекта, экосистемой проекта, контекстными событиями, условиями
формирования команды проекта,
особенностями организации управления проектом, контекстами ролей,
которые должны исполняться командой проекта на различных фазах его
жизненного цикла, и др.
4. Контекст деятельности членов команды проекта. Шаблоны представления этой деятельности во многом совпадают с шаблонами представления контекста пользовательской деятельности.
64
Для анализа контекста деятельности субъектов важно использовать
определенные модели. Они необходимы для постановки вопросов,
на которые нужно получить ответы. Это вопросы о знаниях, используемых будущими пользователями продукта проекта в своей деятельности
в настоящем. Здесь следует придерживаться следующего правила: внимательно слушайте пользователя и не разыгрывайте из себя специалиста в
его предметной области, не старайтесь казаться умнее его. Ведь
задачу сборки образа целого при выборе действий в предметной области
решает в настоящем и будет решать в будущем, при работе с продуктом
проекта, только он [18].
3.2. СИСТЕМНОЕ ПРЕДСТАВЛЕНИЕ БИЗНЕС-КОНТЕКСТА
ИТ-ПРОЕКТА
В анализе бизнес-контекста реализации ИТ-проекта как разового
предприятия
следует определиться с организационной структурой реализации управления проектом. Различие будет существенным в зависимости от реализации проекта в проектно-зависимой, проектно-ориентированной организации или реализации в виде стартапа. Существуют три
основные организационные формы для управления проектами в организациях: линейно-функциональная, функционально-матричная и чисто
проектная [5]. Выбор и
настройка на условия конкретного проекта подходящей формы управления проектом зависит от многих факторов, касающихся как самого процесса разработки проекта, так и факторов контекста организации, где будет внедряться продукт проекта. Ведь большинство организаций имеет достаточно различающиеся представления
о бизнес-моделях своей деятельности. Как правило, эти представления
включают в
себя утверждения по поводу миссии, основных целей организации, критических факторов успеха, принятых стратегий, описания
основных функций, а также структур и процессов, необходимых для их
реализации. Напомним, что проекты, инициируемые организацией-заказчиком, как показано в разделе 2, – это инструменты стратегического
управления организаций.
Дадим краткую характеристику организационных форм. Форма
определяет структуру
ролей и постов в команде проекта, что позволяет
в определенной мере сделать предсказуемыми взаимоотношения при
реализации проекта. Каждая форма имеет свои достоинства и недостатки, но принципиально важным является фактор наличия опыта ее
применения.
65
Если проект реализуется собственными силами организации, в которой для управления используется традиционная линейно-функциональной структура, то возможна следующая схема реализации проекта:
работы по проекту распределяются между существующими функ-
циональными подразделениями;
не создаются новые роли или структуры для управления проектом;
управление работами по проекту осуществляется в рамках
существующей системы ролей и постов, ориентированной на реализацию
операциональной деятельности в рамках существующей бизнес-модели.
В случае использования функционально-матричной структуры для
управления проектом в дополнение к ролям существующей линейнофункциональной структуры управления создаются роли координатора
или менеджера проекта. Работы по проекту также выполняются персоналом функциональных подразделений,
который остается в подчинении
своего руководителя, но часть полномочий по управлению выделенными сотрудниками для проведения работ по проекту передается координатору проекта. Его роль – согласование работы сотрудников функциональных подразделений, которые будут задействованы в проекте,
с планом работ по проекту. Линейное управление этим персоналом
остается за руководителем функционального подразделения. Координа
-
тор проекта может работать на условиях частичной или полной занятости в проекте. Отсутствие опыта работы в таких структурах может приводить к конфликтам интересов руководителей подразделений и менеджеров или координаторов проекта.
Введение должности менеджера проекта, работающего с полной за-
нятостью в проекте, или создание офиса проекта в рамках
существующей организационной структуры означает передачу уже большей части
полномочий по управлению персоналом функциональных подразделений, который занят в проекте, в распоряжение менеджера проекта.
В офисе проекта также будут сотрудники, находящиеся в подчинении
менеджера проекта, т. е. появляются подчиненные только ему члены команды проекта.
При использовании чисто проектного управления для
проекта формируется отдельная команда. Отметим, что для управления командой
разработчиков высокотехнологичного проекта обычно создается своя
линейно-функциональная структура, в которой, как показано на рис. 22,
будет два контура управления – управление структурой и управление
функционированием.
66
Рис. 22. Управление структурой и управление функционированием
В результате реализации цикла организационного управления
(цикл 1 на рис. 22), т. е. цикла создания системы ролей и постов в команде проекта для систематического выполнения определенных функций, будут определены:
состав задач или обособленных функций и операций;
исполнители задач (распределение зон и степени ответствен-
ности);
процедуры решения задач (
последовательности и порядка испол-
нения);
регламенты исполнения процессов;
отчетность об исполнении;
контроль исполнения (процедурный контроль).
В результате для каждого сотрудника команды проекта будут определены зоны ответственности, его права и обязанности, выполняемые
функции и необходимые для этого средства.
В основу разработки цикла управления функционированием (цикл 2
на рис. 22) должны
быть положены результаты моделирования исполнения ролей и моделей текущего контроля деятельности. Для реализации управления функционированием следует определять:
1) критерии оценки качества решений;
67
2) формальную систему коммуникаций, включая подсистему сбора
информации о текущем состоянии управляемой системы;
3) инструментальные средства поддержки принятия решений по ре-
гулированию управляемых процессов;
4) систему контроля результатов;
5) систему анализа причин отклонений и регулирования;
6) систему учета результатов и формирования отчетности и др.
Заметим, что эффективное организационное и функциональное
управление проектом невозможны
без разработки сценариев поведения
среды, т. е. всегда необходим учет текущих и прогнозируемых значений
факторов контекста. На рис. 23 показан пример схемы канвы (шаблона)
представления контекста реализации проекта в целом как управляемой
организации [51]. Здесь под бизнес-контекстом жизнедеятельности организации понимается наличие учтенных и неучтенных факторов среды
в ее системном представлении, используемом
на различных уровнях организации управления бизнесом. Это учитываемые в моделях деятельности организации как целого (т. е. актуализируемые и формально определенные) факторы внешней и внутренней среды организации (факторы
контекста), которые понимаются ее руководством как сильные и слабые
стороны или как возможности и угрозы для деятельности организации
[13, 30, 45].
Демогра-
фические
тренды
Правила
и законо-
дательство
Экономи-
ческий
климат
Конку-
ренты
Организация
Канва (шаблон)
бизнес-модели организации
Технологиче-
ские тренды
Рис. 23. Канва контекста организации в целом
Потребности
клиента
68
Неопределен-
ности
Уровни системного представления бизнес-контекста ИТ-проекта по-
казаны на рис. 24 и 25.
Воздействие со стороны политической, экономической, социальной, правовой, технологической и природной среды, в которой осуществляется деятельность организации
Внешний контекст организационных изменений
Контекст организационных изменений
Влияние наличия формальной и неформальной структуры управления и коммуникаций,
культуры, потенциала организации (сильных и слабых сторон), возможностей и угроз,
распределения власти и влияния заинтересованных сторон в организации
Внутренний контекст организационных изменений
Рис. 24. Контекст организационных изменений
Бизнес-контекст команды
проекта
Внешний
контекст
Элемент
контекста
Рис. 25. Уровни системного представления бизнес-контекста
Таким образом, контекст организационных изменений касается вопросов организации и управления производством продукта ИТ-проекта,
а также вопросов желательности или обязательности учета в ИТ-проекте изменения требований к проекту при изменении внешнего и внутреннего контекста деятельности организации, где будет внедряться
проект.
Бизнес-контекст ИТ-проекта
в целом
Внутренний
контекст
Элемент
контекста
Бизнес-контекст организации
(заказчика)
Внешний
контекст
Элемент
контекста
Внутренний
контекст
Элемент
контекста
69
3.3. КОНТЕКСТ ОРГАНИЗАЦИИ – ПОТРЕБИТЕЛЯ ПРОДУКТА
ИТ-ПРОЕКТА
Контекст организации – это модель, которая дает возможность руководству организации выявлять и понимать внешние и внутренние
факторы ее среды, влияющие на жизнедеятельность организации.
Внешний контекст организации включает в себя внешние заинтересованные стороны, локальную операционную среду ее деятельности,
а также любые внешние факторы, которые
влияют на постановку целей
и задач, а также на способность выполнения поставленных задач.
Внутренний контекст организации включает в себя заинтересованные стороны в реализации ИТ-проекта, используемые методы координации и формы организации бизнеса (подход к управлению), отношения
со своими клиентами, а также потенциал и корпоративную культуру.
Общий обзор контекста организации
, в которой будет внедряться
продукт ИТ-проекта, показан на рис. 26. Составить обзор контекста –
это получить ответы на следующие вопросы.
1. Каковы основные функции (бизнес-процессы) в деятельности ор-
ганизации?
2. Какие сценарии развития бизнеса необходимо учитывать в реали-
зуемом проекте?
3. Какова вероятность реализации этих сценариев?
4. Каков внешний контекст деятельности
организации?
5. Какие необходимы информационные взаимосвязи и процессы об-
работки информации?
Общий обзор контекста
организации
Внешний
контекст
деятельности
организации
Основные
функции.
Цепочки создания
добавленной
стоимости
Модели
используемых
на практике
бизнес-сценариев
Информационные
взаимосвязи
и процессы
Рис. 26. Общий обзор контекста организации
Под бизнес-моделями, как показано в разделе 1, понимается поток
событий, связанных с бизнесом, в который вовлечены различные функции
бизнеса, организационные единицы и активы предприятия. Обеспечение
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]