Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Анализ контекста деятельности в управлении высокотехнологичными проектами. Учебное пособие
.pdf
проекта его образ по основным измерениям (координатам). Формируемый образ проекта по пяти координатам схематично представлен
на рис. 14.
Качество
Согласованные
границы проекта
Кадры
– характеристика неопределенности
– наличие свободы в использовании (изменении) фактора
Рис. 14. Представление образа проекта для менеджера проекта
Функции
продукта
График
Затраты
Согласование границ проекта означает, что достигнуто понимание
сложности продукта проекта и процесса его реализации, а также оценены связи между основными координатами проекта и актуализированными факторами контекста.
Например, при проектировании программных продуктов решаемые
задачи могут быть связаны с автоматизацией реализации конкретных
типовых функций и информационной поддержки деятельности пользователей в
нестандартных ситуациях. Помимо конкретных целей проектирования у любого проекта имеется контекст, который необходимо понимать и учитывать в процессе планирования и управления реализацией
проекта. Этот контекст представляет собой определенную «экосистему» проекта. Кроме характеристики окружения (связей) той работы,
которую предстоит выполнить с другими работами, к нему относят:
рабочую
среду, в которой действуют сотрудники (корпоративную
культуру организации);
41
людей, с которыми необходимо взаимодействовать (необходимо
понимание их ролей, власти и ответственности, прав и обязанностей,
функций и используемых ими средств).
Информация, полученная в результате анализа экосистемы проекта
(бизнес-контекста продукта проекта и контекста деятельности команды
проекта), будет использоваться на всех этапах реализации проекта.
При этом необходимо получить ответы на
следующие вопросы.
Какие роли для этого в команде проекта следует предусмотреть?
Кто будет решать задачи определения экосистемы проекта?
Например, при проектировании веб-сайтов следует определиться
с типом сайта. В зависимости от этого будет существенно различаться
состав и важность учитываемых факторов контекста. Сайт может относиться к одному из
следующих типов [39].
1. Сайт поддержки бренда – постоянно действующая интернет-
площадка, обеспечивающая связь между компанией и целевой аудиторией.
2. Маркетинговый сайт или сайт поддержки проведения маркетинговых акций) – специализированный сайт или приложение для получения конкретного, объективно измеряемого отклика от узкой целевой
группы или целевой аудитории в течение ограниченного периода времени.
3. Контентный сайт – хранилище разнотипной информации (статьи,
документы, видеоматериалы, фотографии, учебники и т. п.), предназначенной для информирования, привлечения или развлечения пользователей.
4. Сайт с функциями задачно-ориентированного приложения – инструмент для решения конкретных задач, в том числе вычислительных. Здесь важен контроль «неограниченного увеличения функциональности».
5. Сайт электронной
коммерции – сочетает элементы первых четырех типов проектов. Сайт должен поддерживать собственный бренд,
предоставлять контент и упрощать выполнение задач (поиск, сравнение,
отзывы, заказ).
6. Образовательное электронное приложение – сочетает особенно-
сти контентных сайтов и задачно-ориентированных приложений.
7. Приложения социальных сетей – обеспечивают пользователям
функции поиска друзей, включения их в свой список, управления про
-
филем, подключением, отправки сообщений, поиска информации и др.
42
2.2. ГИБКИЕ ПОДХОДЫ В УПРАВЛЕНИИ ПРОЕКТАМИ
Для высокотехнологичных ИТ-проектов во многих случаях необходимо использовать гибкие подходы в управлении (Agile). Эти подходы
стали считать обязательными многие проектные менеджеры. Главный
критерий выбора Agile – неопределенность [22, 46]. Если можно однозначно описать задачу, разработчик знает, как ее реализовать и это
можно зафиксировать в документах, то в
таком случае Agile не нужен.
Напротив, использование такого подхода создаст дополнительные трудности в управлении проектом.
Заметим, что Agile, или гибкие подходы в управлении, – это не конкретная методика и не набор методик. Это комплекс ценностей и принципов. Перейти на Аgile – значит создать систему управления проектами, в которой персонал проекта следует
философии Аgile. В основе
этой философии лежат четыре ценности и 12 принципов, изложенных
в Аgile-манифесте [22, 46]. Agile-манифест разработки программного
обеспечения представлен в приложении.
Методик, соответствующих ценностям и принципам гибкости Аgileманифеста, достаточно много. Наиболее известные из них – scrum и канбан [22]. Scrum используется в большей части Аgile-проектов. В scrum
реализация проекта разбита на
короткие итерации, называемые спринтами. Рекомендуемая продолжительность спринта – от двух до четырех
недель. Более короткий спринт не позволяет реализовать задачу, более
длинный превращает scrum в подобие мини-водопада.
Каждый отрезок имеет свое планирование, задачи и результат, как
показано на рис. 15. У каждого спринта есть обязательная ретроспектива – мероприятие, в ходе которого команда
анализирует эффективность работы и обсуждает ее повышение. Результатом каждого спринта
должна стать поставка инкремента – готовой к использованию части
продукта, внедряемой опционально. Инкремент должен нести ценность
для потребителя. Таким образом, для заказчика (потребителя) продукт
появляется постепенно, и каждое следующее его улучшение должно
быть полезно.
Scrum – это отличный пример того, чем А
gile отличается от каскад-
ного подхода. Ведь при каскадной модели пользователям только в конце
станет понятно, как работает продукт проекта. Scrum же предполагает
поставку части продукта каждые две-три недели. Такая модель разработки позволяет вносить корректировки в концепцию проекта в процессе его реализации или даже отказаться от последующих этапов.
43
(
Разработка
Старт
– цикл создания минимально жизнеспособного продукта
Планирование
Тестирование
Демонстрация
Внедрение
опционально)
Рис. 15. Цикл создания инкремента в гибком управлении проектом
Главная идея – сотрудничать при разработке проекта. Требования,
возникающие проблемные ситуации и результаты работы обсуждают
сразу все заинтересованные стороны, чем обеспечивается эффективная
обратная связь в управлении проектом в целом. При этом власть и ответственность, а также взаимодействия в команде проекта зависят
во многом от текущих целей и задач.
2.3. РОЛИ В
КОМАНДЕ ПРОЕКТА
Мы не будем рассматривать все роли в команде проекта. Отметим
те роли, в моделях которых важна работа с факторами контекста. Это
роли менеджера проекта, системного или бизнес-аналитика, владельца
продукта и UX-проектировщика. Более подробно остановимся только
на ролях менеджера проекта и системного или бизнес-аналитика, так
как от качественного
исполнения этих ролей будет во многом зависеть
успех проекта.
Роль менеджера проекта
Деятельность менеджера проекта занимает центральное место в команде проекта. Она связана с решением множества задач – от «архитектурных», касающихся создания команды проекта как управляемой организации, до решения координационных задач, обеспечивающих ежедневное взаимодействие сотрудников разных специальностей.
Суть его
деятельности – определение целей и задач управления проектом, обработка информации, выработка и принятие решений, исполнителями которых будут отдельные сотрудники или команда проекта в целом.
Работа менеджера проекта – это сложная интеллектуальная деятельность, требующая специальных знаний и опыта.
44
Менеджер проекта должен одновременно системно представлять
и понимать:
целое и части;
контекст целого и контекст частей;
процесс и результат;
индивидуальные и групповые действия.
Для этого он должен уметь использовать инструментальные средства, подходящие для решения стратегических и оперативных задач
проекта.
Анализируя деятельность менеджера проекта, следует различать три
уровня осуществления им необходимых действий для реализации задач
проекта, за которые он несет управленческую ответственность.
1. Уровень управления непосредственно действием, т. е. самостоятельное его выполнение. Заметим, что непосредственное действие – это
конечная цель управленческих действий.
2. Уровень управления членами команды проекта, которых он побуждает осуществлять те или иные необходимые для
реализации про-
екта действия.
3. Уровень управления информацией, посредством которой оказывается воздействие на индивидов.
Конкретный менеджер проекта использует на практике все три
уровня управленческих действий, но зачастую есть тот уровень, на котором он предпочитает работать. Это важная характеристика его стиля
управления. Есть те, кто предпочитает работать на уровне непосред
-
ственного действия, другие ориентируются в основном на работу
с людьми. Тяжело работать в команде проекта с теми, кто опирается
в основном на управление информационными потоками.
Эффективность работы менеджера проекта зависит от наделения его
непрерывной ответственностью за результаты проекта на всех этапах
его жизненного цикла. Поэтому на роль менеджера крупного высокотехнологичного ИТ-проекта всегда требуется назначение сотрудника
с полной занятостью.
При работе менеджера проекта с частичной занятостью в матричных
структурах управления происходит размывание ответственности за конкретный проект между ним и руководителями функциональных подразделений.
В слабых матричных структурах не вводится должность менеджера
проекта, а эта роль разделяется между несколькими сотрудниками
орга-
низации, реализующей проект, – назначаются координатор проекта
45
с частичной занятостью, ответственные за выполнение расписания проекта, стоимость проекта, администрирование контрактов и др. Такое
разделение чаще всего приводит к конфликтам и полному размыванию
ответственности за проект в целом.
Заметим, что менеджер сложного проекта не может сам выполнять
все операции по управлению проектом – планирование, комплектование
штатов, организацию работ, контроль и
оценку. В его распоряжении
должны быть службы или сотрудники со штабными полномочиями, руководство которыми он будет осуществлять. При этом его управленческая ответственность за проект в целом не может делегироваться подчиненным.
Должность менеджера проекта является интегрирующей, так как
назначенный на эту должность сотрудник объединяет усилия всех
участников проекта,
находящихся под его непосредственным руководством, и координирует взаимодействия с субподрядчиками. Он отвечает
за правильную расстановку приоритетов – что должно быть сделано, когда это должно быть сделано, как выполнить работы проекта в рамках
согласованного с заказчиком бюджета.
В литературе уделяется большое внимание этой роли. Мы остано-
вимся только на том аспекте
роли менеджера проекта, который касается
согласования интерфейсных событий в проекте.
Интерфейс – это определенная стандартами (соглашениями) граница между взаимодействующими объектами (системами). Он определяет параметры, процедуры и характеристики взаимодействия объектов. Например, интерфейс прикладной программы (Application Program
Interface, API) обеспечивает предоставление различных видов сервиса:
доступ к операционной системе;
обмен информацией по
каналам связи между распределенными
в пространстве процессами;
доступ к базам данных;
взаимодействие прикладных программ;
взаимодействие с пользователем.
Необходимо различать понятия интерфейсов продукта и интерфейса
проекта в характеристике предметов деятельности менеджера проекта [5].
Интерфейсы продукта относятся только к тому, что создается для
клиента. Это может быть аппаратное и программное обеспечение
, различного рода услуги, документация и др. Интерфейсы подразделяются
на эксплуатационные (стыки между компонентами или подсистемами
продукта) и физические (стыки между частями продукта). Эксплуатаци-
46
онные интерфейсы отражают связи продукта проекта в информационной системе организации – заказчика проекта.
Выделяют несколько категорий интерфейсов проекта, которые следует рассматривать как интерфейсные события. Здесь события – это моменты, которые указывают, когда совершается конкретное действие
(прогнозируемое, запланированное или совершенное). Заметим, что интерфейсные события – это связующие события проекта. Они
могут касаться изменения функциональной ответственности, результатов выполнения задач, действий руководства проекта, взаимодействий с заказчиком проекта, поставки материалов и оборудования, обмена информацией. Такие события следует рассматривать как часть элементов контекста (планируемого и реализуемого на практике) для руководителей
функциональных подразделений и лидеров проекта. Эта часть контекста касается
технических, управленческих и прочих входов (информация, ресурсы, разрешения, утверждения и др.), а также промежуточных
и конечных результатов решения задачи, которые должны быть переданы другим членам команды проекта.
Роль системного (бизнес-) аналитика
Эта роль ключевая в анализе контекста продукта высокотехнологич-
ного проекта. В команде любого ИТ-проекта обязательно должен
быть
человек, явно или неявно выполняющий роль аналитика. Его задачи:
выявить заинтересованных лиц проекта;
собрать и проанализировать мнения заинтересованных сторон и лиц;
прежде всего выяснить, для чего нужна пользователям новая система;
отразить результаты анализа в концепции проекта и специфика-
ции требований;
определить пользовательские функциональные, нефункциональ-
качественные требования, на основе которых команда сможет
ные и
оценить и спланировать проект, а также спроектировать, построить
и проверить продукт;
передать информацию другим заинтересованным в проекте лицам.
Бизнес-аналитик согласовывает возможные изменения в организационном контексте стороны заказчика, определяя потребности и рекомендуя решения, которые представляют ценность для заинтересованных лиц.
также является посредником во взаимодействии заказчика и ко-
Он
манды проекта – проясняет нечеткие представления пользователей и заинтересованных лиц, преобразуя их в четкие спецификации для команды разработчиков продукта.
47
Название должности для исполнения этой роли в организациях может быть разным. Например, аналитик по требованиям, системный аналитик, инженер по требованиям, менеджер по требованиям, прикладной
аналитик, аналитик бизнес-систем, ИТ-аналитик и др. Главное для
участника проекта – правильно понимать содержание этой роли и исполнять ее.
Заметим, что функции аналитика
могут выполняться как дополнительные несколькими членами команды параллельно со своими основными обязанностями. Иногда они возлагаются на менеджера проекта.
Аналитик прежде всего должен уметь применять разные средства сбора
информации и уметь представлять эту информацию различными способами [36]. Основные факторы успеха его работы – терпение и искреннее
желание работать с людьми.
Как профессионал в этой области он должен обладать одновременно
следующими качествами:
развитыми коммуникационными навыками;
знанием психологии межличностного общения;
необходимыми техническими знаниями для понимания предмет-
ных областей деятельности команды проекта;
знаниями предметной области бизнеса, где будет внедряться про-
дукт проекта;
личными качествами, подходящими для этой работы.
Обратим
внимание на следующие возможные ситуации в исполне-
нии роли аналитика:
роль выполняется командой проекта, и менеджеры проекта ожи-
дают, что функции аналитика будут выполнять разработчики. На практике навыки и личные качества, необходимые разработчику, значительно отличаются от тех, которые необходимы системному аналитику
проекта;
роль выполняется персоналом или
приглашенным специалистом
на стороне заказчика проекта;
на эту роль в команду проекта приглашается специалист со сто-
роны.
Заметим, что при возложении этой роли на разработчиков проекта
возникает определенная психологическая проблема. Разработчики
нетерпеливы при работе с пользователями и другими заинтересованными лицами на стороне заказчика, считая эту работу обузой для себя
.
Они стремятся как можно быстрее перейти к программированию – работе, предметную область которой они хорошо знают. При этом они
48
осознают важность процесса создания требований. Проблема в том, что
разработчики в роли аналитика должны достаточно подробно ознакомиться с предметной областью бизнеса заказчика проекта. Однако они
переходят на присущее ИТ-сфере техническое мышление и жаргон, концентрируясь на функциях программного продукта, который надо создать. Здесь же важно понимание потребностей
и контекстов деятельностей пользователей и других заинтересованных лиц проекта на стороне заказчика. Поэтому из анализа часто опускается понимание бизнес-контекста и контекста деятельности пользователей приложения,
представление которого будет необходимо для качественного проектирования будущего опыта деятельности пользователей продукта проекта.
На рис. 16 показаны взаимодействия и предметы деятельности системного
проекта.
аналитика на этапах формирования концепции и определения
Куратор проекта
Управление
проектом
Бизнес-требования
Пользователи
Пользовательские
требования
Другие
заинтересованные
лица
Ожидания
и ограничения
Системный
аналитик
Функциональные
и нефункциональные
требования
Масштаб
и сложность.
Состояние требований
Проектирование
Разработка
Функциональные
и нефункциональные
требования
Тестирование
Рис. 16. Предметы деятельности и взаимодействия системного аналитика
49
Дадим краткую характеристику роли UX-проектировщика в команде проекта (UX – сокращение от User eXperience, что буквально
означает «опыт пользователя»). В отечественной практике распространенным переводом этого термина является «опыт взаимодействия пользователя». Кроме разработки человеко-компьютерного взаимодействия
UX-проектировщику часто приходится выполнять в проекте еще несколько ролей. Эти роли – независимо от того, определены
они офици-
ально в команде проекта или нет, – зависят от следующих факторов:
типа проекта;
состава проектной команды;
опыта работы с командами проектов, который есть у заказчика.
Следует четко позиционировать место UX-проектировщика с самого начала работы над проектом, чтобы исключить ложные ожидания
от обязанностей, связанных с этой ролью
у других участников проекта.
Важно также согласовать со стороной заказчика содержание роли
UX-проектировщика, если такая должность будет предусмотрена в проекте. На практике роль UX-проектировщика имеет разные названия
(или может никак не обозначаться, если в проекте не существует формальной должности такого типа). Ее исполнение может быть распреде-
между информационным архитектором, проектировщиком взаи-
лено
модействия, юзабилити-аналитиком.
Наличие концепции продукта ИТ-проекта гарантирует, что все в команде проекта знают, куда идут. Задание границ проекта гарантирует,
что они говорят при этом об одной и той же вещи в проекте или его
итерации.
Говоря о концепции, мы подразумеваем весь продукт. Концепция
может изменяться относительно медленно при уточнении со временем стратегии реализации продукта или при изменении бизнес-целей заказчика.
Границы же относятся к определенному проекту или его итерации, в которых реализуются возможности продукта. Они более динамичны, чем
концепция, при использовании гибкого управления проектом. Заинтересованные лица могут изменять содержимое
каждого выпуска (версии)
в соответствии с ограничениями графика, бюджета, ресурсов и качества.
При этом границы текущего выпуска всегда должны быть четко определены. Границы будущих выпусков в реализации проекта тем менее четко
определены, чем более дальняя перспектива рассматривается. Задача команды проекта состоит в четком управлении границами текущего
выпуска проекта как
определенным подмножеством стратегической
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]