Разработка информационного обеспечения процесса подбора команды ИТ проекта

Чупахина Е.И.

Разработка информационного обеспечения процесса подбора команды ИТ проекта

38.04.05 Бизнес-информатика

Информатика

Дипломы

Вуз: Белгородский государственный университет - национальный исследовательский университет (НИУ «БелГУ»)

ID: 5b8873577966e1073081b1c2

UUID: 337844e0-8ed4-0136-b085-525400005860

Язык: Русский

Опубликовано: больше 5 лет назад

Просмотры: 13

Чупахина Е.И.

Источник: Федеральное государственное автономное образовательное учреждение высшего образования «Белгородский государственный национальный исследовательский университет»

Комментировать 0

Рецензировать 0

Скачать - 1,5 МБ

Поделиться работой

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БЕЛГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ» ( Н И У « Б е л Г У » ) ИНСТИТУТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ И ЕСТЕСТВЕННЫХ НАУК КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ РАЗРАБОТКА ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ПРОЦЕССА ПОДБОРА КОМАНДЫ ИТ ПРОЕКТА Выпускная квалификационная работа обучающегося по направлению подготовки 38.04.05 «Бизнес-информатика» заочной формы обучения, группы 07001471 Чупахиной Елены Игоревны Научный руководитель к.т.н., доцент, Ломакин В.В. Рецензент доцент кафедры техническая кибернетика Института энергетики, информационных технологий и управляющих систем БГТУ им. В.Г. Шухова, к.т.н. Порхало В.А. БЕЛГОРОД 2017

СОДЕРЖАНИЕ Введение ....................................................................................................................... 3 1 Исследование существующих подходов к подбору команды ИТ проекта ....... 7 1.1 Исследование методологических подходов подбора команды ИТ проекта ................................................................................................................... 7 1.2 Анализ инструментальных средств подбора команды ИТ проекта ...... 21 1.3 Выводы по главе ......................................................................................... 24 2 Разработка процедуры подбора команды ИТ проекта ...................................... 25 2.1 Разработка функциональной схемы процесса подбора команды ИТ проекта ................................................................................................................. 25 2.2 Разработка и описание процедуры подбора команды ИТ проекта ........ 30 2.3 Разработка концептуальной схемы базы данных для информационной системы подбора команды ИТ проекта .................................................................. 51 2.4 Выводы по главе ......................................................................................... 56 3 Экспериментальная проверка работоспособности процедуры подбора команды ИТ проекта ................................................................................................. 58 3.1 Определение потребности в ресурсах для ИТ проекта ........................... 58 3.2 Подбор кандидатов для каждой роли ИТ проекта .................................. 70 3.3 Выводы по главе ......................................................................................... 78 Заключение ................................................................................................................ 79 Список использованных источников ...................................................................... 81 Приложение ............................................................................................................... 90

ВВЕДЕНИЕ Актуальность темы. Аналитической компанией IDC были опубликованы краткие результаты исследования российского рынка ИТ услуг. Результаты данных исследований показали, что в 2015 году продажи ИТ услуг в России составили $4,52 млрд. Рынок ИТ услуг включает услуги: внедренческого консалтинга, системной интеграции, установки и поддержки оборудования и ПО. Как правило, предоставление ИТ услуг осуществляется на основании ИТ аутсорсинга, который предполагает делегирование внешней специализированной компании решение вопросов, связанных с разработкой, внедрением и сопровождением информационных систем, как целиком на уровне инфраструктуры предприятия (сопровождение оборудования или ПО), так и объёмов работ, связанных с развитием и/или поддержкой функционирования отдельных участков системы [37]. Компании, предоставляющие ИТ услуги, как правило, по каждому договору предоставления услуг инициируют ИТ-проект. Проект – это комплекс мероприятий, направленных на создание уникального продукта или услуги в условиях временных и ресурсных ограничений [30] по определению ГОСТ Р 54869-2011. ИТ проект является разновидностью более общего термина «Проект». По данным The Standish Group International, в 2014 году 52,7% ИТ проектов столкнулись во время разработки с проблемами, которые оказали значительное влияние на длительность, бюджет, качество и впоследствии привели к изменению ранее запланированных целей и ожидаемых результатов. Порядка 31% проектов были остановлены и не завершены. Согласно опубликованным данным, средняя стоимость завершенных проектов в сфере информационных технологий в 2014 году составила 189% от первоначальных 3

оценок (CHAOS Manifesto 2014: Value versus Success&the Orthogonals/ The Standish Group International 2014) [49]. Приведенная статистика показывает, что успешное завершение ИТ проекта является сложной задачей и складывается из множества факторов. В соответствии с ГОСТ Р 54869-2011 команда проекта - это совокупность лиц, групп и организаций, объединенных во временную организационную структуру для выполнения работ проекта. Так как термин «ИТ проект» является частным случаем термина «Проект», то можно сказать что термин «Команда ИТ проекта» является частным случаем термина «Команда проекта». Команда проекта - это один из наиболее сложных объектов управления при реализации проектов. Для каждого нового проекта участники команды подбираются заново. Ресурсные менеджеры основной упор делают на профессиональные качества, технические компетенции и проектный опыт исполнителей – участников проектной команды. На сегодняшний день компаний, предоставляющих услуги ИТ консалтинга достаточно много, а значит конкуренция среди компаний высока. По условиям рынка выигрывает та компания, которая предоставляет оптимальное сочетание цены и качества предоставляемого продукта. Так как продукт, который предоставляют подобные компании — это результаты интеллектуального труда, то уровень проектной команды имеет ключевую роль в вопросах конкуренции. Можно сделать вывод, что выигрывает та компания, которая смогла максимально сохранить и приумножить свои человеческие ресурсы, сохранить наиболее грамотных сотрудников. Соответственно задача подбора команды ИТ проекта является важной и достаточно сложной. Необходимо решить задачу подбора участников в команду учитывая множество фактов и критериев. Объектом исследования является процесс подбора команды ИТ проекта. Предмет исследования – методики, модели и алгоритмы в процессе подбора команды ИТ проекта. 4

Целью магистерской диссертации является рациональное распределение человеческих ресурсов в процессе подбора команды ИТ проекта. Для достижения цели необходимо решить следующие задачи: исследование существующих методик и программных продуктов подбора персонала для ИТ проектов; разработка функциональной схемы процесса подбора команды ИТ проекта; разработка процедуры подбора команды ИТ проекта, охватывающей все этапы данного процесса; разработка концептуальной схемы базы данных для информационной системы поддержки процесса подбора команды ИТ проекта. Методы исследования. При решении указанных задач использовались методология функционального моделирования IDEF0, методология разработки реляционных баз данных IDEF1X, теория автоматического управления, системный анализ, методы многокритериальной оптимизации, теория принятия решений. Научную новизну работы составляют: процедура подбора команды ИТ проекта, обеспечивающая рациональное распределение человеческих ресурсов в структуре команды ИТ проекта; введением модифицированная RACI матрица, отличающаяся от стандартной процента занятости исполнителя для каждой задачи, что обеспечивает более точный учет ресурсов при их распределении на задачи проекта; матрица совместимости выполняемых исполнителем задач, обеспечивающая правильное распределение исполнителей по задачам в модифицированной RACI матрице. Практическая значимость работы заключается в том, что: результаты работы могут быть использованы для разработки информационной системы поддержки процесса подбора команды ИТ проекта; 5

повысить разработанная процедура подбора команды ИТ проекта позволит эффективность использования человеческих ресурсов при выполнении ИТ проектов. Апробация работы. Основные положения и результаты диссертационного исследования были опубликованы на IV Международной научно-практической конференции «Научно-технический прогресс: актуальные и перспективные направления будущего» (2016г., г. Кемерово). Положения, выносимые на защиту: функциональная схема процесса подбора команды ИТ проекта; процедура подбора команды ИТ проекта; концептуальная схема базы данных для информационной системы поддержки процесса подбора команды ИТ проекта. Публикации. По теме исследования опубликованы научные работы: 1) Чупахина, Е.И. Построение онтологии предметной области «Команда ИТ-проекта» в среде PROTEGE [Текст] / Е.И. Чупахина, В.В. Ломакин // Сборник материалов Международной научно-технической конференции «Современные тенденции развития науки и производства», Том 1. – Кемерово: ЗапСибНЦ, 2016. – С. 158-162. 2) Чупахина, Е.И. Функциональная схема процесса подбора участников команды ИТ-проекта [Текст] / Е.И. Чупахина, И.А. Чупахин, В.В. Ломакин // IV Международная научно-практическая конференция «Научно-технический прогресс: актуальные и перспективные направления будущего», Том 1. – Кемерово: ЗапСибНЦ, 2016. – С. 89-91. Объем работы. Диссертационная работа изложена на 89 страницах машинописного текста, содержит 21 иллюстрацию и 20 таблиц, состоит из введения, трех глав, заключения, списка литературы, включающего 71 наименование, и одного приложения. 6

1 ИССЛЕДОВАНИЕ СУЩЕСТВУЮЩИХ ПОДХОДОВ К ПОДБОРУ КОМАНДЫ ИТ ПРОЕКТА 1.1 Исследование методологических подходов подбора команды ИТ проекта Люди – один из факторов успеха практически любого проекта, поэтому в ИТ проектах «человеческий фактор» играет одну из главных ролей. Грамотно подобранная команда обеспечит большую часть успеха проекта [5]. Процесс подбора команды проекта предполагает, что для работы назначаются требуемые люди или группы [5] людей. В процессе подбора необходимо добиться того, чтобы выбрать из доступных ресурсов наиболее подходящие. Исходными данными для подбора персонала является описание возможностей специалистов, включающее предыдущий опыт работы, личные интересы, личностные характеристики, доступность в требуемое проектом время. Одна из важнейших стратегических целей управления проектом состоит в том, чтобы усилия всех активных участников проекта были направлены на достижение единой цели и при этом удовлетворялись интересы всех участников и заинтересованных лиц. Если собственные интересы отдельных участников превалируют над целями проекта, такая ситуация может вылиться в череду конфликтов и привести к неэффективным проектным решениям[5]. За подбор команды ИТ проекта, как правило, отвечает руководитель проекта. В задачи команды входят обследование предприятия, проектирование и оптимизация бизнес-процессов с помощью внедряемой системы, разработка и тестирование отдельных модулей, внедрение и интеграция в общую ИТ инфраструктуру. Команда проекта состоит из команды управления проектом и команды исполнителей проекта. Команда проекта подчиняется руководителю проекта. Команда управления проектом включает следующие роли: координатор проекта, администратор проекта, менеджер по конфигурации. В крупных проектах к выполнению каждой из этих ролей может быть привлечено 7

нескольких человек. Приведенный список ключевых ролей команды управления проектом является необходимым для управления работами при внедрении информационной системы. Допускаются некоторые модификации состава команды в зависимости от сложности и масштабности проекта [29] – роли могут как добавляться, так и упрощаться. В состав команды исполнителей проекта входят функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик. В зависимости от масштаба проекта один член команды может выступать одновременно в нескольких ролях. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика [29]. На текущий момент существуют различные методологии и стандарты в части управления проектами, которые широко применяются на практике. Данные методологии и стандартны так же включают в себя часть по подбору команды проекта. Ниже описаны стандарты, которые используются в управлении проектами. ГОСТ 54869―2011 «Проектный менеджмент, Требования к управлению проектами» - устанавливает требования к управлению проектом от его старта до завершения, при этом предметом стандартизации являются обязательные выходы процессов управления проектом [30]. Данный ГОСТ содержит раздел (пункт 5.3.4 Процесс планирования персонала проекта), посвященный теме подбора команды для выполнения проекта. 8

В соответствии с данным ГОСТом целью процесса является определение порядка обеспечения проекта человеческими ресурсами, выходы процесса это: определены и документированы роли участников проекта, их функции и полномочия; определен численный и квалификационный состав команды проекта, а также требования к условиям труда; персонально определены основные члены команды проекта [30]. PMBoK - Project Management Body of Knowledge – методология по управлению проектами признанная национальным стандартом ANSI (American National Standards Institute). Данная методология охватывает весь спектр процессов управления проектом, в том числе и процесс управления человеческими ресурсами проекта [57]. Структура методологии приведена на рисунке 1.1. В соответствии с данной методологией общая схема управления человеческими ресурсами проекта включает следующие этапы: разработка плана управления человеческими ресурсами; набор команды проекта; развитие команды; управление командой. Процессы управления проектами обычно представляются в виде дискретных элементов с четко выделенными границами, хотя на практике они пересекаются и оказывают взаимное влияние такими способами, которые не могут быть детально описаны в руководстве PMBOK. В качестве примеров взаимосвязи, подлежащей дополнительному планированию можно привести следующие ситуации: после того, как первоначальная команда проекта создала иерархическую структуру, может возникнуть необходимость расширения команды; 9

после расширения состава команды проекта уровень подготовки членов команды может увеличить или уменьшить риски проекта, что вызывает необходимость в дополнительных обновлениях планов по рискам; если оценка длительности операций была выполнена до определения окончательного состава команды проекта, то с привлечением новых членов команды, с учетом их квалификации может возникнуть необходимость в изменении длительности операций [57]. Рисунок 1.1 – Общая схема управления человеческими ресурсами проекта 10

Разработка плана управления человеческими ресурсами представляет собой процесс определения и документирования ролей, ответственности, требуемых навыков и отношений подчиненности, а так же создания плана управления обеспечением проекта персоналом[57]. Иллюстрация процесса разработки плана управления рисунке 1.2. Планирование человеческими ресурсами человеческих ресурсов приведена на используется для определения и идентификации человеческих ресурсов, а так же навыков, необходимых для успеха проекта[57]. Блок-схема процесса плана управления человеческими ресурсами приведена на рисунке 1.3. Рисунок 1.2 – Процесс разработки плана управления человеческими ресурсами Рисунок 1.3 – Блок-схема процесса разработки плана управления человеческими ресурсами Разработка плана управления человеческими следующие входы: 11 ресурсами, имеет

требования к ресурсам операций: для определения потребностей проекта в персонале при планировании человеческих ресурсов используются требования к ресурсам операций; предварительные требования к необходимому для команды проекта персоналу и уровню его квалификации последовательно прорабатываются в рамках процесса разработки плана управления человеческими ресурсами; факторы среды предприятия: факторы, которые могут оказывать влияние на процесс разработки плана управления человеческими ресурсами, включают в себя среди прочего: 1) организационную и культурную структуру; 2) существующие человеческие ресурсы; 3) правила управления персоналом и ситуацию на рынке; активы процессов организации: активы, которые могут оказать влияние на процесс разработки плана управления человеческими ресурсами, включают в себя, среди прочего: 1) стандартные процессы и нормы организации, а так же описания типовых ролей; 2) шаблоны организационных диаграмм и должностных инструкций; 3) историческую информацию по организационным структурам, которые оказались эффективными в предыдущих проектах [57]. Разработка плана управления человеческими ресурсами включает в себя инструменты и методы. Существуют различные форматы документирования распределения ролей и ответственности членов команды. Большинство форматов относятся к одному из трех типов: иерархический, матричный и текстовый. Независимо от того, какой метод используется, цель всегда одна – добиться того, чтобы для каждого пакета работ был назначен один ответственный за его исполнение, и чтобы каждый член команды четко понимал свою роль и сферу ответственности [57]. Одним из наиболее удобных инструментов распределения ролей является 12 матрица распределения

ответственности, наиболее распространенный вариант которой известен как RACI-матрица. Этапы построение матрицы ответственности. Первый этап – перечислить основные работы проекта. По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации [29]. Второй этап – перечислить группы/роли внутри проектной команды. По горизонтали в матрице перечисляются группы/ роли внутри проектной команды. В матрице ответственности указываются именно группы/роли, а не имена и фамилии отдельных членов коллектива. Персональное закрепление проектных работ производится позднее [29]. Третий этап – закодировать матрицу ответственности. С помощью кодов в ячейках на пересечении соответствующих столбцов с ролями и строк с работами проекта указать степень участия, формальные полномочия и распределение ответственности за выполнение каждой операции [29]. Условные обозначения матрицы ответственности приведены в таблице 1.1. Таблица 1.1 – Условные обозначения матрицы ответственности (RACI). Обозначение 1 Исп. (R) Расшифровка Описание 2 Исполнитель 3 Несет ответственность за непосредственное (Responsible) исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя Cогл. (C) Согласующий Согласует (Consulted) взаимодействие с ним носит двусторонний характер 13 принимаемые решения,

Продолжение таблицы 1.1 1 Н. 2 Наблюдатель Его (I) (Informed) взаимодействие с ним носит односторонний характер информируют 3 об уже принятом решении, На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)) [29]. Пример RACI матрицы приведен в таблице 1.2. Таблица 1.2 – Пример RACI матрицы. Роль 4 Роль 3 Роль 2 Наименование задачи Задача 1 Роль 1 Роль R I Задача 2 R C A Задача 3 C A I Матрица распределения R ответственности является удобным инструментом управления. Она позволяет быстро и в наглядной форме ответить на важные для менеджера вопросы, такие, например, как: кто отвечает за данную работу, есть ли работы, за которые никто не отвечает или за которые отвечают несколько исполнителей. На основании построенной матрицы ответственности можно определить необходимое и достаточное количество участников ИТ проекта [29]. Процесс разработки плана управления человеческими ресурсами имеет выходы. Результатом разработки плана управления человеческими ресурсами должен стать план управления человеческими ресурсами, который является неотъемлемой частью плана управления проектом. Данный план должен включать в себя: 14

роли и сферы ответственности; организационные диаграммы проекта; план управления обеспечением проекта персоналом. Набор команды проекта – это процесс подтверждения доступности человеческих ресурсов и набора команды, необходимой для выполнения заданий по проекту. Иллюстрация процесса набора команды проекта приведена на рисунке 1.4. Рисунок 1.4 – Процесс набора команды проекта Процесс набора команды проекта имеет следующие входы: план управления проектом, содержит план управления человеческими ресурсами, в котором имеется информация, используемая для предоставления указаний о порядке определения, набора, управления, контроля и высвобождения человеческих ресурсов с проекта; факторы среды предприятия, которые могут оказывать влияние на процесс набора команды проекта; активы процессов организации, которые могут влиять на процесс набора команды проекта [57]. Процесс набора команды проекта имеет следующие инструменты и методы: предварительное назначение – в некоторых случая члены команды известны заранее, то есть они предварительно назначены на проект; такая ситуация может возникнуть, если в результате конкурсного отбора определенным лицам было обещано участие в проекте, если выполнение проекта зависит от знаний определенных лиц или если назначение 15

определенных лиц на определенные должности предусмотрено уставом проекта; переговоры 1) с обеспечение функциональными проекта руководителями, соответствующими штатом чтобы гарантировать квалифицированных сотрудников на требуемый период времени; 2) с другими командами управления проектами внутри организации; 3) внешними организациями, исполнителями, поставщиками, подрядчиками в отношении подходящих, дефицитных, специализированных, квалифицированных, сертифицированных и прочих человеческих ресурсов определенного типа; набор персонала - если у исполняющей организации для выполнения проекта не хватает штатных специалистов, то требуемые услуги можно получить из сторонних источников; это может выражаться в найме консультантов или передаче части работ сторонним организациям на условиях субподряда [57]. Процесс набора команды проекта имеет следующие выходы: назначение укомплектованным персонала персоналом, проекта когда на - работы проект считается проекта назначены соответствующие лица; ресурсные календари - для указания доступности ресурсов в ресурсных календарях документально фиксируются периоды; времени, в течение которого каждый член команды проекта может принимать участие в выполнении проекта; обновления плана управления проектом [57]. Блок-схема процесса набора команды проекта приведена на рисунке 1.5 16

Рисунок 1.5 – Блок схема процесса набора команды проекта ISO 21500:2012 – руководство по управлению проектами, которое может применяться в организации любого типа. Данный стандарт так же включает раздел по подбору команды проекта. Это раздел 4.3.15 «Формирование команды проекта». В соответствии с данным стандартом целью формирования команды проекта является обеспечение проекта человеческими ресурсами [31]. Руководитель проекта должен определить, как и когда члены команды проекта будут вовлечены в работу и/или освобождены от нее. При отсутствии достаточного объема человеческих ресурсов в организации необходимо рассмотреть возможность найма дополнительных сотрудников или передачи части работ на субподряд другой организации. Кроме того, должны быть определены места выполнения работ, обязанности работников, роли и ответственность, а также требования к отчетности и организации взаимодействия. Руководитель проекта может контролировать отбор членов команды проекта полностью или частично, но в любом случае он должен принимать участие в отборе. При наличии возможности, руководитель при формировании команды проекта должен учитывать такие факторы, как знания и опыт кандидатов, их личные особенности, а также динамику поведения в группах. Поскольку внешняя среда проекта обычно подвержена изменениям, процесс формирования команды может осуществляться на протяжении всего 17

проекта [31]. Основные входные и выходные данные процесса приведены в таблице 1.3. Таблица 1.3 – Входные и выходные данные процесса формирования команды проекта. Входные данные Выходные данные Потребности в ресурсах Назначение персонала проекта Организационная структура проекта Договоры о найме Наличие ресурсов Планы проекта Описание ролей Кроме того раздел 4.3.16 «Оценка ресурса проекта» дает рекомендации по оценке ресурсов проекта для возможности подбора. В соответствии с данным разделом целью оценки ресурсов проекта является определение того, какие ресурсы необходимы для каждой работы из списка работ. Результаты оценки должны содержать данные об объеме ресурсов, их характеристиках, источниках, а также даты начала и завершения работы на проекте [31]. Основные входные и выходные данные процесса оценки ресурсов проекта представлены в таблице 1.4. Таблица 1.4 – Входные и выходные данные процесса оценки ресурсов проекта. Входные данные Выходные данные Список работ Потребности в ресурсах Планы проекта План обеспечения ресурсами Утвержденные изменения Помимо международных стандартов существую локальные методики, которые дают рекомендации по подбору участников в команду проекта. 18

Так Грекул В.И. в книге «Методические основы управления ИТ проектами» рекомендует на этапе планирования для каждой роли определить список навыков, необходимых членам команды проекта. Для разработки списка рекомендуется использовать реестр навыков - список категорий и компонентов навыков для определенного класса команды исполнителей проекта [29]. Пример реестра навыков приведен в таблице 1.5. Таблица 1.5 – Реестр навыков для команды исполнителей проекта. Категории и компоненты навыков Технические навыки Навыки межличностного общения и Умение управлять проектом и его лидерства технологией Оказание помощи в разрешении проблем проблем проекта Взаимодействие с Участие в достижении компромиссов Понимание Наличие Определение целей Получение поддержки высшего руководства основных задач маркетинга Построение техническим многофункциональной команды персоналом Оказание помощи в решении навыков Мотивация членов команды Управление конфликтами системного анализа Административные навыки Привлечение Стратегические навыки уникальных специалистов Стратегическое планирование Принятие Навыки эффективного общения решений Умение делегировать полномочия Ведение переговоров с Умение работать в условиях целью риска обеспечения ресурсами Календарное планирование Сотрудничество с стратегических другими проектными командами 19 Умение лидировать

Для обеспечения анализа совокупностей навыков компоненты группируются в четыре категории: технические навыки, административные, навыки межличностного общения, стратегические навыки. Для каждого навыка отмечаются рейтинг критичности и рейтинг способностей [29]. Для оценки рейтинга принято использовать 4-балльную шкалу (таблица 1.6). Таблица 1.6 – Шкала рейтингов критичности и способностей. Рейтинг Критичность Квалификация 1 Неважно/Маловажно Отсутствие навыков / слабые навыки 2 Важно Базовые навыки 3 Очень важно Высокая квалификация 4 Критично для успеха проекта Уникальная квалификация Реестры навыков должны быть составлены для каждого класса персонала, как, например, для руководителя проекта, системного архитектора, специалиста по качеству. Критичность навыков для руководителя проекта определяется во многом масштабом проекта и организационной структурой проекта. Список навыков может быть определен на основе профессиональных стандартов в области информационных технологий. Распределение навыков зависит от уровня административной ответственности. Рейтинг критичности смещается от "технических" в сторону "административных", а затем в сторону "межличностного общения" и "стратегических навыков" по мере роста административной ответственности. Следует подчеркнуть важность навыков межличностного общения. Команда проекта может многократно снизить количество возникающих проблем и повысить взаимодействие сотрудников, если будет понимать настроение членов команды проекта, предвидеть их действия, внимательно выслушивать и признавать их мнение и решать их проблемы. После того как реестр сформирован, он может быть использован с минимальной точной подстройкой к новой проектной ситуации [29]. 20

1.2 Анализ инструментальных средств подбора команды ИТ проекта Для подбора сотрудников компанией SAP было разработано решение ERecruiting передовое решение, включающее все необходимые компаниям функции управления подбором персонала, охватывающее весь процесс от планирования и бюджетирования до привлечения кандидатов и приема на работу. С помощью формирования базы данных внутренних и внешних кандидатов SAP E-Recruiting помогает грамотно построить отношения с потенциальными сотрудниками на самой ранней стадии процесса подбора. Четкие требования вакантной должности и возможности различных оценок кандидатов позволяют подбирать правильных людей, а наличие базы внутренних кандидатов позволяет сократить временные и финансовые издержки на подбор персонала и удержать талантливых специалистов внутри компании. На рисунке 1.6 приведен пример интерфейса поиска кандидатов в команду решения SAP E-Recruiting. Рисунок 1.6 – Пример интерфейса поиска кандидатов в команду В составе решения SAP E-Recruiting инструменты для: 21 имеются эффективные

формирования заявки на поиск; предварительного отбора кандидатов; собеседований и оценки кандидатов; финального отбора кандидатов; приема кандидата и закрытия вакансии. Компанией ООО «Сайнер» была разработана функциональность, позволяющая формировать требования к таким объектам как штатная должность и далее выполнять сопоставление и анализ с существующими сотрудниками. Для этих целей был разработан каталог профессиональных компетенций. Пример структуры каталога приведен на рисунке 1.7. Для каждой штатной должности был разработан профиль требований на основании каталога компетенций, а для каждого сотрудника проведена оценка по данному каталогу компетенций. На основании полученных данных по штатным должностям и сотрудникам возможно получать различные отчетные формы и в дальнейшем проводить анализ данных. На рисунке 1.8 приведен вид каталога профессиональных компетенций. Рисунок 1.7 – Структура каталога профессиональных компетенций 22

Рисунок 1.8 – Вид каталога профессиональных компетенций Если рассматривать процесс подбора команды ИТ проекта с точки зрения подбора сотрудников и проверки на не превышение их загрузки, то в качестве программного продукта, поддерживающего данный процесс может выступать Microsoft Project. Данный программный продукт позволяет для каждой задачи проекта назначать ресурс (возможно назначение как конкретного ресурса, так и обезличенной роли) и в дальнейшем проверить, что загрузка каждого участника проекта не превышает 100%. Пример интерфейса Microsoft Project приведен на рисунке 1.9. Рисунок 1.9 – Интерфейс Microsoft Project в части планирования человеческих ресурсов на проект 23

1.3 Выводы по главе 1) Проведено исследование отечественных и зарубежных стандартов в предметной области «Управление проектами», в частности были рассмотрены ГОСТ 54869-2011 «Проектный менеджмент, требования к управлению проектами», Project Management Body of Knowledge (PMBoK) – методология по управлению проектами, ISO 21500:2012 «Руководство по управлению проектами». 2) Анализ отмеченных стандартов показал, что в процессе «Управление проектом» существует этап формирования команды проекта, при этом ни один из исследованных стандартов не дает полного руководства и методики по подбору участников команды ИТ проекта, а представлены только общие рекомендации. 3) Осуществлен поиск инструментальных средств поддержки процесса подбора кандидатов в проектную команду: SAP E-Recruiting, разработка ООО «Сайнер» - Recruiting, Microsoft Project. 4) Анализ перечисленных инструментальных средств показал, что вышеуказанные программные продукты позволяют решать задачу подбора команды ИТ проекта лишь частично и только на отдельных этапах всего процесса подбора персонала в проектную команду. 5) Отсутствует программный продукт, который бы полностью поддерживал процесс подбора команды ИТ проекта на всех его этапах. 6) Правильный подбор участников ИТ команды является одним из ключевых моментов в успешной реализации ИТ проекта. Проведенные исследования и анализ предметной области выявил необходимость внедрения в общую ИТ инфраструктуру ИТ компаний информационной системы, поддерживающей все этапы процесса подбора участников команды ИТ проекта. 7) Для построения информационной системы поддержки процесса подбора участников команды требуется разработка процедуры, охватывающей все этапы процесса подбора участников команды ИТ проекта. 24

2 РАЗРАБОТКА ПРОЦЕДУРЫ ПОДБОРА КОМАНДЫ ИТ ПРОЕКТА 2.1 Разработка функциональной схемы процесса подбора команды ИТ проекта Опишем процесс подбора участников, команды ИТ проекта на основании известных принципов теории автоматического управления. В частности, для процесса управления командой ИТ проекта возможно построить функциональную схему процесса, которую можно рассматривать в качестве основы для дальнейшей разработки и реализации ИС подбора команды ИТ проекта. С точки зрения принципов построения и структуры систем автоматического управления команда ИТ проекта представляет собой объект управления. В рамках задачи подбора команды ИТ проекта осуществляется управление составом команды ИТ проекта [70]. В соответствии с основами теории автоматического управления АСУ должна иметь структурные элементы в контуре управления, способные осуществлять управление объектом управления. Этими элементами являются управляющее устройство, исполнительный механизм и элемент оценки в контуре обратной связи, возможно также наличие корректирующего элемента, который корректирует управляющее воздействие, основываясь не на информации полученной от объекта управления, а на информации о внешнем воздействии на объект управления. Используя все перечисленные выше элементы, можно сказать, что система управления построена по комбинированному принципу, то есть совмещает в себе принципы систем как замкнутого, так и разомкнутого типа [70]. В общем виде процесс управления составом команды ИТ проекта можно описать следующим образом: на вход системы подается задача «Сформировать команду для конкретного ИТ проекта», что бы подобранный состав в полной мере мог 25

выполнить задачи данного проекта, то есть необходимо полностью сформировать команду проекта; на основании информации о структуре проекта и о проектах, выполненных ранее, а также информации о типовых требованиях к ролям проекта управляющее устройство формирует перечень ролей, необходимых и достаточных для выполнения данного ИТ проекта; перечень ролей содержит так же описание каждой роли, включая требования к компетенциям, которыми должны обладать будущие участники проекта; после того как был сформирован список необходимых ролей и требования к ним, производится подбор участников; подбор участников является двухуровневым процессом – на первом уровне производится выбор наиболее подходящих кандидатов из общего множества сотрудников компании, а также из внешних кандидатов, на втором уровне из группы подобранных претендентов производится выбор наиболее подходящих кандидатов; в процессе жизненного цикла объекта управления - команды ИТ проекта - возможны внешние воздействия на объект, за которыми производит наблюдение корректирующий элемент и на основании полученной информации подает сигнал управляющему устройству о корректировке управляющего воздействия; под внешними воздействиями в рамках данной задачи можно понимать такие внешние факторы как изменение объема проекта или изменение состава команды в связи с выбытием участников из команды; также во время жизненного цикла объекта управления производится оценка его состояния по каналу обратной связи – действительно ли хватает выделенных ресурсов для выполнения задач ИТ проекта, данную оценку производит элемент оценки [70]. Таким образом, АСУ настраивает объект управления на заданные параметры, используя канал обратной связи и анализируя внешние воздействия. Под настройкой объекта управления в рамках данной задачи понимается изменение состава команды ИТ проекта [70]. 26

На рисунке 2.1 представлена функциональная схема процесса управления командой ИТ проекта. Корректирующий элемент IВ Эксперт в предметной области Исполнительный механизм Управляющее устройство Объект управления IВК Блок определения потребности в ресурсах IЦ IОС IСП IУ IТР IВП База успешно выполненных проектов Структура проекта Блок подбора участников команды ИТ проекта IУК IОУ Модуль выбора наиболее подходящего кандидата на каждую роль База данных кандидатов IГК База типовых ролей Команда ИТ проекта Модуль формирования группы кандидатов для каждой роли IК Элемент оценки Руководитель проекта Рисунок 2.1 - Функциональная схема процесса подбора участников команды ИТ проекта Как уже указывалось ранее, объектом управления является команда ИТ проекта в части состава данной команды. Устройство управления, расположенное в прямом канале передачи управляющего воздействия, представляет собой блок определения потребности в ресурсах. Входными данными для данного блока являются: IЦ – информация о цели управления командой ИТ проекта, IВК – информация о возмущающем воздействии на объект управления, передаваемый экспертом в предметной области и являющимся корректирующим элементом в рамках данного процесса, IОС информация о состоянии объекта управления, получаемая по каналу обратной связи через руководителя проекта, в рамках данного процесса элемента оценки. 27

На основании получаемой входной информации управляющее устройство формирует выходной управляющий поток данных IУ. Данный поток данных включает в себя информацию о перечне ролей, необходимых для выполнения проекта, при этом каждая роль имеет набор требований. Формирование выходного потока данных производится на основании данных, которые используются в блоке определения потребностей: информация о структуре проекта, информация о подобных проектах, успешно выполненных ранее, базе типовых ролей с перечнем стандартных требований [70]. Управляющий поток данных IУ является входным для исполнительного механизма. Задача исполнительного механизма – воздействие на объект управления на основании сигнала, поданного управляющим устройством. Исполнительный механизм представляет собой блок подбора участников команды ИТ проекта: подбирая конкретного человека на определенную роль проекта, изменяется состояние объекта управления. Блок подбора участников команды ИТ проекта состоит из двух модулей, работающих последовательно. Первым модулем является модуль формирования группы кандидатов для каждой определенной роли из множества доступных кандидатов как внутренних (состоящих в штате компании), так и внешних (не состоящих в штате компании и привлекаемых под задачи проекта). Множество внешних и внутренних кандидатов находится в базе данных кандидатов, с которой взаимодействует модуль формирования группы кандидатов для каждой роли. Данный модуль на выходе формирует информационный поток IГК, включающий в себя информацию о подобранных группах кандидатов для каждой роли. Информационный поток IГК является входным для второго модуля – модуля подбора наиболее подходящего кандидата на каждую роль. В данном модуле производится выборка наиболее подходящего кандидата на роль проекта из группы ранее определенных кандидатов. Выборка производится на основании более расширенных требований, специфичных для предметной области. Информационный поток формируемый на выходе данного модуля является также выходным сигналом исполнительного механизма - IУК и 28

представляет из себя перечень конкретных людей, которые должны быть включены в команду ИТ проекта [70]. В процессе функционирования объекта управления на объект воздействуют внешние факторы IВ, в результате которых происходит изменение состояния объекта или же изменение требований к состоянию объекта. Примером изменения состояния объекта может служить исключение участников проекта из состава проекта по каким-либо причинам (переключение сотрудника на другой проект, увольнение, отпуск, больничный). Примером изменения требований к состоянию объекта может служить изменение объема проекта, в связи с чем количество задач увеличивается и требуется большее число участников проекта. Контроль за возмущающим воздействием осуществляется по разомкнутому принципу, иначе называемому управлением по возмущению. На основании данного принципа оценка состояния объекта управления после возмущающего воздействия не производится, а анализируется само возмущающее воздействие, и данные этого анализа передаются в управляющее устройство. В разрабатываемой функциональной схеме оценка возмущающего воздействия выполняется корректирующим элементом – экспертом в предметной области. Корректирующий элемент преобразует входное возмущающее воздействие IВ в выходное IВК – информация о возмущающем воздействии на объект управления, которое в свою очередь является входным для управляющего устройства [70]. Для реализации замкнутого принципа управления в систему введена обратная связь, которая анализирует состояние объекта управления IОУ и преобразовывая его в нужный формат передает как сигнал обратной связи IОС на вход управляющего устройства [70]. Реализация выделенных основных функциональных блоков позволит разработать методику подбора команды ИТ проекта и автоматизировать процесс подбора участников команды ИТ проекта. Данная функциональная схема может быть использована как основа для построения информационной системы подбора команды ИТ проекта [70]. 29

2.2 Разработка и описание процедуры подбора команды ИТ проекта Процедура – это упорядоченная совокупность взаимосвязанных определенными отношениями действий, направленных на решение задачи. В рамках данной работы необходимо разработать процедуру, направленную на решение задачи «Подбор команды ИТ проекта». Разработанная процедура описана средствами IDEF0. Методология IDEF0 основана на подходе, разработанном Дугласом Т. Россом в начале 70-ых годов и получившем название SATD (Structured Analysis & Design Technique – метод структурного анализа и проектирования) [46]. Основу подхода и, как следствие, методологии IDEF0 составляет графический язык описания (моделирования) систем, обладающий следующими свойствами: графический язык – полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания; язык обеспечивает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта, то есть служит средством «информационного общения» большого числа специалистов и рабочих групп, занятых в одном проекте, в процессе обсуждения, критики, утверждения результатов; язык прошел многолетнюю проверку и продемонстрировал работоспособность в проектах выполнявшихся как государственными, так и частными компаниями; язык легок и прост в изучении и освоении; язык может генерироваться рядом инструментальных средств машинной графики [46]. 30

Перечисленные свойства языка определили выбор методологии IDEF0 в данной работе. На рисунке 2.2 представлена контекстная диаграмма верхнего уровня А -0 «Осуществить подбор участников команды ИТ проекта». Данная диаграмма определяет область моделирования и ее границу. Входящие и исходящие стрелки отражают связь объекта моделирования с внешней средой. В рамках работы объектом моделирования является процесс подбора участников команды ИТ проекта. Разработка модели процесса осуществляется с точки зрения системного аналитика предметной области. Данная модель разрабатывается для достижения следующей цели: разработка процедуры подбора участников команды ИТ проекта. Положение о проектной деятельности Потребность в команде ИТ проекта Локальные нормативные акты Осуществить подбор участников команды ИТ проекта Перечень участников команды ИТ проекта с ролями и полномочиями 0 A0 Руководитель проекта Руководитель структурного Рекрутер подразделения ЦЕЛЬ: Разработка процедуры подбора участников команды ИТ проекта ТОЧКА ЗРЕНИЯ: системный аналитик предметной области УЗЕЛ: A-0 ЗАГОЛОВОК: Осуществить подбор участников команды ИТ проекта НОМЕР: 1 Рисунок 2.2 – Контекстная диаграмма верхнего уровня процесса подбора команды ИТ проекта Входными данными процесса подбора участников команды ИТ проекта является потребность в команде. Выходными данными процесса является перечень участников команды с ролями и полномочиями. Процесс подбора 31

участников команды ИТ проекта осуществляется с помощью руководителя проекта, руководителя структурного подразделения и рекрутера. Подбор участников команды регламентируется положением о проектной деятельности компании и локальными нормативными актами, которые относятся к вопросам управления персоналом на предприятии и подбора внешних сотрудников на проекты. Данные нормативные документы являются управлением – условиями и необходимыми функциями, что бы произвести правильный выход. Дочерней диаграммой для контекстной диаграммы верхнего уровня А-0 является диаграмма А0 «Осуществить подбор участников команды ИТ проекта», приведенная на рисунке 2.3, которая представляет собой детализацию моделируемого процесса на основные составляющие. Процесс подбора участников команды ИТ проекта включает в себя два основных подпроцесса. На первом этапе производится определение потребности в ресурсах. Входной информацией для данного подпроцесса является информация о потребности в команде ИТ проекта. На выходе данного подпроцесса формируется информация о перечне ролей, необходимых для данного ИТ проекта. Потребность в ресурсах определяет руководитель проекта, руководствуясь при этом положением о проектной деятельности. Информация о необходимых ролях для выполнения ИТ проекта является входной для второго подпроцесса. На втором этапе производится подбор участников команды ИТ проекта среди внутренних и внешних кандидатов. Выход данного подпроцеса является также выходом всего процесса подбора участников команды ИТ проекта – перечень участников команды ИТ проекта с ролями и полномочиями. Исполнителями данного процесса являются: руководитель проекта, руководитель структурного подразделения, рекрутер. Управляющим воздействием, определяющим условия для правильного выхода, являются локальные нормативные акты, которые относятся к вопросам управления персоналом на предприятии и подбора внешних сотрудников на проекты. Процесс подбора участников команды ИТ проекта будет иметь более одной итерации, так как во время жизненного цикла 32

ИТ проекта состав команды может меняться в связи с различными внешними условиями. Положение о проектной деятельности Потребность в команде ИТ проекта Определить потребность в ресурсах Перечень необходимых ролей 1 Локальные нормативные акты A1 Руководитель проекта Осуществить подбор участников среди внутренних и внешних кандидатов Перечень участников команды ИТ проекта с ролями и полномочиями 2 A2 Руководитель проекта УЗЕЛ: A0 ЗАГОЛОВОК: Руководитель структурного подразделения Рекрутер Осуществить подбор участников команды ИТ проекта НОМЕР: 2 Рисунок 2.3 – Диаграмма А0 «Осуществить подбор участников команды ИТ проекта» Рассмотрим более подробно подпроцесс определения потребности в ресурсах. Данный подпроцесс детализирован на диаграмме А1 «Определить потребность в ресурсах», представленной на рисунке 2.4. Процесс определения потребности в ресурсах состоит из четырех этапов. На первом этапе, которому соответствует блок 11 на диаграмме А1, производится детализация ИТ проекта на задачи. На входе данного процесса информация о том, что необходимо подобрать команду ИТ проекта (потребность в команде ИТ проекта), а так же информация о самом проекте, для которого необходимо выполнить подбор команды. Информация об ИТ проекте является «туннельной» в терминах нотации IDEF0, то есть данная информация не фигурирует в общем процессе, а необходима только в масштабе данного блока. На выходе данного процесса 33

информация о детализированном проекте – проекте, разбитом на задачи. Операции данного процесса выполняются на основании положения о проектной деятельности организации. Данный процесс выполняют руководитель проекта и эксперт в предметной области (эксперт в области разрабатываемого решения). Исполнитель процесса – эксперт в области разрабатываемого решения является так же туннельным. Положение о проектной деятельности Детализированный проект Положение о проектной деятельности Потребность в команде ИТ проекта Построить матрицу совместимости выполняемых исполнителем задач Матрица совместимости выполняемых исполнителем задач Перечень необходимых для выполнения ИТ проекта ролей 12 Проверить на непротиворечивость построенную RACI матрицу А12 Разбить проект на задачи ( ) 11 ( ) Эксперт в области разрабатываемого решения 14 Положение о проектной деятельности A14 Результаты проверки модифицированной RACI матрицы ( ) ИТ проект Руководитель Эксперт в области разрабатываемого проекта решения Руководитель проекта Построить модифицированую RACI матрицу Модифицированная RACI матрица 13 A13 Руководитель проекта УЗЕЛ: A1 ЗАГОЛОВОК: Определить потребность в ресурсах НОМЕР: 3 Рисунок 2.4 – Диаграмма А1 «Определить потребность в ресурсах» Детализированный по задачам проект поступает на вход второго и третьего этапов. Вторым этапом процесса определения потребности в ресурсах является построение матрицы совместимости выполняемых исполнителем задач – блок 12 диаграммы А1 «Определить потребность в ресурсах». Входом данного процесса является детализированный на задачи ИТ проект, выходом матрица совместимости выполняемых исполнителем задач. Выполняет данный процесс эксперт в области разрабатываемого решения, опираясь на положение о проектной деятельности предприятия. Третьим этапом является построение 34

модифицированной RACI матрицы – блок 13 диаграммы А1 «Определить потребность в руководитель ресурсах». проекта. Исполнителем Выходом данного процесса процесса является является сформированная модифицированная RACI матрица. На вход второго этапа так же подается информация обратной связи четвертого блока о результатах проверки построенной модифицированной RACI матрицы на непротиворечивость. Построение модифицированной RACI матрицы основывается на положении о проектной деятельности организации. Четвертым этапом процесса определения потребности в ресурсах является проверка построенной матрицы на непротиворечивость – блок 14 диаграммы А1 «Определить потребность в ресурсах». Входом данного процесса является построенная модифицированная и RACI матрица совместимости выполняемых исполнителем задач, выходами – перечень необходимых для выполнения ИТ проекта ролей и результаты проверки модифицированной RACI матрицы. Выход с результатами проверки модифицированной RACI матрицы так же является обратной связью для процесса построения модифицированной RACI матрицы. Рассмотрим совместимости более подробно выполняемых процесс исполнителем построения задач. матрицы Данный процесс представлен на рисунке 2.5. Процесс состоит из двух шагов. На первом шаге (соответствует блоку 121 диаграммы А12) по вертикали и горизонтали экспертом в области разрабатываемого решения перечисляются основные задачи проекта – детализированный проект является входной информацией для процесса. Выходом данного процесса является предзаполненная матрица совместимости выполняемых (соответствует блоку разрабатываемого 122 решения исполнителем диаграммы задач. А12) предзаполненная На втором экспертом матрица в шаге области кодируется в соответствии со следующими значениями: E (Error – ошибка) - совмещение исполнителем задач запрещено, P (Possible - возможно) - совмещение 35

исполнителем задач возможно, W (Warning - предупреждение) - совмещение задач исполнителем возможно, но лучше его избежать. Предзаполненная матрица совместимости выполняемых исполнителем задач Детализированный проект Перечислить основные работы проекта по вертикали и горизонтали Положение о проектной деятельности Закодировать матрицу совместимости выполняемых исполнителем задач 121 122 Эксперт в области разрабатываемого решения Руководитель проекта УЗЕЛ: A12 ЗАГОЛОВОК: Матрица совместимости выполняемых исполнителем задач Построить матрицу совместимости выполняемых исполнителем задач НОМЕР: 4 Рисунок 2.5 – Диаграмма А12 «Построить матрицу совместимости выполняемых исполнителем задач» Пример матрицы совместимости выполняемых исполнителем задач приведен в таблице 2.1. Таблица 2.1 – Пример заполнения матрицы совместимости выполняемых исполнителем задач. Задача 1 Задача 2 Задача 3 P W Задача 1 Задача 2 P Задача 3 W E E 36

Детализируем процесс построения модифицированной RACI матрицы. Данный процесс представлен на рисунке 2.6. Процесс построения модифицированной RACI матрицы состоит из четырех этапов. Каждый из этапов регламентируется положением о проектной деятельности организации. Весь процесс в целом, так же как и отдельные его этапы выполняет руководитель проекта. Детализированный Положение о проектной проект деятельности Положение о проектной деятельности Предзаполненная RACI матрица Закодированная RACI матрица Перечень необходимых для выполнения ролей Перечислить основные работы проекта по вертикали RACI матрицы Закодировать RACI матрицу 131 133 Руководитель проекта Руководитель проекта Положение о проектной деятельности Положение о проектной деятельности Распределить роли между задачами в процентном соотношении 134 Перечислить основные роли проекта по горизонтали RACI матрицы Руководитель проекта 132 Результаты проверки модифицированной RACI матрицы УЗЕЛ: A13 Руководитель проекта ЗАГОЛОВОК: Построить модифицированную RACI матрицу НОМЕР: 5 Рисунок 2.6 – Диаграмма А12 «Построить модифицированную RACI матрицу» Для построения модифицированной RACI матрицы необходимо: основные по вертикали (соответствует строкам) в матрице перечислить работы проекта – блок 131 диаграммы А13 «Построить модифицированную RACI матрицу» на основании информации, поступившей в данный блок: информации о детализированном проекте и информации о результатах проверки модифицированной RACI матрицы предыдущей итерации данного процесса (в случае первой итерации информация о проверке будет отсутствовать); 37

роли по горизонтали (соответствует столбцам) в матрице перечислить команды проекта модифицированную RACI – блок 132 матрицу»; диаграммы данный А13 процесс «Построить производится параллельно предыдущему и использует ту же входную информацию; на выходе обоих блоков будет предзаполненная RACI матрица; «Построить закодировать матрицу ответственности – блок 133 диаграммы А13 модифицированную RACI матрицу»; процесс кодирования матрицы заключается в указании кодов участия каждой роли для каждой задачи, то есть на пересечении столбца, соответствующего роли и строки, соответствующей задаче проекта указывается обозначение в следующей кодировке: R – исполнитель (Responsible), A – Утверждающий (Accountable), C – Согласующий (Consulted), I – Наблюдатель (Informed); выходом данного процесса является закодированная RACI матрица; в полученной закодированной RACI матрице распределить роли между задачами в процентном соотношении – блок 134 диаграммы А13; выходом данного блока является перечень необходимых для выполнения проекта ролей, данная информация является так же выходом всего блока «Построить модифицированную RACI матрицу». Пример модифицированной RACI матрицы приведен в таблице 2.2. Роль 3 Роль4 Наименование задачи 1 Роль 2 Роль Роль 1 Таблица 2.2 – Пример модифицированной RACI матрицы. 2 3 4 5 Задача 1 R 40% I 100% Задача 2 R 30% C 100% A 100% Задача 3 C 30% R 100% A 100% I 100% 70% 100% 100% 100% Промежуточный итог R – исполнитель A – утверждающий 38

Продолжение таблицы 2.2 1 2 C – согласующий 3 4 30% 100% I – наблюдатель Общий итог 5 100% 100% 100% 100% 100% 100% Детализация узла 13 «Построить модифицированную RACI матрицу» завершена, рассмотрим более подробно узел 14 «Проверить на непротиворечивость построенную матрицу». IDEF0 диаграмма процесса проверки модифицированной RACI матрицы приведена на рисунке 2.7. Заполненная матрица совместимости выполняемых исполнителем задач Матрица совместимости выполняемых исполнителем задач Модифицированная RACI матрица Заполнить матрицу совместимости выполняемых исполнителем задач для каждой роли Проверить корректность матрицы совместимости задач исполнителем для каждой роли 141 Руководитель проекта 142 Руководитель проекта Перечень необходимых ролей Результаты проверки модифицированной RACI матрицы Проверить на непревышение загрузки каждой роли 100% 143 Руководитель проекта УЗЕЛ: A14 ЗАГОЛОВОК: Проверить на непротиворечивость построенную RACI матрицу НОМЕР: 6 Рисунок 2.7 – Диаграмма А13 «Проверить на непротиворечивость построенную RACI матрицу» Процесс проверки составленной модифицированной RACI включает два этапа, которые могут выполняться как параллельно, так и последовательно. 39

На первом этапе, который включает в себя блоки 141 и 142 диаграммы А14 «Проверить на непротиворечивость построенную RACI матрицу» производится проверка на возможность совмещения различных задач одной ролью и выполняется руководителем проекта. Первым шагом (блок 141) производится заполнение матрицы совмещения выполняемых исполнителем задач для каждой роли из модифицированной RACI матрицы, то есть если роль назначена исполнителем более чем на одну задачу проекта, то в ячейках матрицы совмещения ролей указывается код исполнителя для всех комбинаций назначенных задач. На вход данного процесса подаются модифицированная RACI матрица и матрица совмещения выполняемых исполнителем задач. На выходе формируется заполненная матрица совместимости выполняемых исполнителем задач. Вторым шагом производится проверка заполненной матрицы – не должны быть заполнены ячейки с кодом E, и не желательно, что бы были заполнены ячейки с кодом W. В случае если ячейки с кодом W заполнены решение принимается руководителем проекта. На выходе формируется два информационных сигнала – перечень необходимых ролей и результаты проверки матрицы на непротиворечивость. Для пояснения данного процесса возможно привести пример. При составлении модифицированной RACI матрицы в перечень задач проекта входят задачи: «разработка субприложения 1» и «тестирование субприлодения 1». Для данных задач указано свойство совместимости – E совмещение исполнителем задач запрещено. При назначении исполнителя данным задачам для обоих задач был назначен исполнитель (R – исполнитель (Responsible)) консультант №1. При проверке в данном блоке должна быть ошибка противоречивости, так как эти две задачи не могут быть выполнены одной ролью. Второй этап проверки, отраженный в блоке – блок 143 диаграммы А14 «Проверить на непротиворечивость построенную RACI матрицу» соответствует проверке на не превышение загрузки каждой роли – то есть для каждой роли суммарный процент занятости на проектах задачи не должен быть более 100%. 40

Входными данными также является модифицированная RACI матрица, а выходными – перечень необходимых ролей и результаты проверки матрицы на непротиворечивость. Узел А14 является последним в детализации узла А1 «Определить потребность в ресурсах», поэтому переходим к узлу А2 «Осуществить подбор участников среди внутренних и внешних кандидатов» (данный узел отражен на рисунке 2.3). Локальные нормативные акты Перечень ролей с компетенциями для каждой роли Перечень необходимых для выполнения ролей Определить необходимые компетенции для каждой роли Сформировать группу наиболее подходящих кандидатов из общего списка кандидатов (внешние и внутренние) 21 A21 Руководитель проекта Руководитель структурного подразделения Группа кандидатов Перечень участников команды ИТ проекта с ролями и полномочиями 22 A22 Руководитель Рекрутер структурного подразделения Выбрать кандидата на каждую роль из предлагаемой группы кандидатов 23 A23 Руководитель проекта УЗЕЛ: A2 ЗАГОЛОВОК: Осуществить подбор персонала среди внутренних и внешних кандидатов НОМЕР: 7 Рисунок 2.8 – Диаграмма А2 «Осуществить подбор персонала среди внутренних и внешних кандидатов» Детализация узла А2 «Осуществить подбор участников среди внутренних и внешних кандидатов» приведена на рисунке 2.8. Данный процесс состоит из трех этапов. Первым этапом является определение необходимых компетенций для каждой роли – блок 21 диаграммы А2. Исполнителями данного процесса являются руководитель проекта и руководитель структурного подразделения (структурного подразделения из 41

сотрудников которого необходимо произвести выборку кандидатов). На входе данного процесса перечень необходимых ролей, составленный на основании проверенной на непротиворечивость модифицированной RACI матрицы. Выходом данного процесса является перечень ролей со списком необходимых компетенций для каждой роли. Управлением данного процесса являются локальные нормативные акты организации в части управления персоналом. Вторым этапом процесса подбора персонала для ИТ проекта является выборка группы наиболее подходящих кандидатов из общего списка кандидатов – блок 22 диаграммы А2. Общий список кандидатов состоит из множества внутренних сотрудников и внешних кандидатов. Исполнителями данного процесса являются руководитель структурного подразделения и рекрутер. Руководитель структурного подразделения производит выборку наиболее подходящих кандидатов из числа сотрудников компании, а рекрутер из числа внешних кандидатов. Входной информацией для данного процесса является перечень ролей с компетенциями. На выходе формируется группа кандидатов для каждой роли. На завершающем этапе команды ИТ проекта производится выборка конкретного кандидата для конкретной роли – блок 23 диаграммы А2. Данную выборку выполняет руководитель проекта. На вход данного процесса подается информация о перечне ролей с требованиями для каждой роли, определенная в процессе 21 «Определить необходимые компетенции для каждой роли» и группа кандидатов для каждой роли, определенная в процессе 22. Выход данного подпроцесса является так же выходом всего процесса подбора участников команды ИТ проекта – перечень участников команды ИТ проекта. Далее перейдем к рассмотрению процесса 21 «Определить необходимые компетенции для каждой роли» более подробно. Диаграмма данного процесса приведена на рисунке 2.9. 42

Существующий каталог компетенции Актуализированный каталог компетенций ( ) Актуализировать каталог компетенций 211 Локальные нормативные акты Перечень необходимых для выполнения ролей ( ) Руководитель структурного подразделения Технический специалист Присвоить компетенции ролям прорабатываемого проекта 212 Руководитель проекта УЗЕЛ: A21 ЗАГОЛОВОК: Перечень ролей с компетенциями для каждой роли Руководитель структурного подразделения Определить необходимые компетенции для каждой роли НОМЕР: 8 Рисунок 2.9 – Диаграмма А21 «Определить необходимые компетенции для каждой роли» Процесс определения компетенций для каждой роли состоит из двух этапов. На первой этапе производится актуализация существующего каталога компетенций – блок 211 диаграммы А21 «Определить необходимые компетенции для каждой роли». Входными данными для данного этапа являются существующий каталог компетенций, а также перечень ролей, необходимых для выполнения данного ИТ проекта. Информация о существующем каталоге компетенций является «туннельным» входом, то есть данная информация не фигурирует в общем процессе, а необходима только в масштабе данного блока. Исполнителями данного процесса являются руководитель проекта и технический специалист. Исполнителя «технический специалист» так же можно отнести к «туннельным» – он необходим только в рамках данного блока. Выходом процесса является актуализированный каталог 43

компетенций, с которым возможно работать в рамках реализуемого ИТ проекта. На втором этапе производится присвоение компетенций из актуализированного каталога каждой роли – блок 212 диаграммы А21 «Определить необходимые компетенции для каждой роли». В рамках данного процесса производится формирование требований к кандидатам при дальнейшем подборе. Входной информацией для данного процесса является актуализированный на предыдущем шаге каталог компетенций, а так же перечень необходимых ролей. Исполнителями данного процесса являются руководитель проекта и руководитель структурного подразделения. Данный процесс опирается на локальные нормативные акты организации в части управления персоналом. Результатом данного процесса является перечень ролей с компетенциями для каждой роли. Далее рассмотрим подпроцесс 22 «Сформировать группу наиболее подходящих кандидатов из общего списка кандидатов». Данный процесс представлен на рисунке 2.10, он состоит из четырех блоков и является итеративным, то есть возможно несколько итераций до получения окончательного результата. Данный процесс проводится для каждой роли. Первым шагом в процессе формирования группы наиболее подходящих кандидатов является задание диапазона отклонения компетенции кандидата от требования к роли – блок 221 диаграммы А22. Для каждой роли определен набор необходимых компетенций, то есть требований к роли. Каждая компетенция (требование к роли) включена не просто абсолютным требованием, а имеет шкалу от 1 до 5, где 1 минимальный уровень компетенции, 5 максимальный уровень компетенции. Каждый сотрудник организации так же имеет набор компетенций со шкалой. При проведении выборки возможно задать как конкретный уровень определенной компетенции, например, владение Microsoft Project, на уровне 3 (который соответствует требованию), так и диапазон, например, ± 1 значений (владение Microsoft Project, на уровне 2-4). Входными данными для данного процесса являются 44

информация о возможных условиях допустимости, а так же информация обратной связи о результатах проверки осуществленной выборки предыдущей итерации. Информация о результатах проверки предыдущей выборки необходима для принятия решения о корректировке диапазона в ту или другую сторону. Исполнителем данного процесса является руководитель проекта. На выходе формируются заданные условия допустимости выборки. Перечень ролей с компетенциями для каждой роли Заданные условия допустимости Возможные условия допустимости Осуществить выборку из базы данных внутренних кандидатов на основании заданных условий Результаты выборки Группа кандидатов 223 ( ) Задать диапазон отклонения компетенции кандидата от требования к роли Проверить результаты выборки Руководитель проекта 224 221 Руководитель проекта Задать максимально допустимое количество несоответствий компетенций и требований при выборке кандидата Осуществить выборку внешних кандидатов на основании заданных условий 225 Руководитель проекта Результаты выборки Рекрутер 222 Результаты проверки выборки Руководитель проекта УЗЕЛ: A22 ЗАГОЛОВОК: Сформировать группу наиболее подходящих кандидатов из общего списка кандидатов НОМЕР: 9 Рисунок 2.10 – Диаграмма А22 «Сформировать группу наиболее подходящих кандидатов» Вторым шагом, который выполняется параллельно с предыдущим является задание максимально допустимого количества несоответствий компетенций и требований к кандидатам – блок 222 диаграммы А22 «Сформировать группу наиболее подходящих кандидатов». Например, в случае задания максимально допустимого количества несоответствий компетенций и требований к кандидатам равному 1 при совпадении требований по компетенциям 4 из 5 кандидат попадает в группу для второго этапа выборки. 45

Входными данными для данного процесса, так же как и для шага 221 являются информация о возможных условиях допустимости, а так же информация обратной связи о результатах проверки осуществленной выборки предыдущей итерации. Информация о результатах проверки предыдущей выборки необходима для принятия решения о корректировке максимально допустимого количества несоответствий в ту или другую сторону. Исполнителем данного процесса является руководитель проекта. На выходе формируются заданные условия допустимости для выборки. После задания условий допустимости выполняется процесс, выборки кандидатов из базы данных внутренних кандидатов, то есть сотрудников организации – блок 223 диаграммы А22. Данный процесс осуществляется для каждой роли проекта на основании данных по обрабатываемой роли, то есть на основании требований к роли, а так же заданных условий допустимости, сформированных в шагах, описанных выше. Выполняет данный процесс руководитель проекта. На выходе формируются результаты выборки из базы данных. Выборка производится на основании простого сравнения требований к роли и компетенций сотрудников. Все подходящие сотрудники попадают в результат выборки. После того как выборка произведена производится ее проверка – блок 224 диаграммы А22. Проверка производится на ненулевой результат выборки, то есть входной информацией для данного процесса является результат выборки из базы данных внутренних кандидатов, исполнителем процесса является руководитель проекта. На выходе процесса проверки формируется два информационных сигнала – результат проверки и группа кандидатов. Группа кандидатов формируется только в случае ненулевой выборки. Результаты проверки выборки (сигнал обратной связи) передается на блоки 221 и 222 для возможности изменения диапазона условий выборки в большую или меньшую сторону, если требуется новая итерация, а так же в блок выборки внешних кандидатов. Блок выборки внешних кандидатов задействован только в том случае если результаты выборки текущей итерации нулевые. Блок выборки внешних кандидатов – блок 225 диаграммы А22 в качестве входной 46

информации использует описанную выше обратную связь, а также перечень ролей ИТ проекта с необходимыми для данных ролей требованиями. Исполнителем данного процесса является рекрутер. Результаты выборки так же передаются в блок 224 «Проверить результаты выборки» на выходе которого формируется окончательная группа кандидатов для каждой роли. После формирования группы кандидатов проводится окончательная выборка кандидата для каждой роли. Данному процессу соответствует диаграмма А23 «Выбрать кандидата на каждую роль из предлагаемой группы кандидатов», изображенная на рисунке 2.11. Данный процесс проводится для каждой роли, определенной на этапе А1 «Определить потребность в ресурсах». На первом этапе процесса А23 «Выбрать кандидата на каждую роль из предлагаемой группы кандидатов» для каждой компетенции (требованию к роли) устанавливается вес – блок 231 диаграммы А23. Входными данными для данного процесса является перечень требуемых ролей с компетенциями, выходными – перечень ролей с компетенциями и присвоенными им весами для каждой роли, исполнителем является руководитель проекта. Установка веса производится на основании классической методологии метода парных сравнений: строится квадратная матрица где по вертикали и горизонтали указываются компетенции для обрабатываемой роли; производится сравнение каждой компетенции с каждой и результат и цифровом виде заносится в соответствующую ячейку, при сравнении компетенции саму с собой на пересечении указывается 1, при сравнении компетенции 1 с компетенцией 2 на их пересечении устанавливается значение от 1 до 9, при обратном пересечении, то есть компетенции 2 с компетенцией 1 указывается обратное значение; на основании установленных значений сравнения производится вычисление веса каждой компетенции для обрабатываемой роли путем суммирования элементов каждой строки и делением полученного значения на сумму всех компетенций. 47

Перечень ролей с компетенциями для каждой роли Установка веса каждой компетенции методом парных сравнений для каждой роли Компетенции с весами для каждой роли 231 Руководитель проекта Группа кандидатов Выбор из группы кандидатов наиболее подходящего кандидата для каждой роли Перечень участников команды ИТ проекта с ролями и полномочиями 232 Руководитель проекта УЗЕЛ: A23 ЗАГОЛОВОК: Выбрать кандидата на каждую роль из предлагаемой группы кандидатов НОМЕР: 10 Рисунок 2.11 – Диаграмма А23 «Выбрать кандидата на каждую роль из предлагаемой группы кандидатов» После установления весов производится окончательная подборка участников команды ИТ проекта – блок 232 диаграммы А23 «Выбрать кандидата на каждую роль из предлагаемой группы кандидатов». Входными данными для данного процесса является перечень требуемых ролей с компетенциями и весами, выходными – перечень участников команды ИТ проекта, исполнителем является руководитель проекта. Процесс выборки осуществляется следующим образом: для каждого кандидата из группы производится умножение значения компетенции по шкале на вес данной компетенции; результаты произведения по каждой компетенции складываются, таким образом для каждого кандидата из группы определяется удельный вес; на основании полученных результатов выбирается кандидат с наибольшим удельным весом. 48

Определенный на основании методики, описанной выше кандидат закрепляется за ролью проекта. В целом процесс подбора команды ИТ проекта может быть описан перечнем узлов: 0 Осуществить подбор участников команды ИТ проекта 1 Определить потребность в ресурсах 11 Разбить проект на задачи 12 Построить матрицу совместимости выполняемых исполнителем задач 121 Перечислить основные работы проекта по вертикали и горизонтали 123 Закодировать матрицу совместимости выполняемых исполнителем задач 13 Построить модифицированную RACI матрицу 131 Перечислить основные работы проекта по вертикали RACI матрицы со свойствами совместимости 132 Перечислить основные роли проекта по горизонтали RACI матрицы 133 Закодировать RACI матрицу 134 Распределить роли между задачами в процентном соотношении 14 Проверить на непротиворечивость построенную матрицу 141 Заполнить матрицу совместимости выполняемых исполнителем задач 142 Проверить корректность матрицы совместимости выполняемых исполнителем задач 143 Проверить на не превышение загрузки каждой роли 100% 2 Осуществить подбор участников среди внутренних и внешних кандидатов 21 Определить необходимые компетенции для каждой роли 211 Актуализировать каталог компетенций 49

212 Присвоить компетенции ролям прорабатываемого проекта 22 Сформировать группу наиболее подходящих кандидатов из общего списка кандидатов 221 Задать диапазон отклонения компетенции кандидата от требования к роли 222 Задать максимально допустимое количество несоответствий компетенций и требований при выборке кандидата 223 Осуществить выборку из базы данных внутренних кандидатов на основании заданных условий 224 Проверить результаты выборки 225 Осуществить выборку внешних кандидатов на основании заданных условий 23 Выбрать кандидата на каждую роль из предлагаемой группы кандидатов 231 Установка веса каждой компетенции методом парных сравнений для каждой роли 232 Выбор из группы кандидатов наиболее подходящего кандидата для каждой роли Разработанная модель IDEF0 со всеми уровнями структурной декомпозиции может быть представлена отдельной диаграммой в виде дерева узлов. Дерево узлов процесса подбора команды ИТ проекта представлено на рисунке 2.12. 0 1 11 2 12 121 14 122 141 142 21 143 211 23 212 13 131 132 231 232 22 133 134 221 222 223 224 225 Рисунок 2.12 – Дерево узлов процесса подбора команды ИТ проекта 50

2.3 Разработка концептуальной схемы базы данных для информационной системы подбора команды ИТ проекта Концептуальная схема базы данных для информационной системы подбора участников команды ИТ проекта спроектирована с помощью методологии IDEF1X. IDEF1X является методом для проектирования реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы [66]. Концептуальной схемой называется универсальное представление структуры данных, независимой от конечной реализации базы данных и аппаратной платформы [66]. Для удобства описания концептуальной схемы базы данных условно разобьем ее на три блока: «Проект», «Кандидаты», «Справочники». Каждый блок включает в себя данные, которые логически можно выделить отдельно. Концептуальная схема базы данных приведена в приложении А. Блок «Проект» включается в себя сущности: «Проект»; «Задача проекта»; «Свойство задачи проекта»; «Роль проекта»; «Компетенция роли проекта»; «RACI матрица». Блок «Кандидаты» включает в себя сущности: «Кандидат»; «Внешний кандидат»; «Сотрудник»; «Компетенция сотрудника». Блок «Справочники» включает в себя сущности: «Компетенция»; «Вид значения уровня компетенции»; 51

«Вид реакции»; «Код RACI матрицы». Концептуальный проект базы данных включает следующие отношения: «включает»; «состоит из»; «описывается»; «имеет»; «входит». Опишем каждую сущность и ее взаимосвязь с другими сущностями более подробно. Сущность «Проект» является независимой, так как каждый экземпляр сущности «Проект» может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность «Проект» имеет следующие атрибуты: «Номер проекта», который является первичным ключом, а так же «Название проекта». Экземплярами сущности «Проект» являются реализуемые проектной компанией проекты. Каждый проект состоит из задач, соответственно база данных включает сущность «Задача проекта». Сущность «Задача проекта» является зависимой, так как задача проекта может существовать только в рамках проекта, то есть зависит от отношения к сущности «Проект». Сущность «Задача проекта» включает атрибуты: «Номер проекта», «Номер задачи», «Название задачи». Атрибуты «Номер проекта» и «Номер задачи» являются первичным ключом, при этом «Номер проекта» является внешним ключом. В рамках разработанного процесса подбора участников команды ИТ проекта задачам проекта можно задать свойства совместимости – какие из задач запрещено выполнять одной ролью (например, разработка программы и тестирование программы). Для этих целей разработана сущность «Свойство задачи проекта». В данной сущности определяется какие задачи в рамках проекта не совместимы или совместимы с ограничениями. Данная сущность является зависимой и содержит следующие атрибуты «Номер задачи 1», «Номер задачи 2», «Код реакции». Все атрибуты являются внешними 52

ключами, первичным ключом являются атрибуты «Номер задачи 1», «Номер задачи 2». Так как атрибут «Код реакции» является внешним ключом, то для него определена сущность «Вид реакции». Данная сущность является независимой, и по сути, представляет справочник возможных реакции при пересечении одной роли в разных задачах проекта. Сущность «Вид реакции» содержит атрибуты «Код реакции», являющаяся первичным ключом и «Название реакции». Для выполнения каждого проекта должны быть определены роли проекта, по этому выделена отдельная сущность «Роль проекта». Данная сущность так же является зависимой, так как роль проекта может существовать только в рамках проекта. Сущность «Роль проекта» имеет атрибуты: «Номер проекта», «Идентификатор роли» и «Название роли». Атрибуты «Номер проекта» и «Идентификатор роли» являются первичным ключом, при этом «Номер проекта» является внешним ключом. В рамках определения ролей для проекта для каждой роли необходимо определить компетенции, которыми должна обладать роль, и уровень владения этими компетенциями, для этих целей в базу данных введена сущность «Компетенция роли проекта». Данная сущность является зависимой, так как может существовать только для конкретных ролей и конкретных компетенций. Данная сущность включает следующие атрибуты: «Номер проекта», «Идентификатор роли», «Идентификатор компетенции», «Ключ значения уровня компетенции». Все перечисленный атрибуты являются внешними ключами, атрибуты Номер проекта», «Идентификатор роли» и «Идентификатор компетенции» составляют первичный ключ. Дополнительно определены сущность «Компетенция», которая является справочником компетенций, а так же «Вид значения уровня компетенции», которая является справочником значений уровней владения компетенций. «Компетенция» Обе сущности включает два являются атрибута: независимыми. атрибут Сущность внешнего ключа «Идентификатор компетенции» и атрибут «Название компетенции». Сущность «Вид значения уровня компетенции» так же включает два атрибута: атрибут внешнего ключа «Ключ значения уровня компетенции» и атрибут «Значение 53

уровня компетенции». Для блока «Проект» так же необходимы сущность «RACI матрица» и «Код RACI матрицы». Опишем сущность «RACI матрица». Данная сущность является зависимой, так как существует только в рамках конкретного проекта, содержит следующие атрибуты: «Номер проекта», «Номер задачи», «Идентификатор роли», «Код RACI матрицы», «Процент занятости». Атрибуты «Номер проекта», «Номер задачи», «Идентификатор роли» и «Код RACI матрицы» составляют первичный ключ, а так же являются внешними ключами. Сущность «Код RACI матрицы» является независимой и представляет собой справочник возможных кодов RACI матрицы. Данная сущность включает атрибуты «Код RACI матрицы» и «Значение кода RACI матрицы». Атрибут «Код RACI матрицы» является первичным ключом. В блоке «Кандидаты» можно выделить независимую сущность «Кандидат». Данная сущность имеет первичный ключ «Идентификатор, по которому возможно определить каждого отдельного кандидата, а так же дополнительные атрибуты «Фамилия», «Имя», «Отчество», «Дата рождения». Так как всех кандидатов можно разделить на внешних и внутренних, и для каждой категории кандидатов необходим различный набор данных и различная обработка, то выделены две отдельные сущности «Внешний кандидат» и «Сотрудник», связанные отношениями категоризации с сущностью «Кандидат». Дополнительно выделена сущность «Компетенция сотрудника», описывающая компетенции каждого сотрудника. Данная сущность является зависимой и включает следующие атрибуты: «Идентификатор сотрудника», «Идентификатор компетенции» и «Ключ значения уровня компетенции». Все перечисленные атрибуты являются внешними ключами, атрибуты «Идентификатор сотрудника» и «Идентификатор компетенции» являются первичным ключом описываемой сущности. Далее опишем отношения между сущностями. Между сущностями «Проект» и «Задача проекта» существует отношение «состоит из». Данное отношение является отношением связи. В данном отношении сущность «Проект» является родителем, сущность «Задача проекта» является потомком. 54

Мощность данного отношения – P, то есть «один или более» - «проект состоит из одной или более задач проекта». Так как для задач проекта определены свойства совместимости, то между сущностями «Задача проекта» и «Свойство задачи проекта» существует отношение «описывается». Данное отношение является отношением связи. В данном отношении сущность «Задача проекта» является родителем, сущность «Свойство задачи проекта» является потомком. Мощность данного отношения – P, то есть «один или более» - «задача проекта описывается одним или более свойством задачи проекта». Так как для задач проекта определены свойства совместимости с помощью кода реакции на пересечение задач, то между сущностями «Свойство задачи проекта» и «Вид реакции» существует отношение «включает». Данное отношение является отношением связи. Мощность данного отношения 1 – «Свойство задачи проекта имеет один вид реакции». Между сущностями «Проект» и «Роль проекта» существует отношение «включает». Данное отношение является отношением связи. В данном отношении сущность «Проект» является родителем, сущность «Роль проекта» является потомком. Мощность данного отношения – P, то есть «проект включает одну или более ролей проекта». Так как каждая роль проекта должна быть описана компетенциями (требованиями к данной роли), то между сущностями «Роль проекта» и «Компетенция роли проекта» существует связь «имеет». Данное отношение является отношением связи. В данном отношении сущность «Роль проекта» является родителем, сущность «Компетенция роли проекта» является потомком. Мощность данного отношения – P, то есть «роль проекта имеет одну или более компетенций роли проекта». Между сущностями «Компетенция роли проекта» и «Компетенция» существует связь «включает». Данное отношение является отношением связи. В данном отношении сущность «Компетенция роли проекта» является родителем, сущность «Компетенция» является потомком. Мощность данного отношения – 1, «компетенция роли проекта имеет одну компетенцию». Между сущностями «Компетенция роли проекта» и «Вид значения уровня компетенции» существует связь «включает». Данное отношение является 55

отношением связи. В данном отношении сущность «Компетенция роли проекта» является родителем, сущность «Компетенция» является потомком. Мощность данного отношения – 1, «компетенция роли проекта имеет одну компетенцию». Для построения модифицированной RACI матрицы предназначена сущность «RACI матрица». Данная сущность связана с сущностями «Задача проекта» и «Роль проекта» отношениями «включает». Сущность «RACI матрица» является родителем, сущности «Роль проекта» и «Задачи проекта» являются потомками, мощность обоих отношений – P «RACI матрица включает одну или более ролей проекта» и «RACI матрица включает одну или более задач проекта». Сущность «Кандидат» связана отношением категоризации через дискриминатор с сущностями «Внешний кандидат» и «Сотрудник». Сущности «Внешний кандидат» и «Сотрудник» являются сущностями категориями сущности «Кандидат». Сущность «Сотрудник» имеет связь «имеет» с сущностью «Компетенция сотрудника». Мощность данного отношения P «сотрудник имеет одну или более компетенций». Сущность «Компетенция сотрудника» связана со справочниками «Компетенция» и «Ключ значения компетенции» отношениями «включает». Мощность данных отношений – 1, «компетенция сотрудника имеет одну компетенцию» и «Ключ значения компетенции имеет одно значение». В рамках разработанной концептуальной схемы базы данных блоки «Проект» и «Кандидат» используют одни и те же справочники: «Компетенция» и «Вид значения уровня компетенции». Данный подход дает возможность сравнить требования к роли проекта и компетенции сотрудников организации. 2.4 Выводы по главе 1) На основании принципов теории автоматического управления разработана функциональная схема процесса подбора участников команды ИТ проекта. На основании разработанной функциональной схемы процесса подбора участников команды ИТ проекта выделены основные функциональный 56

блоки и информационные потоки, определен объект управления – команда ИТ проекта и варианты изменения его состояния – изменение состава команды ИТ проекта. Разработанная функциональная схема может быть использована как основа для построения процедуры подбора команды ИТ проекта и информационной системы подбора команды ИТ проекта. 2) Разработана процедура подбора участников команды ИТ проекта, включающая все этапы данного процесса. Процедура представлена в виде диаграмм IDEF0. Разработанная процедура позволила определить основных участников процесса подбора команды ИТ проекта, этапы и последовательность действий при подборе специалистов, входные и выходные потоки данных на каждом из этих этапов. Разработанная процедура включает как уже существующие алгоритмы оценки (метод анализа иерархий) и выбора, так и вновь разработанные методы распределения задач – модифицированная RACI матрица, матрица совместимости выполняемых исполнителем задач. 3) Разработана концептуальная схема базы данных для информационной системы подбора команды ИТ проекта. В рамках данной концептуальной схемы выделены основные сущности и взаимосвязи между ними, которые позволяют осуществлять хранение информации и дальнейшую ее обработку. Разработанная концептуальная схема базы данных в дальнейшем может быть реализована на выбранной аппаратной платформе и языке программирования. 4) Необходимо выполнить проверку работоспособности процедуры подбора команды ИТ проекта. 57

3 ЭКСПЕРИМЕНТАЛЬНАЯ ПРОВЕРКА РАБОТОСПОСОБНОСТИ ПРОЦЕДУРЫ ПОДБОРА КОМАНДЫ ИТ ПРОЕКТА 3.1 Определение потребности в ресурсах для ИТ проекта Выполним подбор участников команды для проекта «Электронный документооборот между SAP системой и системой «Сбербанк Бизнес Онлайн»». В соответствии с процедурой, описанной в пункте 2.1 «Разработка и описание процедуры подбора команды ИТ проекта» данной работы первым этапом процесса является определение потребности в ресурсах. Первым шагом данного этапа является процесс «Разбить проект на задачи и указать свойства совместимости». Детализированный на задачи проект представлен в таблице 3.1. Таблица 3.1 – Детализированный на задачи проект. Номер задачи 1 1 2 3 4 5 6 7 8 9 Название задачи 2 Разработка проектного решения Согласование проектного решения Составление технического задания для программы формирования XML-реестра выгрузки данных Разработка программы формирования XML-реестра выгрузки данных Тестирование программы формирования XML-реестра выгрузки данных Документирование программы формирования XML-реестра выгрузки данных Составление технического задания для программы формирования XML-реестра загрузки данных Разработка программы формирования XML-реестра загрузки данных Тестирование программы формирования XML-реестра загрузки данных 58

Продолжение таблицы 3.1. 1 11 2 Документирование программы формирования XML-реестра загрузки данных Сдача разработки заказчику 12 Переход в продуктивную эксплуатацию 10 Для задач проекта необходимо указать свойства совместимости, то есть необходимо указать какие задачи могут быть выполнены одним исполнителем, а какие задачи одним исполнителем совмещать запрещено – создать матрицу совместимости выполняемых исполнителем задач. Свойства совместимости представлены в виде матрицы в таблице 3.2. По вертикали и горизонтали указаны задачи проекта, а на пересечении строки и столбца в каждой ячейке указана возможность пересечения исполнителя по данной задаче. Для удобства отображения информации вместо названий задач проекта указаны их номера из таблицы 3.1. Таблица 3.2 – Матрица совместимости выполняемых исполнителем задач 1 1 2 3 4 5 6 7 8 9 10 11 12 P P P P P P P P P P P P P P P P P P P P P E P P P P P P P P E P W P W P P P P P W P P P P P P P P P P E P P P P E P P P P P P P P 2 P 3 P P 4 P P E 5 P P P E 6 P P P P P 7 P P P W P P 8 P P P P W P E 9 P P P W P P P E 10 P P P P P P P P P 11 P P P P P P P P P P 12 P P P P P P P P P P 59 P P

Легенда заполнения матрицы совместимости выполняемых исполнителем задач: E (Error – ошибка) - совмещение исполнителем задач не допустимо, P (Possible - возможно) - совмещение исполнителем задач возможно, W (Warning - предупреждение) - совмещение задач исполнителем возможно, но лучше его избежать. В матрице совместимости видно: запрещено совмещение задач 3 и 4, то есть один исполнитель не может выполнять задачи «Составление технического задания для программы формирования XML-реестра выгрузки данных» и «Разработка программы формирования XML-реестра выгрузки данных»; запрещено совмещение задач 4 и 5, то есть один исполнитель не может выполнять задачи «Разработка программы формирования XML-реестра выгрузки данных» и «Тестирование программы формирования XML-реестра выгрузки данных»; запрещено совмещение задач 7 и 8, то есть один исполнитель не может выполнять задачи «Составление технического задания для программы формирования XML-реестра загрузки данных» и «Разработка программы формирования XML-реестра загрузки данных» запрещено совмещение задач 8 и 9, то есть один исполнитель не может выполнять задачи «Разработка программы формирования XML-реестра загрузки данных» и «Тестирование программы формирования XML-реестра загрузки данных»; возможно совмещение с предупреждениями задач 4 и 7, то есть желательно избегать совмещение исполнителем задач «Разработка программы формирования XML-реестра выгрузки данных» и «Составление технического задания для программы формирования XML-реестра загрузки данных» возможно совмещение с предупреждениями задач 4 и 9, то есть желательно избегать совмещение исполнителем задач «Разработка программы формирования XML-реестра выгрузки данных» и «Тестирование программы формирования XML-реестра загрузки данных» 60

желательно возможно совмещение с предупреждениями задач 5 и 8, то есть избегать совмещение исполнителем задач «Тестирование программы формирования XML-реестра выгрузки данных» и «Разработка программы формирования XML-реестра загрузки данных». Следующим шагом процесса подбора команды ИТ проекта является этап построения модифицированной RACI матрицы. В таблице 3.3 представлена составленная в первую итерацию модифицированная RACI матрица. Консультант 2 категории (К2) ABAP программист №1 (П_1) ABAP программист №2 (П_2) Наименование задачи 1 Разработка проектного решения Согласование проектного решения Составление технического задания для программы формирования XMLреестра выгрузки данных Разработка программы формирования XMLреестра выгрузки данных Тестирование программы формирования XMLреестра выгрузки данных 2 R 30% R 30% 3 4 5 6 C 25% R 45% Эксперт (Э) Роль (код роли) Консультант 1 категории (К1) Таблица 3.3 – Модифицированная RACI матрица, первая итерация. R 75% C 50% R 30% 61

Продолжение таблицы 3.3 1 Документирование программы формирования XMLреестра выгрузки данных Составление технического задания для программы формирования XMLреестра загрузки данных Разработка программы формирования XMLреестра загрузки данных Тестирование программы формирования XMLреестра загрузки данных Документирование формирования XMLреестра загрузки данных Сдача разработки заказчику Переход в продуктивную эксплуатацию Промежуточный итог 2 3 4 C 25% C 25% 5 6 R 15% R 45% R 75% C 50% R 30% C 25% R 15% R 30% R 10% R 10% R 10% R 25% R 25% R – исполнитель 100% 100% 100% 100% 100% C – Согласующий 100% 100% Общий итог 200% 200% 100% 100% 100% Для построения модифицированной RACI матрицы задачи проекта должны быть размещены по вертикали (из таблицы 3.1), а требуемые роли должны быть размещены по горизонтали, после чего ячейки матрицы кодируются и устанавливается необходимый процент занятости роли на задачи. Легенда кодировки матрицы: R – исполнитель (Responsible), A – Утверждающий (Accountable), C – Согласующий (Consulted), I – Наблюдатель 62

(Informed). После заполнения производится проверка матрицы на совмещение задач исполнителем. Для выполнения проверки закодированная матрица совмещения выполняемых исполнителем задач дополнительно заполняется кодами роли – если роль назначена более чем на одну задачу проекта, то в ячейках матрицы совмещения выполняемых исполнителем задач указывается код исполнителя для всех комбинаций назначенных задач. Проверка считается выполненной, если ячейки матрицы с кодом E не заполнены. Заполненная матрица совмещения выполняемых исполнителем задач приведена в таблице 3.4. Как видно из заполненной матрицы совмещения выполняемых исполнителем задач ячейки с кодом E (выделены красным) не заполнены, то есть проверка на совмещение задач пройдена для каждой роли. Таблица 3.4 – Заполненная матрица совмещения выполняемых исполнителем задач для модифицированной RACI матрицы первой итерации. 1 3 4 5 6 7 8 9 10 Э 1 2 2 Э 11 12 Э Э Э Э К1 3 К1 П_1 4 К2 5 К2 6 К2 К2 К2 К2 К2 К2 К1 7 К1 П_2 8 9 К2 К2 10 К2 К2 11 Э Э 12 Э Э К2 К2 К2 К2 Э К1 П_1 К2 К2 К1 П_2 К2 К2 Э При проверке загрузки каждой роли видно, что для роли Эксперт и Консультант 1 категории загрузка превышает 100%. Так как у ролей Эксперт и 63

Консультант 1 категории превышена загрузка, то в модифицированную RACI матрицу вместо ролей Эксперт и Консультант 1 категории вводятся дополнительные роли Эксперт№1 и Эксперт№2, а так же Консультант 1 категории №1 и Консультант 1 категории №2, задачи распределяются между этими ролями и проверка проводится повторно. В таблице 3.5 представлена модифицированная RACI матрица с учетом результатов предыдущей проверки. Консультант 1 категории №1 Консультант 1 категории №2 Консультант 2 категории ABAP программист №1 ABAP программист №2 Наименование задачи 1 Разработка проектного решения Согласование проектного решения Составление технического задания для программы формирования XMLреестра выгрузки данных Разработка программы формирования XMLреестра выгрузки данных Тестирование программы формирования XMLреестра выгрузки данных Эксперт №2 Роль Эксперт №1 Таблица 3.5 – Модифицированная RACI матрица, вторая итерация. 2 R 15% R 15% 3 R 15% R 15% 4 5 6 7 8 C 25% R 45% R 75% C 50% 64 R 30%

Продолжение таблицы 3.5 1 Документирование программы формирования XMLреестра выгрузки данных Составление технического задания для программы формирования XMLреестра загрузки данных Разработка программы формирования XMLреестра загрузки данных Тестирование программы формирования XMLреестра загрузки данных Документирование формирования XMLреестра загрузки данных Сдача разработки заказчику Переход в продуктивную эксплуатацию Промежуточный итог 2 3 4 5 C 25% 6 7 8 R 15% C 25% R 45% R 75% C 50% C 25% R 30% R 15% R 15% R 15% R 5% R 5% R 5% R 5% R 10% R – Исполнитель 50% 50% 50% 50% 100% 100% 100% C – Согласующий 50% 50% 50% 50% Общий итог 100% 100% 100% 100% 100% 100% 100% R 25% R 25% Для данной модифицированной RACI матрицы так же заполнена матрица совместимости выполняемых исполнителем задач – приведена в таблице 3.6. Как видно из заполненной матрицы проверка на совмещение задач исполнителем для модифицированной RACI матрицы второй итерации выполнена. 65

Таблица – 3.6 Заполненная матрица совместимости выполняемых исполнителем задач для модифицированной RACI матрицы второй итерации. 1 3 4 5 6 7 8 9 10 Э_1 Э_2 1 2 2 Э_1 Э_2 11 12 Э_1 Э_2 Э_1 Э_2 Э_1 Э_2 Э_1 Э_2 3 К1_1 4 П_1 К2 5 К2 6 К2 К2 К2 К2 К2 К2 7 К1_2 8 П_2 9 К2 К2 10 К2 К2 11 12 Э_1 Э_2 Э_1 Э_2 Э_1 Э_2 Э_1 Э_2 К2 К2 К2 К2 Э_1 Э_2 К1_1 П_1 К2 К2 К1_2 П_2 К2 К2 Э_1 Э_2 В соответствии с результатами построения модифицированной RACI матрицы для выполнения проекта необходимы следующие роли: Эксперт №1; Эксперт №2; Консультант 1 категории №1; Консультант 1 категории №2; Консультант 2 категории; ABAP программист №1; ABAP программист №2. После определения требующихся для выполнения проекта ролей необходимо для каждой роли определить набор компетенций, достаточный для выполнения каждой задачи, для которой эта роль определена. Предварительно в организации должен быть составлен справочник компетенций, который будет использоваться как для определения требований к ролям проекта, так и для 66

определения компетенций каждого сотрудника организации. Справочник компетенций составленный для проверки работоспособности разработанной в данной работе методики приведен в таблице 3.7. Таблица 3.7 – Справочник компетенций. Группа компетенций 1 Технические компетенции области SAP HCM Название компетенции 2 в Основы SAP HCM SAP PA базовый уровень SAP PA расширенный уровень SAP OM базовый уровень SAP OM расширенный уровень SAP TM базовый уровень SAP TM расширенный уровень SAP PY базовый уровень Технические компетенции области SAP ABAP SAP PY расширенный уровень в Знание ABAP Знание ООП ABAP Знание ABAP под HCM Разработка функций и операций PY и PT User-exits Enhancements Business Add-Ins MS Office integration Adobe forms Логическая база данных PNP Логическая база данных PCH Технические компетенции в Знание Microsoft Excel области других программных Знание Microsoft Word продуктов Знание Microsoft Visio Знание Microsoft Power Point 67

Продолжение таблицы 3.7 1 Личностные компетенции 2 Навыки проведения переговоров Навыки проведения презентаций Для определения уровня компетенции необходим справочник допустимых значений уровня каждой компетенции, данный справочник приведен в таблице 3.8. Уровень компетенции присваивается компетенции для каждой роли и для каждого сотрудника. Использование одной и той же шкалы для ролей и кандидатов дает возможность правильного сравнения требований к кандидатам и возможностей кандидатов. Таблица 3.8 – Справочник допустимых значений уровня компетенции. Значение уровня компетенции 1 Расшифровка значения уровня компетенции Знания отсутствуют 2 Владение на минимальном уровне 3 Владение на среднем уровне 4 Владение на хорошем уровне 5 Владение на максимальном уровне Определим требования к каждой роли использовав справочник компетенций и справочник допустимых значений уровня компетенции. Требования к каждой роли приведены в таблице Таблица 3.9. 68

Таблица 3.9 – Компетенции для каждой роли проекта. Роль 1 Эксперт №1 Эксперт №2 Консультант 1 категории №1 Консультант 1 категории №2 Компетенция 2 Значение уровня компетенции 3 SAP PA расширенный уровень 5 SAP OM расширенный уровень 5 Знание Microsoft Excel 3 Знание Microsoft Word 5 Знание Microsoft Visio 4 Знание Microsoft Power Point 4 Навыки проведения переговоров 5 Навыки проведения презентаций 5 SAP PA расширенный уровень 5 SAP OM расширенный уровень 5 Знание Microsoft Excel 3 Знание Microsoft Word 5 Знание Microsoft Visio 4 Знание Microsoft Power Point 4 Навыки проведения переговоров 5 Навыки проведения презентаций 5 SAP PA расширенный уровень 4 SAP OM расширенный уровень 4 Знание ABAP под HCM 3 Логическая база данных PNP 3 Знание Microsoft Word SAP PA расширенный уровень 5 4 SAP OM расширенный уровень 4 Знание ABAP под HCM 3 Логическая база данных PNP 3 Знание Microsoft Word 5 69

Продолжение таблицы 3.9 1 2 Консультант 2 категории ABAP программист №1 ABAP программист №2 3 SAP PA базовый уровень 4 SAP OM базовый уровень 4 Знание Microsoft Word 4 Основы SAP HCM 4 SAP PA базовый уровень 3 SAP OM базовый уровень 3 Знание ООП ABAP 5 Знание ABAP под HCM 5 MS Office integration 5 Логическая база данных PNP 5 Знание Microsoft Word 3 Основы SAP HCM 4 SAP PA базовый уровень 3 SAP OM базовый уровень 3 Знание ООП ABAP 5 Знание ABAP под HCM 5 MS Office integration 5 Логическая база данных PNP 5 Знание Microsoft Word 3 3.2 Подбор кандидатов для каждой роли ИТ проекта В соответствии с разработанной методикой следующим шагом является выбор группы наиболее подходящих кандидатов для каждой роли проекта. Так как это простая выборка из базы данных, то в рамках данной работы приведем только начальные параметры выборки и результаты данной выборки. Начальные параметры: диапазон отклонения компетенции кандидата от требования к роли ±1; 70

максимально допустимое количество несоответствий компетенций и требований при выборке кандидата 1. Результаты выборки приведены в таблице 3.10. Так как требования к ролям Эксперт №1 и Эксперт №1 одинаковые, то для этих ролей группа выбранных кандидатов одинаковая, в таблице приведена один раз, так же, как и для ролей Консультант 1 категории №1 и Консультант 1 категории №2, ABAP программист №1 и ABAP программист №2. Таблица 3.10 – Группа выбранных кандидатов для каждой роли Кандидат Компетенция 1 2 Значение уровня компетенции 3 Эксперт №1 и Эксперт №2 Сотрудник 01 Сотрудник 02 SAP PA расширенный уровень 4 SAP OM расширенный уровень 5 Знание Microsoft Excel 3 Знание Microsoft Word 4 Знание Microsoft Visio 5 Навыки проведения переговоров 4 Навыки проведения презентаций SAP PA расширенный уровень 4 5 SAP OM расширенный уровень 5 Знание Microsoft Excel 3 Знание Microsoft Word 4 Знание Microsoft Visio 3 Знание Microsoft Power Point 3 Навыки проведения презентаций 4 71

Продолжение таблицы 3.10 1 Сотрудник 03 Сотрудник 04 Сотрудник 05 Сотрудник 07 2 3 SAP PA расширенный уровень 5 SAP OM расширенный уровень 4 Знание Microsoft Excel 4 Знание Microsoft Word 5 Знание Microsoft Visio 3 Знание Microsoft Power Point 3 Навыки проведения переговоров 4 Навыки проведения презентаций 5 SAP PA расширенный уровень 4 SAP OM расширенный уровень 4 Знание Microsoft Excel 3 Знание Microsoft Word 5 Знание Microsoft Visio 3 Знание Microsoft Power Point 3 Навыки проведения переговоров 5 Навыки проведения презентаций SAP PA расширенный уровень 5 4 SAP OM расширенный уровень 4 Знание Microsoft Excel 3 Знание Microsoft Word 4 Знание Microsoft Visio 3 Знание Microsoft Power Point 3 Навыки проведения переговоров 5 Навыки проведения презентаций 4 SAP PA расширенный уровень 4 SAP OM расширенный уровень 4 Логическая база данных PNP 3 Знание Microsoft Word 4 72

Продолжение таблицы 3.10 1 Сотрудник 08 Сотрудник 09 Сотрудник 10 Сотрудник 11 2 3 SAP PA расширенный уровень 3 SAP OM расширенный уровень 3 Знание ABAP под HCM 3 Логическая база данных PNP 4 Знание Microsoft Word 5 SAP PA расширенный уровень 4 Знание ABAP под HCM 4 Логическая база данных PNP 3 Знание Microsoft Word SAP PA расширенный уровень 4 4 SAP OM расширенный уровень 4 Знание ABAP под HCM 4 Логическая база данных PNP 4 Знание Microsoft Word 5 SAP PA расширенный уровень 3 SAP OM расширенный уровень 3 Знание ABAP под HCM 3 Знание Microsoft Word 4 Консультант 2 категории SAP PA базовый уровень 4 Сотрудник 12 SAP OM базовый уровень 5 Сотрудник 14 Знание Microsoft Word SAP PA базовый уровень 3 5 SAP OM базовый уровень 3 Знание Microsoft Word 3 SAP PA базовый уровень 4 SAP OM базовый уровень 5 Знание Microsoft Word 4 Сотрудник 15 73

Продолжение таблицы 3.10 1 2 3 ABAP программист №1 и ABAP программист №2 Сотрудник 16 Сотрудник 17 Сотрудник 18 Основы SAP HCM 4 SAP PA базовый уровень 4 SAP OM базовый уровень 2 Знание ABAP под HCM 5 MS Office integration 4 Логическая база данных PNP 5 Знание Microsoft Word Основы SAP HCM 4 5 SAP PA базовый уровень 4 Знание ООП ABAP 4 Знание ABAP под HCM 4 MS Office integration 4 Логическая база данных PNP 4 Знание Microsoft Word 4 Основы SAP HCM 5 SAP PA базовый уровень 2 SAP OM базовый уровень 2 Знание ООП ABAP 5 Знание ABAP под HCM 4 Логическая база данных PNP 4 Знание Microsoft Word 4 74

Продолжение таблицы 3.10 1 Сотрудник 19 Сотрудник 20 2 3 Основы SAP HCM 4 SAP PA базовый уровень 3 SAP OM базовый уровень 3 Знание ООП ABAP 4 Знание ABAP под HCM 5 MS Office integration 4 Логическая база данных PNP 5 Знание Microsoft Word 4 Основы SAP HCM 5 SAP PA базовый уровень 3 SAP OM базовый уровень 4 Знание ООП ABAP 4 Знание ABAP под HCM 4 MS Office integration 5 Логическая база данных PNP 5 Знание Microsoft Word 4 После выборки группы кандидатов для каждой роли необходимо произвести выборку одно кандидата из группы для каждой роли. Для этих целей используется метод анализа иерархий. На первом этапе для каждого требования к роли определим коэффициент значимости каждой компетенции используя метод парных сравнений. Так как для ролей Эксперт №1 и Эксперт №1, Консультант 1 категории №1 и Консультант 1 категории №2, ABAP программист №1 и ABAP программист №2 требования одинаковые, то коэффициент значимости определим для одного эксперта, одного консультанта 1 категории и одного ABAP программиста. Результаты вычислений приведены в таблице 3.11. 75

Таблица 3.11 – Коэффициент значимости каждой компетенции для роли. Роль Компетенция 1 Эксперт №1 и Эксперт №2 2 Консультант 1 категории №1 и Консультант 1 категории №2 Консультант 2 категории ABAP программист №1 и ABAP программист №2 После Коэффициент значимости 3 SAP PA расширенный уровень 0.3 SAP OM расширенный уровень 0.27 Знание Microsoft Excel 0.06 Знание Microsoft Word 0.11 Знание Microsoft Visio 0.02 Знание Microsoft Power Point 0.02 Навыки проведения переговоров 0.12 Навыки проведения презентаций 0.1 SAP PA расширенный уровень 0.38 SAP OM расширенный уровень 0.33 Знание ABAP под HCM 0.13 Логическая база данных PNP 0.13 Знание Microsoft Word SAP PA базовый уровень 0.03 0.45 SAP OM базовый уровень 0.45 Знание Microsoft Word 0.09 Основы SAP HCM 0.03 SAP PA базовый уровень 0.07 SAP OM базовый уровень 0.05 Знание ООП ABAP 0.16 Знание ABAP под HCM 0.24 MS Office integration 0.18 Логическая база данных PNP 0.25 Знание Microsoft Word 0.02 определения коэффициента значимости путем определим удельный вес каждого кандидата в группе. Полученные результаты приведены в таблице 3.12. 76

Таблица 3.12 – Удельный вес кандидатов для каждой роли Группа роли 1 Эксперт №1 и Эксперт №2 Консультант 1 категории №1 и Консультант 1 категории №2 Консультант 2 категории ABAP программист №1 и ABAP программист №2 Кандидат 2 Удельный вес 3 Сотрудник 3 4.47 Сотрудник 4 4.23 Сотрудник 1 4.15 Сотрудник 5 4.02 Сотрудник 2 3.99 Сотрудник 06 4.45 Сотрудник 10 4.03 Сотрудник 07 3.35 Сотрудник 08 3.19 Сотрудник 11 2.64 Сотрудник 09 Сотрудник 15 2.55 4.41 Сотрудник 12 4.32 Сотрудник 14 3.87 Сотрудник 13 3.51 Сотрудник 20 4.39 Сотрудник 19 4.37 Сотрудник 17 3.83 Сотрудник 16 3.75 Сотрудник 18 3.23 Расположив в каждой группе кандидатов в порядке убывания удельного веса можно выбрать сотрудника для каждой роли проекта. Исходя из полученных результатов: Эксперт №1 – Сотрудник 3; Эксперт №2 – Сотрудник 4; 77

Консультант 1 категории №1 – Сотрудник 6; Консультант 1 категории №2 – Сотрудник 10; Консультант 2 категории – Сотрудник 15; ABAP программист №1 – Сотрудник 20; ABAP программист №2– Сотрудник 19. 3.3 Выводы по главе 1) Осуществлена проверка работоспособности разработанной процедуры на примере подбора команды для ИТ проекта «Электронный документооборот между SAP системой и системой «Сбербанк Бизнес Онлайн»». 2) Проверка работоспособности процедуры по указанному ИТ проекту позволила разбить проект на 12 задач и сформировать для них матрицу совместимости выполняемых исполнителем задач. Процедура позволяет построить модифицированную RACI матрицу и проверить её на непротиворечивость, а уже на основании модифицированной RACI матрицы позволяет определить необходимые роли для выполнения данного проекта (на рассматриваемом примере проекта с помощью процедуры было определено 7 ролей). Для рассматриваемого примера при помощи процедуры для каждой из определенных ролей сформирована группа кандидатов, с применением метода анализа иерархий для каждого кандидата из группы определен удельный вес и выбран лучший – с наибольшим удельным весом. На завершающем этапе процедура позволила сформировать перечень участников команды для рассматриваемого ИТ проекта 3) Проверка работоспособности предложенной процедуры показала, что данная процедура является работоспособной. Процедуру возможно применять для ИТ проектов различного масштаба. Разработанная процедура позволяет выбрать наиболее подходящего кандидата для выполнения каждой задачи проекта. 78

ЗАКЛЮЧЕНИЕ При выполнении диссертационной работы была достигнута поставленная цель магистерской диссертации – рациональное распределение человеческих ресурсов в процессе подбора команды ИТ проекта. В процессе решения поставленной задачи были получены следующие результаты. 1) На основании проведенного анализа существующих подходов к подбору команды ИТ проекта было установлено, что на текущий момент ни одна из предлагаемых методик и информационных средств не решают задачу подбора команды ИТ проекта полностью, а лишь на отдельных этапах процесса подбора команды ИТ проекта. 2) Разработана функциональная схема процесса подбора команды ИТ проекта, позволившая выделить основные функциональные блоки и информационные потоки данного процесса, определить объект управления (команда ИТ проекта) и варианты изменения его состояния (изменение состава команды ИТ проекта). Данная функциональная схема является основой для разработки процедуры подбора команды ИТ проекта. 3) Разработана поцедура подбора команды ИТ проекта, которая включает в себя все этапы данного процесса. Определено, что процедура подбора команды ИТ проекта должна включать два основных этапа: определение потребности в ресурсах для проекта и осуществление подбора кандидатов для выявленных ресурсов. 4) Разработан потребности в метод человеческих определения ресурсах необходимой для и достаточной ИТ проекта посредством модифицирования RACI матрицы, применяемой в методологии управления проектами PMBoK, и введением в алгоритм её проверки матрицы совместимости выполняемых исполнителем задач. 5) Разработана концептуальная схема базы данных, содержащая сведения о проекте, включающие информацию о составе проекта, его свойствах, необходимых ресурсах и требованиях к ним, а так же сведения о существующих человеческих ресурсах. Разработанная концептуальная схема 79

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ COBIT 5: Бизнес-модель по руководству и управлению ИТ на 1 предприятии [Текст]. – Соединенные Штаты Америки, 2012. IDEF1X. Электронный учебник [Электронный ресурс] – режим 2 доступа http://dit.isuct.ru/ivt/books/CASE/case10/idef1x/, свободный. ISO21500: Guidance on project management. [Электронный ресурс] – 3 режим доступа: http://www.projectprofy.ru/, свободный. Абакаров, А.Ш. Об одном подходе к управлению персоналом 4 фирмы [Электронный ресурс] / А.Ш. Абакаров, А.Ю. Иванов, Ю.А. Сушков. – Режим доступа: tomakechoice.com/paper/MAI&Personal.pdf, свободный. Авдошин, С. М. Информатизация бизнеса. Управление рисками. 5 [Текст] / С. М. Авдошин, Е. Ю. Песоцкая. – Москва: ДМК Пресс, 2011. – 176с. Андрианова, Е.Г. Методы и программные средства специальной 6 обработки данных человеческими аппаратно-программного ресурсами предприятия комплекса [Электронный управления ресурс] / Е.Г. Андрианова, Ю.В. Буланова // Современные проблемы науки и образования. – – 2015. № 2. – Режим доступа http://www.science- education.ru/ru/article/view?id=21548, свободный. 7 Ажмухамедов, А.И. Математическая модель мотивационного управления персоналом [Текст] / А. И. Ажмухамедов, О. М. Проталинский // Вестник АГТУ. Управление, вычислительная техника и информатика. – 2016 – № 2 – С. 50 – 57. 8 Азямова, Л.В. Аттестация персонала организаций: Методические и организационные аспекты [Текст]: автореферат дис.кандидата экономических наук (08.00.05) / Лариса Владимировна Азямова, - Москва, 2002 – 15 с. 9 обработки Андрианова, Е.Г. методы и программные средства специальной данных человеческими аппаратно-программного ресурсами предприятия комплекса [Электронный управления ресурс] / Е.Г. Андрианова, Ю.В. Буланова // Современные проблемы науки и образования. – 81

– 2015. № 2. – Режим доступа http://www.science- education.ru/ru/article/view?id=21548, свободный. 10 Арчибальд, Р. Управление высокотехнологичными проектами [Текст] / Р. Арчибальд; пер. с англ. Мамонтова Е.В.; под. ред. Баженова А.Д., Арефьева А.О. – 3-е изд., перераб и доп. – Москва: Компания АйТи; ДМК Пресс, 2010. – 464 с. 11 Асадуллаев, адаптивного Р.Г. Построение управления структурной индивидуальным схемы обучением процесса персонала промышленных предприятий [Электронный ресурс] / В.В. Ломакин, Р.Г. Асадуллаев //II международная научно-техническая интернет- конференция «Информационные системы и технологии». – Орел: Госуниверситет – УНГЖ. – Режим 2013. доступа: http://isitconf.guunpk.ru/conferences/2/materials/manager/view/178, свободный. 12 Безруков, А.В. Некоторые аспекты анализа компетенций сотрудников компании в сфере разработки программного обеспечения [Электронный ресурс] / А.В. Безруков // Управление экономическими системами. – 2012. - № 10. – Режим доступа http://uecs.ru/ru/instrumentalniimetody-ekonomiki, свободный. 13 Бейльханов, управленческих Д.К. решений при Информационная подборе технология разработчиков принятия программного обеспечения [Текст]: диссертация, к.т.н.: 05.13.10: защищена 03.07.2015 / Бейльханов Дамир Кайржанович. – Астрахань, 2015. – 126 с. 14 Бейльханов, Д.К. Использование методов оценки кандидатов в процессе командообразования [Текст] / Д.К. Бейльханов, И.Ю. Квятковская // Международная молодежная научная конференция «Поколение будущего: Взгляд молодых ученых». – Курск, 2012. – С. 156 – 160. 15 Бейльханов, Д.К. Использование модели компетенций в процессе командообразования [Текст] / Д.К. Бейльханов, И.Ю. Квятковская // XXX Международная заочная научно-практическая конференция «Технические науки – от теории к практике» (СибАК-2014). – Новосибирск, 2014. – С. 7 – 12. 82

16 Бейльханов, Д.К. Метод исследования модели компетенций в системе поддержки принятия решений [Текст] / Д.К. Бейльханов, И.Ю. Квятковская // 2-я Международная молодежная научная конференция «Поколение будущего – 2013». – Курск, 2013. – С. 87 – 91. 17 Бейльханов, Д.К. Разработка алгоритма подбора приоритетной команды в процессе командообразования [Текст] / Д.К. Бейльханов, И.Ю. Квятковская // Вестник Астраханского государственного технического университета: управление, вычислительная техника и информатика. – 2014 – №3 – С. 75 – 84. 18 Бейльханов, Д.К. Система поддержки принятия решений по формированию команд проектов на основе компетентностного подхода [Текст] / Д.К. Бейльханов, И.Ю. Квятковская // Международная научно-практическая конференция «Проблемы развития науки и образования: теория и практика. Часть II». – Москва, 2013. – С. 125 – 129. 19 сфере ИТ Бейльханов, Д.К. Управление процессом командообразования в с Д.К. Бейльханов использованием // Журнал компетентностного «Ученые записки» подхода [Текст] / Санкт-Петербургского Университета управления и экономики. – 2014. – №6. – С. 36 – 43. 20 Богданов, В.В. Управление проектами. Корпоративная система – Шаг за шагом [Текст] / В.В. Богданов. – Москва: Манн, Иванов и Фербер, 2012. – 258с. 21 Борисов, С. А. Особенности управления проектами в области информационных систем [Текст] / С. А. Борисов, А. Ф. Плеханова // Фундаментальные исследования. – 2014. – № 9 (ч. 3). С. 625–629. 22 Боронина, Л. Н. Основы управления проектами: Учеб. Пособие [Текст] / Л. Н. Боронина, З.В. Сенук. – Екатеринбург: Изд-во Урал. ун-та, 2015. – 112с. 23 Брумштейн, Ю. М. Анализ моделей и методов выбора оптимальных совокупностей решений для задач планирования в условиях ресурсных ограничений и рисков [Текст] / Ю. М. Брумштейн, Д. А. Тарков, И. А. Дюдиков 83

// Прикаспийский журнал: управление и высокие технологии. – 2013 – №3 – С.169 – 179. 24 Брумштейн, Ю. М. Модели оптимизации подбора ресурсов при управлении совокупностью проектов с учетом зависимости качества результатов, рисков и затрат [Текст] / Ю. М. Брумштейн, И. А. Дюдиков // Вестник АГТУ. Управление, вычислительная техника и информатика. – 2015 № 1 – С. 78 – 87. 25 Будыльский, А. В. Управление командой разработчиков на этапе исполнения IT-проекта с использованием метода критической цели [Тест] / А.В. Будыльский, И. Ю. Квятковская // Вестник АГТУ. Управление, вычислительная техника и информатика. – 2014 – № 3 – С. 85 – 91. 26 В поисках SAP-консультанта. [Электронный ресурс] / Статьи от экспертов LUXOFT PERSONNEL. – Режим доступа: http://www.luxoftpersonnel.ru/press/articles/7_steps/, свободный. 27 Вылегжанина, А.О. Информационно-технологическое и программное обеспечение управления проектом: учебное пособие [Текст] / А.О. Вылегжанина. – Москва – Берлин: Директ-Медиа, 2015. – 429 с. 28 Горбовцов, Г.Я. Системы управления проектом: учебное пособие [Текст] / Г.Я. Горбовцов. – Москва: Издательский центр ЕАОИ, 2011. – 344 с. 29 Грекул, В.И. Методические основы управления ИТ-проектами [Текст] / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. – Москва: Бином, 2011. – 392с. 30 ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. [Текст] – Москва: Стандартинформ, 2011. – 9с. 31 ГОСТ Р ИСО 21500–2014. Руководство по проектному менеджменту. [Текст] – Москва: Стандартинформ, 2015. – 45с. 32 Демарко, Т. Человеческий фактор: успешные проекты и команды [Текст] / Т. Демарко, Т Листер; пер. с анг. М. Зислис, С. Маккавеев. – 3-е изд. – Спб.: Символ-Плюс, 2014. – 288 с. 84

33 ДеМарко, Т. Вальсируя с медведями [Текст] / Т. Демарко, Т. Листер. – Компания p.m.Office, 2005. – 196 с. 34 И.В. Доронина, И.В. Основы оценки персонала [Электронный ресурс] / Доронина, В.Н. Меньшова. – Режим доступа: http://siu.ranepa.ru/UMM_1/2440/2_3.htm, свободный. 35 Дублин, А.Б. Проект «Методика оценки уровня компетентности SAP специалистов» [Электронный ресурс] / А.Б. Дублин. - Режим доступа: http://sapland.ru/sapland-news/startoval-proekt-metodika-obektivnoi-otsenkiurovnya-kompetentnosti-sap-spetsial.html, свободный. 36 Иванова, С.В. Оценка компетенций методом интервью: Универсальное руководство [Текст] / С.В. Иванова. – М.: Альпина Паблишер. – 2015. – 155 с. 37 ИТ-аутсорсинг [Электронный ресурс] / режим доступа https://ru.wikipedia.org/wiki/%D0%98%D0%A2%D0%B0%D1%83%D1%82%D1%81%D0%BE%D1%80%D1%81%D0%B8%D0 %BD%D0%B3, свобоный. 38 Кожухар, В.М. Инновационный менеджмент: учебное пособие [Текст] / В.М. Кожухар. – Москва: Издательско-торговая корпорация «Дашков и К», 2014. – 292с. 39 Коротков, эффективность, деловая Э.П. Управление репутация, человеческим креативный потенциал капиталом: [Текст] / Э.П. Коротков // Проблемы теории и практики управления. 2010. № 4. – С.18– 30. 40 Костылев, А.А. Проектное управление по стандарту ISO 21500:2012 обзор и перспектива использования [Текст] / А.А. Костылев // Тамбовский государственный университет им. Р.Г. Державина, 2014. - №12. – С. 145 – 150. 41 Кулябов, Д.С. Введение в формальные методы описания бизнес- процессов: Учеб. пособие. [Текст] / Д.С. Кулябов, А.В. Королькова – Москва: РУДН, 2008. – 202с. 85

42 Лаптев, В. В. Метод оценки деятельности разработчиков объектно- ориентированного программного обеспечения [Текст] / В.В. Лаптев, А.В. Морозов // Вестник АГТУ. Управление, вычислительная техника и информатика. – 2010 - № 1 – С. 122 – 126. 43 Локк, Д. Основы управления проектами [Текст] / пер. с англ. – Москва: «HIPPO», 2004. – 253с. 44 студентов Матяш, Н.В. [Электронный Методика ресурс] оценки / Н.В. проектной компетентности Матяш, Ю.А.Володина // Психологические исследования: электрон. науч. журн. 2011. N 3(17). – Режим доступа: http://psystudy.ru/index.php/num/2011n3-17/488-matyash-volodina17, свободный. 45 парных Метод парных сравнений [Электронный ресурс] // Глава 6. Метод сравнений (ПС). – Режим доступа: http://ecsocman.hse.ru/data/466/641/1219/ch6.pdf, свободный. 46 Методология функционального моделирования IDEF0. Руководящий документ. [Текст] – Москва: Издательство стандартов, 2000. – 75с. 47 Мизинцева, М.Ф. Оценка персонала [Учебное пособие] / М.Ф. Мизинцева, А.Р. Сардарян. – М.: Юрайт. – 2014. – 19 с. 48 Миронова, Н. А. Интеграция модификаций метода анализа иерархии для систем поддержки принятия групповых решений [Текст] / Н.А.Миронова // Радиоэлектроника, информатика, управления. – 2011. – №2 – С. 47-54. 49 Николаенко, В.С. Анализ инструментария по обеспечению функции управления рисками в ИТ-проектах [Электронный ресурс] / В.С. Николаенко // Государственное управление . Электронный вестник. – 2015. – №49 –С. 105– 118. Режим доступа: http://e- journal.spa.msu.ru/vestnik/item/49_2015nikolaenko.htm, свободный. 50 Официальный сайт компании Консист [Электронный ресурс] / Режим доступа: http://www.cbgr.ru/, свободный. 86

51 Плаксин М.А. Метод анализа иерархий как инструмент обоснования бизнес-решений [Текст] / М.А. Плаксин // Internatioanl Conference «e-Management & Business Intelligence». – 2007. – C.1-8. 52 Попова, О. В. Управление качеством проекта: роль человеческого ресурса [Текст] / О. В. Попова // Вестник Сибирской государственной автомобильно-дорожной академии – 2014. – №3 (37). – С. 111 – 115. 53 Принятие решений на основе метода анализа иерархий [Электронный ресурс] // Глава 3. Принятие решений на основе метода анализа иерархий. – Режим доступа: http://www.pandia.ru/text/78/382/492.php, свободный. 54 Прохоров, Ю.К. Управленческие решения [Текст] / Ю.К. Прохоров, В.В. Фролов – 2-е изд., – СПб.: СПбГУ ИТМО, 2011. – 138 с. 55 Раскладка профессий в области ИТ [Электронный ресурс] / Режим доступа:http://www.apkit.ru/committees/education/projects/Layout_of_ITprofession s.pdf, свободный. 56 Рубанов, В.Г. Линейные системы автоматического управления: Учеб. Пособие [Текст] / В.Г. Рубанов. – Белгород: Изд.БелГТАСМ, 1997. – 106с. 57 Руководство к своду знаний по управлению проектами (Руководство PMBOK) [Текст]. – 4-е издание. – США: Project Management Institute, Inc. – 2008. – 463 с. 58 Рыбанов, А.А. Инструментальные средства автоматизированного проектирования баз данных: Учебное пособие и варианты заданий к лабораторным работам по дисциплине «Базы данных» [Текст] / А.А. Рыбанов – Волгоград: ВолгГТУ, 2007. – 96с. 59 Саати, Т. Принятие решений. Метод анализа иерархий [Текст] / Т. Саати; пер. с анг. Р.Г. Вачнадзе. – Москва: Радио и связь, 1993. – 278с. 60 Сосновый, А. Оценка персонала с применением модели компетенций [Электронный ресурс] / А. Сосновый, А. Гун. – Режим доступа: http://free-consulters.ru/?p=1003, свободный. 87

61 Уиддет, С. Руководство по компетенциям [Текст] / С Уиддет, С. Холлифорд. - М.:Гиппо, 1978. – 240 с. 62 Управление менеджеров 4CIO. – проектами Режим [Электронный доступа: ресурс] / Клуб топ- http://www.4cio.ru/pages/index/150, свободный. 63 Управление проектами с использованием Microsoft Project [Электронный ресурс] / Т.С. Васючкова, М.А. Держо, Н.А. Иванчева, Т.П. Пухначева – Режим доступа http://www.intuit.ru/studies/courses/2199/357/info, свободный. 64 Управление проектом. Основы проектного управления: учебник [Текст] / под. ред. проф. М.А. Разу. – Москва: КНОРУС, 2006. – 768 с. 65 Управление человеческими ресурсами проекта (Project Human Resource Management) [Электронный ресурс] / Project Management Experience. Стандарт ANSI PMI глава PMBOK, 2. Режим доступа: http://pmexperience.org/ru/content/glava-2-standart-ansi-pmi-pmbok-upravleniechelovecheskimi-resursami-proekta-project-human-resource-management, свободный. 66 Цинес, Г.Л. Менеджмент проектов в практике современной компании [Текст] / Г.Л. Цинес, А.С. Товб – Москва: ЗАО «Олимп – Бизнес», 2006. – 304с. 67 Цуканова, О. А. Методология и инструментарий моделирования бизнес- процессов: учебное пособие [Текст] / О.А. Цуканова – СПб.: Университет ИТМО, 2015. – 100 с. 68 Чернявская, Е. Тимбилдинг: целесообразность, результаты и перспективы командообразующих мероприятий [Электронный ресурс] / Е. Чернявская. – Режим доступа: http://efsol.ru/articles/Teambuilding-results-andpersepktivy.html, свободный. 69 Чиркова, И.Г. Внутрифирменное планирование проектной деятельности: учебное пособие [Текст] / И.Г. Чиркова, К.Ч. Акберов. – Новосибирск: Изд-во НГТУ, 2015. – 64с. 88

70 Чупахина, Е.И. Функциональная схема процесса подбора участников команды ИТ-проекта [Текст] / Е.И. Чупахина, И.А. Чупахин, В.В. Ломакин // IV Международная научно-практическая конференция «Научно-технический прогресс: актуальные и перспективные направления будущего». – Кемерово: ЗапСибНЦ, 2016. – С. 89-91. 71 Юлдашев, С. Внедряем систему оценки [Электронный ресурс] / С. Юлдашев, Е. Севодина // Журнал «Штат». Управление людьми в интересах бизнеса: сайт. – Режим доступа: http://www.hrmedia.ru/node/597, свободный. 89

ПРИЛОЖЕНИЕ Концептуальная схема базы данных для информационной системы подбора участников команды ИТ проекта 90

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв