Файл: Исследование методов и средств моделирования систем управления проектами на предприятии.docx

возможности для повышения эффективности процесса управления проектами. Во многом ручная модель управления, установившаяся в компании, не вполне адекватна процессам создания проектов, выполняемых командой.

Для организации работы проектной команды необходим единый информационный центр, с помощью которого можно решать следующие задачи управления:

• 
  сохранять проектную документацию;
  
• 
  вести протоколы митингов, стендапов, мозговых штурмов, производственных совещаний;
  
• 
  хранить презентации докладов сотрудников;
  
• 
  оповещать сотрудников о событиях и планах;
  
• 
  создавать реестры задач, бизнес-процессов, собственных разработок;
  
• 
  создавать собственную библиотеку готовых решений по профилю компании;
  
• 
  создавать «запасники» интересных идей, методов, процедур, которые могут пригодиться в будущем;
  
• 
  назначать задачи и раздавать поручения;
  
• 
  осуществлять обратную связь по поставленным задачам и поручениям.
  

Цель данного этапа диссертационного исследования - разработать модель подобного информационного центра в виде автоматизированной системы управления проектами. Эта АСУ проектами должна быть интегрирована в

существующую систему управления проектами и за счет синергии повысить эффективность управления проектами, и, значит, работы компании в целом.

Анализ методов и алгоритмов процесса управления проектами в компании ООО «Мастер Маинд Инк» показал, что управление на этапе R&D существенно отличается от процесса управления на этапе исполнения программного продукта.

Моделируемая система должна быть основана на программных

---

продуктах, которые на данный момент используются на предприятии ООО

«Мастер Маинд Инк»: Jira и Confluence. Данный продукт не будет заменять текущие системы, а будет встроен в нее с целью автоматизации рутинных процессов. Продукт не является самостоятельной и независимой системой, а является плагином для системы Jira, поэтому должен быть адаптирован к работе с ней.

Существуют следующие методы адаптации программного обеспечения:

1. 
   параметрическая адаптация, связанная с настройкой параметров программы. Это самый простой способ адаптации; он предполагает изменение значений характеристик, регулирующих работу программы. С помощью параметрической адаптации возможно проводить необходимую настройку функций и компонентов программы, и отбирать стратегии поведения из предлагаемого набора стратегий;
   
2. 
   функциональная адаптация предполагает изменение функций программного обеспечения в установленных пределах. Функциональная адаптация может выполняться совместно с параметрической. Структура и организация ПО при этом остаются неизменными;
   
3. 
   организационная адаптация - перенастройка потоков и процессов в системе. Организационная адаптация означает перераспределение потоков и процессов системы как ее внутренних ресурсов, без изменения ее структуры. Может сочетаться с функциональной адаптацией;
   
4. 
   структурная адаптация - изменение структуры системы. Используя этот способ адаптации, мы производим модификацию или замену одних
   

структурных элементов системы, или алгоритмических модулей, на другие. Адаптируемая программа становится более адекватной решаемым задачам. При

---

этом возможно использование всех предыдущих видов адаптации системы;

5. 
   размножение - порождение себе подобных потомков. Адаптация размножением является эффективным методом адаптации. Система производит себе подобную, но обладающую наличием свободных ресурсов и способностью к изменениям.
   
6. 
   развитие - направленный процесс эволюции систем. Адаптация программного обеспечения, происходящая через развитие, подобна процессам эволюции живых систем. Адаптируемое ПО проходит процесс эволюции через накопление информации о себе, внешней среде, решаемых задачах. Проходя через этапы зарождения, становления определенных качеств, устойчивого функционирования, деградацию и гибель, ПО как система становится более приспособленным для решения задач [3].
   

Моделируемая система управления проектами должна представлять собой отдельный функциональный блок, встраиваемый в систему Jira и Confluence, а также взаимодействующий с ними посредством их функциональных возможностей. Таким образом, существующая система управления проектами в компании ООО «Мастер Маинд Инк», сочетающая ручное и автоматизированное, несколько меняет свою структуру, организацию и функции.

Рассмотрим, как меняются функции. В модели «As Is» функции создания целого ряда документов и задач лежали на проектной команде и проектном менеджере. Посредством R&D-плагина эта работа будет выполняться автоматически, так как в разрабатываемую систему будет заложен алгоритм R&D-деятельности, благодаря чему шаблоны документов на каждом этапе процесса управления будут формироваться автоматически;

---

задачи и поручения также будут генерироваться с помощью новой системы благодаря функции отслеживания действий проектной команды.

Таким образом, не нарушая установленных пределов изменения функций существующей системы управления, система «To Be» расширяет спектр функций, используемых в команде.

Организационная адаптация системы управления проектами состоит в том, что прежние потоки управленческой информации меняют свою траекторию. Взаимодействие между проектным менеджером и отделами компании будет осуществляться в новой модели через единый информационный центр управления. При этом точки входа и выхода организационных потоков остаются прежними.

Также несколько меняется структура существующей системы управления проектами. Методы ручного управления перестают быть обязательными и в системе Jirа появляется новый элемент - R&D-плагин.

На основе структурно-функционально-организационного метода адаптации была разработана модель АСУ проектами на предприятии ООО

«Мастер Маинд Инк». Модель представлена следующими диаграммами:

• 
  верхнеуровневая диаграмма экосистемы «R&D-плагин»;
  
• 
  диаграмма бизнес-процессов управления «To Be»;
  
• 
  диаграмма прецедентов;
  
• 
  ER-диаграмма.
  

Верхнеуровневая диаграмма экосистемы «R&D-плагин» показана на рисунке 3.1.

Диаграмма экосистемы показывает, с какими уже существующими подсистемами предстоит взаимодействовать новому плагину, и отображает связи между ними.

Рисунок 3.2 изображает модель взаимодействия системы управления проектами «To Be»

---

(«Как будет») с участниками этапа R&D.

Как мы можем видеть, в данной модели появляется еще один участник - R&D Plugin. Процессы, которые присутствовали в модели «As Is», перешли из пулов участников проекта в пул плагина, что означает, что выполнение этих процессов берет на себя плагин.


Рисунок 3.1 - Диаграмма экосистемы встраиваемого плагина для управления проектами на этапе R&D



Рисунок 3.2 - Диаграмма бизнес-процессов модели «To Be» управления проектами на этапе R&D
Забирая на себя часть обязанностей остальных участников процесса, новый плагин может значительно сократить время, необходимое проектной команде на создание задач, документации и на отслеживание процесса разработки.

Рассмотрим подробнее предлагаемую диаграмму бизнес-процессов управления проектами на этапе R&D «To Be»:

1. 
   создание входного документа. Для инициации создания нового проекта проектным менеджером плагин предлагает ему заполнить входной документ по установленному шаблону: заполнить список целей проекта, заполнить список бизнес-требований, к каждому бизнес-требованию добавить комментарий - создается ли проект с помощью ИИ либо с помощью алгоритмизированного подхода, а также создать набор KPI будущего продукта;
   
2. 
   создание задачи на исследование решений. По окончании совещания PM заканчивает работу над созданием документа, проверяет заполненные данные и подтверждает создание нового проекта в системе Jira. Плагин создаёт новый проект в Jira, создает задачу на исследование решений, а также сохраняет протокол, заполненный PM в системе Confluence. Далее PM закрепляет задачу за сотрудником Data Science-отдела. Сотрудник, получивший задание, приступает к ее выполнению;
   
3. 
   создание шаблона списка возможных вариантов решения. Плагин автоматически создает шаблон для найденных вариантов решения в системе Confluence. Данный шаблон в качестве ссылки будет прикреплен к задаче, созданной в п.2;
   
4. 
   создание списка готовых решений. После пункта 3 сотрудник Data Science заполняет список найденных решений в документ. После совещания, на котором проектная команда будет обсуждать варианты решения, создатель списка сделает пометки, в которых расставит приоритеты для каждого найденного решения. Также помечаются решения, которые требуют адаптации;
   
5. 
   создание дерева решений (узел 1-го уровня). На странице плагина проектным менеджером создается корневой узел будущего дерева решения;
   
6. 
   создание узла модели. Проектный менеджер инициирует создание узла решения. АСУ создает узел решения соответственно выбранным в п.4 приоритетам и переходит к следующему этапу;
   
7. 
   создание задачи на адаптацию решения. Если решение, соответствующее созданному в п. 6 узлу нельзя применить в готовом виде, то
   

---