Файл: Исследование методов и средств моделирования систем управления проектами на предприятии.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.10.2023
Просмотров: 415
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Глава 1 АНАЛИЗ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ
Модели жизненных циклов проектов и методы управления проектами
Анализ инструментов управления проектами
Организация процесса исследовательской деятельности на предприятии ООО «Мастер Маинд Инк»
Модель системы управления проектами «As Is»
общем виде представлена на рисунке 2.4.
Рисунок 2.4 - Общая организационная структура предприятия ООО «Мастер Маинд Инк»
Рассмотрим, как происходит создание программного продукта в компании с точки зрения разделения труда.
Анализ организации процесса разработки проектов в компании ООО «Мастер Маинд Инк» на этапе R&D показал, что она имеет сложную нелинейную структуру (рис. 2.5).
Рисунок 2.5 - Модель бизнес-процессов этапа R&D на предприятии ООО «Мастер Маинд Инк»
Представленная модель бизнес-процессов отражает развертывание процесса разработки продукта во времени и распределение работ между исполнителями, а также связи между ними.
Рисунок 2.5 представляет собой следующий уровень декомпозиции блок- схем алгоритма R&D, выполненных на рисунках 2.2 и 2.3. Поскольку более
подробная детализация усложняет схему исследовательской деятельности, выделение четких этапов (как это было сделано в рисунке 2.2), становится весьма затруднительным, так как реальный, физический процесс создания программного продукта является нелинейным, ситуативным, а его подпроцессы могут быть параллельны или пересекаться.
Процесс создания и обучения нейросети распределен между тремя участвующими сторонами: Product Owner (лицо, принимающее решение со стороны заказчика), специалисты по Data Science и инженеры по данным (Data
Engineer). Как уже отмечалось, бывают случаи, когда исполнители меняются ролями и временно принимают на себя обязанности другого члена команды.
Проследим организационные связи между отделами и сотрудника на предприятии ООО «Мастер Маинд Инк» на каждом этапе алгоритма R&D.
Как было ранее показано на рисунке 2.3, R&D-деятельности предшествует анализ предметной области. Результатами этого анализа должны быть:
Предварительная ориентировочная деятельность в проектах с ИИ имеет значение большее, чем в любых других видах проектов. На этой стадии происходит формулирование критериев, которым в дальнейшем будет соответствовать готовый продукт.
Реализация любого проекта всегда начинается с формулирования потребности заказчика/рынка в нем. Product Owner должен иметь представление о том, как этот продукт или его новая функция должны работать в конечном итоге. Например, внедрение некоторого сервиса предотвратит отток посетителей или простимулирует продажи других продуктов.
Формулировка такой потребности не претендует на полное описание проекта, она только обозначает проблему: «наши клиенты должны понять, как они распоряжаются своим бюджетом», «если мы добавим функцию предсказания часа пик в аэропорту, то клиенты
охотнее будут покупать приложение».
Здесь необходимо изложить цели продукта, на основании которых формируются бизнес-требования, т.е. набор той функциональности, которая определяет назначение ПО.
На этом этапе все участники проекта предлагают идеи, которые можно использовать при решении сформулированной проблемы, происходит создание некоторых первоначальных набросков возможного решения. Этим этапом обычно руководит специалист Data Science, но важно, чтобы принимали участие абсолютно все участники работы на проекте, включая менеджмент, так как возможные решения и продуктивные идеи могут лежат в совершенно различных областях знаний.
В результате этого этапа обычно становится ясно, насколько глубоким будет процесс исследования данных.
Затем следует определение количественных показателей, которыми будет определяться, достигнуто ли бизнес-требование. Этот этап заключается в совместном определении объема и ключевых показателей эффективности проекта (KPI). Затем эти KPI должны уточнены и переведены в измеримые. Возможно, удастся получить очень четкие показатели, такие как
«прогнозирование ожидаемого CTR объявления с приближением не менее X% впо меньшей мере Y% случаев, для любого объявления, показанного не менеенедели, и для любого клиента с более чем двумя месяцами временных данных» . Однако в некоторых случаях необходимо использовать качественные показатели, например, «время,необходимоедляизучениятемысиспользованиемсгенерированныхрасширенных
запросов,будетсокращенои/или улучшитсякачество результатов посравнениюс исходнымизапросами».
Это особенно верно, когда модель предназначена для оказания помощи человеку в какой-то сложной его деятельности.
Ключевые показатели могут быть уточнены в связи с имеющимися временными рамками и ресурсами. Для их уточнения нужен дальнейший сбор данных.
Обычно эти метрики (KPI) определяются проектной командой совместно с Product Owner в точных количественных показателях. Но в зависимости от ресурсов и временных ограничений они могут быть подвергнуты пересмотру после консультаций с заказчиком. Поскольку любая обратная связь означает дополнительный расход времени, то проектная команда может попытаться найти дополнительные жесткие метрики, на которые можно опереться для продолжения работы над продуктом, и избежать дополнительных консультаций с заказчиком.
Определение объема работ на этом этапе особенно важно, поскольку исследовательские проекты имеют тенденцию удлиняться и естественным образом увеличиваться в размерах и масштабах по мере появления новых возможностей при проведении исследований.
Процесс определения значений KPI, является, таким образом, итерационным. Он завершается тогда, когда найденные значения удовлетворят клиента. Здесь был замечен следующий факт, отражающий некоторый конфликт бизнес-интересов заказчика и тех возможностей программного продукта, как их оценивает проектная команда. Бизнес всегда стремится иметь максимальные показатели KPI. Разработчики утверждают, что программный продукт объективно не в
состоянии (как любая модель) отразить реальную ситуацию (в предметной области) на 100%. Например, если система предсказывает поведение покупателей с точностью, меньше 95%, то такая система, по мнению большинства заказчиков, является бесполезной.
Однако во многих случаях тщательный анализ и обсуждение предположений о продукте могут привести к появлению очень ценных
решений, которые могут оказаться не такими технически сложными, как казалось на первой итерации выработки KPI.
Определить объем работ на данном этапе также является важным с психологической точки зрения. Исследователь, который начинает изучать полученную задачу, стремится изучить как можно большее количество статей и книг. Поэтому отсутствие четко очерченных границ времени, ресурсов и целей проекта может привести к долгим неделям или месяцам, потраченным на разработку прекрасных моделей, которые в конечном итоге не отвечают реальной потребности, или приводят к неучету некоторых KPI, которые могли быть определены ранее.
Анализ решения (обозначен сиреневым цветом на рисунках 2.2, 2.3 и 2.5).
На данном этапе перед проектной командой стоят задачи изучения литературы и существующих готовых решений.
Исследователь анализирует как академическую литературу, так и существующие программные решения и инструменты.
Глубина погружения в литературу зависит от особенностей проекта: является ли он фундаментальным, определяющим дальнейшую
Рисунок 2.4 - Общая организационная структура предприятия ООО «Мастер Маинд Инк»
Рассмотрим, как происходит создание программного продукта в компании с точки зрения разделения труда.
Анализ организации процесса разработки проектов в компании ООО «Мастер Маинд Инк» на этапе R&D показал, что она имеет сложную нелинейную структуру (рис. 2.5).
Рисунок 2.5 - Модель бизнес-процессов этапа R&D на предприятии ООО «Мастер Маинд Инк»
Представленная модель бизнес-процессов отражает развертывание процесса разработки продукта во времени и распределение работ между исполнителями, а также связи между ними.
Рисунок 2.5 представляет собой следующий уровень декомпозиции блок- схем алгоритма R&D, выполненных на рисунках 2.2 и 2.3. Поскольку более
подробная детализация усложняет схему исследовательской деятельности, выделение четких этапов (как это было сделано в рисунке 2.2), становится весьма затруднительным, так как реальный, физический процесс создания программного продукта является нелинейным, ситуативным, а его подпроцессы могут быть параллельны или пересекаться.
Процесс создания и обучения нейросети распределен между тремя участвующими сторонами: Product Owner (лицо, принимающее решение со стороны заказчика), специалисты по Data Science и инженеры по данным (Data
Engineer). Как уже отмечалось, бывают случаи, когда исполнители меняются ролями и временно принимают на себя обязанности другого члена команды.
Проследим организационные связи между отделами и сотрудника на предприятии ООО «Мастер Маинд Инк» на каждом этапе алгоритма R&D.
Как было ранее показано на рисунке 2.3, R&D-деятельности предшествует анализ предметной области. Результатами этого анализа должны быть:
-
определение цели продукта; -
определение бизнес-требований; -
определение KPI для каждого бизнес-требования; -
определение возможных способов удовлетворения бизнес-требований, а именно: определение проектной командой стратегии решения каждого бизнес-требования - с помощью построения ИИ или алгоритмических методов.
Предварительная ориентировочная деятельность в проектах с ИИ имеет значение большее, чем в любых других видах проектов. На этой стадии происходит формулирование критериев, которым в дальнейшем будет соответствовать готовый продукт.
Реализация любого проекта всегда начинается с формулирования потребности заказчика/рынка в нем. Product Owner должен иметь представление о том, как этот продукт или его новая функция должны работать в конечном итоге. Например, внедрение некоторого сервиса предотвратит отток посетителей или простимулирует продажи других продуктов.
Формулировка такой потребности не претендует на полное описание проекта, она только обозначает проблему: «наши клиенты должны понять, как они распоряжаются своим бюджетом», «если мы добавим функцию предсказания часа пик в аэропорту, то клиенты
охотнее будут покупать приложение».
Здесь необходимо изложить цели продукта, на основании которых формируются бизнес-требования, т.е. набор той функциональности, которая определяет назначение ПО.
На этом этапе все участники проекта предлагают идеи, которые можно использовать при решении сформулированной проблемы, происходит создание некоторых первоначальных набросков возможного решения. Этим этапом обычно руководит специалист Data Science, но важно, чтобы принимали участие абсолютно все участники работы на проекте, включая менеджмент, так как возможные решения и продуктивные идеи могут лежат в совершенно различных областях знаний.
В результате этого этапа обычно становится ясно, насколько глубоким будет процесс исследования данных.
Затем следует определение количественных показателей, которыми будет определяться, достигнуто ли бизнес-требование. Этот этап заключается в совместном определении объема и ключевых показателей эффективности проекта (KPI). Затем эти KPI должны уточнены и переведены в измеримые. Возможно, удастся получить очень четкие показатели, такие как
«прогнозирование ожидаемого CTR объявления с приближением не менее X% впо меньшей мере Y% случаев, для любого объявления, показанного не менеенедели, и для любого клиента с более чем двумя месяцами временных данных» . Однако в некоторых случаях необходимо использовать качественные показатели, например, «время,необходимоедляизучениятемысиспользованиемсгенерированныхрасширенных
запросов,будетсокращенои/или улучшитсякачество результатов посравнениюс исходнымизапросами».
Это особенно верно, когда модель предназначена для оказания помощи человеку в какой-то сложной его деятельности.
Ключевые показатели могут быть уточнены в связи с имеющимися временными рамками и ресурсами. Для их уточнения нужен дальнейший сбор данных.
Обычно эти метрики (KPI) определяются проектной командой совместно с Product Owner в точных количественных показателях. Но в зависимости от ресурсов и временных ограничений они могут быть подвергнуты пересмотру после консультаций с заказчиком. Поскольку любая обратная связь означает дополнительный расход времени, то проектная команда может попытаться найти дополнительные жесткие метрики, на которые можно опереться для продолжения работы над продуктом, и избежать дополнительных консультаций с заказчиком.
Определение объема работ на этом этапе особенно важно, поскольку исследовательские проекты имеют тенденцию удлиняться и естественным образом увеличиваться в размерах и масштабах по мере появления новых возможностей при проведении исследований.
Процесс определения значений KPI, является, таким образом, итерационным. Он завершается тогда, когда найденные значения удовлетворят клиента. Здесь был замечен следующий факт, отражающий некоторый конфликт бизнес-интересов заказчика и тех возможностей программного продукта, как их оценивает проектная команда. Бизнес всегда стремится иметь максимальные показатели KPI. Разработчики утверждают, что программный продукт объективно не в
состоянии (как любая модель) отразить реальную ситуацию (в предметной области) на 100%. Например, если система предсказывает поведение покупателей с точностью, меньше 95%, то такая система, по мнению большинства заказчиков, является бесполезной.
Однако во многих случаях тщательный анализ и обсуждение предположений о продукте могут привести к появлению очень ценных
решений, которые могут оказаться не такими технически сложными, как казалось на первой итерации выработки KPI.
Определить объем работ на данном этапе также является важным с психологической точки зрения. Исследователь, который начинает изучать полученную задачу, стремится изучить как можно большее количество статей и книг. Поэтому отсутствие четко очерченных границ времени, ресурсов и целей проекта может привести к долгим неделям или месяцам, потраченным на разработку прекрасных моделей, которые в конечном итоге не отвечают реальной потребности, или приводят к неучету некоторых KPI, которые могли быть определены ранее.
Анализ решения (обозначен сиреневым цветом на рисунках 2.2, 2.3 и 2.5).
На данном этапе перед проектной командой стоят задачи изучения литературы и существующих готовых решений.
Исследователь анализирует как академическую литературу, так и существующие программные решения и инструменты.
Глубина погружения в литературу зависит от особенностей проекта: является ли он фундаментальным, определяющим дальнейшую