Pull to refresh

Comments 5

Не понятно, зачем нейронная сеть. Ведь проект, в отличие от повторяемоего бизнес-процесса, является уникальной последовательностью с уникальным результатом. Для сбора статистики по рискам сеть тоже не нужна. Для принятия решения в случае возникновения риска не достаточно автомата?
Имитационное моделирование хода проекта с вероятностной генерацией рисков — это вобщем-то достаточно известное (из того же PMBoK) Монте-Карло. Но посыл, каким я его увидел, годный. По концепции правда есть некоторые пробелы.

Успешный результат (продукт) проекта как возникающий эффект есть функция управления и ресурсов. Если на вход подавать представление проекта как плана в виде задач, то риски следует описывать не в терминах отклонения интегральных показателей («по типу ущерб»), а влиянием только на конкретные объекты. Обычно управление рисками в том и заключается, что изменением состава объектов достигается их (рисков) исключение или уменьшения их влияния. Управление (и ходом проекта, и при планировании) — это по сути выбор лучшей альтернативы из доступных (реализуемых), лучшей по выбранному интегральному показателю.

Моя мысль также и в том, что на одних задачах (и даже рисках) успешный проект не всегда сделать. Поэтому зря вы не рассматриваете такой показатель как «процент готовности конечного результата» (он не совпадает с процентом выполнения проекта, так как — очень большие например проекты — могут реализовываться в 4 этапа, и в последнем только что-то делается материальное), и вообще, результат проекта как объект. В конечном итоге все перечисленные вами объекты проекта оказывают влияние именно на стоимость, срок поставки и качество конечного результата. Убирая эти показатели из моделирования, мы управляем только расходованием ресурсов.

Насчет целей (создания?) описанного в посте имитатора-симулятора. Я бы видел его целью не «тренировку ЛПР», а как раз аналитику при планировании, то есть получение оценки качества плана управления проектом. Руководитель проекта сделал план, посмотрел его качество, что-то улучшил глядя в результаты, и так далее, пока этот план всех не устроит. Вот с такими целями огород из Noce.js + Yii 2 + whatever имеет смысл.

И напоследок, по поводу нейронных сетей. В управлении обычно нет нужды находить какие-то творческие решения, управление (с точки зрения систем), это максимизация функционала (см. Уравение Беллмана). Вот нечеткой логикой какие-то критерии (успешности проекта и продукта например) задавать я смысл вижу.
2 prolis и S_A, Применение нейронных сетей даст возможность системе самостоятельно обучаться на множестве проектов, которые были реализованы/симулированы в системе. Таким образом отказываться от нечеткой логики или нейронных сетей я не вижу смысла, но их использование будет немного различным:
А. при отсутствии опыта у системы (маленькой базы архивов проектов) — можно опираться на нечеткую логику;
Б. при наличии ретроспективы — на нейронные сети.
Здесь важно отметить, что результат, и последовательность действий — действительно уникальны, но состоять они могут из типовых (микро) решений и ресурсов, в основе которых могут быть: типы выполняемых задач, участвующее оборудование, умения персонала, объемы и типы материальных ресурсов — общие между проектами.
Интеллектуализация заключается не в создании продукта — придумать, изобразить и т.п., но в поддержании необходимых ключевых условий для достижения цели: проследить за перегрузкой ресурсов, отставанием по срокам, не учтенным рискам, ошибкам в планировании (сроков и/или объемов работ), распределением ресурсов (в том числе и трудовых).
2 S_A, да действительно конечная цель именно в этом (предпоследний абзац) — реализация системы интеллектуальной поддержки, в том числе и с анализом успешности, качества. Однако, реализация такой задачи — слишком глобальна для меня, на данном этапе я сосредоточусь именно в этом направлении, но, конечно, буду учитывать, что может быть необходимо для расширения функционала в этом направлении.
Так же на счет реализации результата проекта, как материального объекта — упустил это из виду, обязательно подумаю, это может открыть интересные возможности.
Прочитал Ресурсная концепция в управлении проектами (у вас опечатка в заголовке), очень интересно, ведь в упомянутой книге этого открытым текстом нет, буду думать, как это реализовать и измерять.
Спасибо за комментарии!
S_A для выполнения прогнозирования выполнения проекта на самом деле столько всего и не нужно. В интеллектуальной сфере где задачи относительно схожие есть «скорость выполнения задач» и «скорость добавления задач» (XP, Agile) на основе которых можно делать прогнозы.

Если у проекта есть риски, то в план добить работы связанные с уменьшением риска или явно заложить буфер расписания и бюджета на известные риски. То есть тоже будет известная цифра для прогноза. А на совсем неизвестные события, где сработает неизвестный риск (Мерфи напомнит о себе) закладывается стандартный буфер критической цепи проекта (см CCPM, TOC)

Таким образом самая простая модель будет такая:

D = (( ((E + R)/ (Vi — Va) ) * Bs * Bb) / T) * W

D — расчетная календарная длительность
E — оцененный, наиболее вероятный объем проекта
Vi — скорость выполнения задач, сколько работы выполнено за календарное время
Va — скорость добавления задач, сколько добавили неизвестной работы за календарное время
R — известные риски, в оцененных чел/днях с учетом вероятности возникновения
Bs — буфер расписания 50% длительности
Bb — буфер бюджета, 50% оцененного объема
T — размер команды
W — пересчет рабочих дней в календарные, с учетом праздников

И её можно посчитать в Excel.

shtorman Касательно SaaS — уже есть, BiPulse использует схему моделирования для рекомендаций что делать руководителю проекта.

Это не я пытался задействовать всё что нужно когда не факт что нужно. Всё что вы написали я в курсе (и подобных моделей могу настругать пачку), а также в курсе что динамическое управление и Беллман в том числе для управления проектами всё же используется. Но! Не в ИТ :) BiPulse глянул. Платненькое решение, интерес не особо вызвало, волшбеного ничего не увидел.
Sign up to leave a comment.

Articles