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

клиента.

Когда Product Owner убежден, что модель отвечает заявленным целям проекта (в удовлетворительной степени), команда может приступить к его производству программного продукта.

На основании выполненного анализа организации процесса исследовательской деятельности в компании ООО «Мастер Маинд Инк» можно сделать вывод о том, что структура этого процесса не является линейной. Развертка Agile-модели жизненного цикла проекта имеет линейную архитектуру, как представлено на рисунке 2.8.

Рисунок 2.8 - Развертка Agile-модели жизненного цикла проекта Модели Crisp DM, в отличие от Agile-моделей, можно представить в виде

дерева решений, где каждая ветка отображает новый цикл разработки.



Рисунок 2.9 - Дерево решений модели Crisp DM

Корневым узлом дерева являются определенные границы проекта в виде целей, бизнес-требований и набора KPI. Узлами второго уровня можно представить найденные или адаптированные возможные решения поставленной задачи. Далее каждый узел имеет ветвление на разработанные ‘features’. Из данных узлов расходятся ветви выбранных для параметров.

Каждый узел принадлежит одному из рассмотренных ранее фаз этапа

R&D.

3. 1   2   3   4   5   6   7   8   9   10   11

---

Модель системы управления проектами «As Is»

Выполненный анализ процесса создания программного ИИ-содержащего продукта, а также организационной структуры процесса в компании ООО

«Мастер Маинд Инк» позволяет построить модель «As Is» («Как есть») процессов управления в компании.

Модель изображена на рисунке 2.10 приложения Б. Она отображает управленческие действия проектного менеджера в инструментах Jira и Confluence, а также действия остальных сотрудников компании, принимающих на себя функции Project Manager в соответствии с текущими потребностями проекта. Построенная модель отражает процессы управления, сопровождающие все фазы R&D-деятельности.

Процессы распределены между Project Manager, отделом Data Science и отделом Data Engineering.

Рисунок 2.10 – Модель управления процессами «As Is»

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

Рассмотрим подробнее представленную модель процесса управления проектом, функционирующую в компании ООО «Мастер Маинд Инк».

1. 
   создание входного документа. Этот процесс принадлежит фазе анализа предметной области. Здесь команда собирается на совещание и записывает на листочке или доске все принятые на совещании решения, а именно: список целей, список бизнес-требований, список KPI, а также пометок к каждому бизнес-требованию, с помощью чего он решается (ИИ или алгоритм). После совещания PM делает фотографию доски или листочка и переносит все записи в Confluence;
   
2. 
   создание задачи на исследование решений. По окончании совещания PM создает задачу в Jira, и закрепляет задачу за сотрудником Data Science-отдела. Сотрудник, получивший задание, приступает к ее выполнению;
   
3. 
   создание списка готовых решений. После исследования сотрудник создает список найденных решений в виде презентации и делает доклад для проектной команды;
   
4. 
   выбор решения. После прослушивания доклада команда обсуждает его и принимает решение, какие из представленных решений перспективны, какие надо отбросить, а какие оставить «про запас»;
   
5. 
   создание задачи на адаптацию решения. Если ни одно из выбранных решений нельзя применить в готовом виде, то PM создает задачу в Jira на адаптацию решения и закрепляет за сотрудником Data Science-отдела;
   
6. 
   создание списка адаптаций для решения. Сотрудник Data Science- отдела, получивший и выполнивший задание, создает список адаптаций и заводит его в Confluence;
   
7. 
   создание списка данных. После выбора варианта решения проектная команда собирается на совещание и создается список данных, необходимых для работы над проектом. Этот пункт также может выполнить сотрудник Data Science-отдела самостоятельно. Данный список создается отдельным документом в Confluence;
   
8. 
   обновление списка данных. Сотрудник Data Engineering-отдела распечатывает документ, созданный в п.7 и занимается сбором данных. На распечатанном документе создаются пометки о том, какие данные удалось собрать и в каком объеме;
   
9. 
   создание задачи на исследование данных. После успешного сбора данных PM создает задачу в Jira для начальника Data Science-отдела;
   
10. 
    создание пометок к списку данных. Начальник Data Science-отдела исследует данные и готовит документ с пометками к собранному списку данных. Данный документ создается в Confluence;
    
11. 
    создание задачи на подготовку данных. PM создает задачу в Jira для сотрудника Data Engineering-отдела на подготовку данных. Сотрудник Data Engineering-отдела получает задачу вместе с документом из п.10;
    
12. 
    создание списка «Features». После создания пометок к списку данных сотрудники Data Science-отдела проводят совещание с целью определения списка «Features». Данный список заводится в Confluence одним из сотрудников Data Science-отдела;
    
13. 
    создание задачи на подготовку наборов данных. После выполнения п. 12 PM создает задачу в Jira для сотрудников Data Engineering-отдела c с прикрепленным документом из п.12;
    
14. 
    создание списка параметров модели. После выполнения задачи, поставленной в п.12, сотрудники Data Science-отдела создают список параметров для текущей модели;
    
15. 
    проверка KPI. После создания и обучения модели с выбранными параметрами и выбранным списком «Features» сотрудники Data Science-отдела проверяют результаты обучения модели средствами Jupiter Notebook. После этого показатели текущего цикла не сохраняются в виде документа.
    

---

Как можно увидеть, проектный менеджер создает задачи с помощью Jira. Наибольшее количество информации, подлежащей документированию, производит работа отдела Data science.

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

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

Выполненное исследование организации управления в ООО «Мастер Маинд Инк» позволило сделать следующие наблюдения. Большинство

документации не имеет четкую структуру и создается на усмотрение исполнителя.

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

Документы, созданные вне Confluence, не всегда переносятся в Confluence;

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

---

Выводы к главе 2

Изучение методов управления проектами, принятых в компании ООО

«Мастер Маинд Инк», а также алгоритма R&D-деятельности позволили сделать следующие наблюдения и выводы:

Компания сталкивается с такими проблемами, как -

• 
  неполная документация.
  

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

• 
  неунифицированный формат.
  

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

• 
  слабая визуализация.
  

Дерево решений не визуализируется и нигде не сохраняется. Это может влиять на общее представление о

---

стадиях проекта, а также затрудняет проектному менеджеру задачу отчетности заказчикам о проделанной работе;

• 
  неполный учет времени.
  

Задачи повторяются от ветки к ветке, некоторые задачи являются незначительными (с точки зрения времени), проектная команда к компании небольшая и каждый знает свои обязанности, по этим причинам некоторые задачи могут не создаваться в инструменте управления проектами. Это затрудняет учет времени, так как в Jira будет храниться неполная информация о задачах. Также это может породить проблему «потери» некоторых задач.

Модель CRISP-DM является на данный момент единственной приемлемой для Data Science проектов, но она обладает определенными недостатками, которые влияют на процесс управления R&D этапом. К ним относят отсутствие средств поддержки.

Данная модель стала применяться недавно к подобного рода проектам. И сами Data Science проекты появились недавно. Поэтому существующие инструменты управления не успели еще адаптироваться под нужды Data Science-проектов, а новые не появились на рынке.

Отсутствие критерия времени. Модель не подразумевает учет времени или ограничение времени каждого цикла.

Глава 3 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ В КОМПАНИИ ООО «МАСТЕР МАИНД ИНК»

1. Модель автоматизированной системы управления проектами на предприятии ООО «МАСТЕР МАИНД ИНК»

Изучение способа организации управления проектами в компании ООО

«Мастер Маинд ИНК» показало, что на предприятии имеются существенные

---