Софтинка-прототипчик-УПП.

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

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

Пока дальнейшую судьбу этой софтины не знаю. Развивать - не уверен, что буду. Но идею реализовал, делюсь.

Скачать можно здесь (7 Мб): http://www.fayloobmennik.net/1580538

Уже больше года в голове болталась идея, изначально пытался сделать её веб-сервисом, под Google App Engine, даже сделал первую половину (квадратики), но потом оказалось что GAE стал очень платный, и я это дело отложил... ну вот реализовал не в вебе, но тем не менее.

Интересная программа :)
Андрей, а что на странице Profile? Снизу в подписи результаты для всего портфеля?

Для всего портфеля, да. На странице Profile - графики фин. рез. (зеленый) и трудозатрат (синий). Хотел было сделать красивые графики, но с этим проблемы выплыли некоторые, так что не сделал. Впрочем, "профиль" видно, и это главное.

Андрей, мне интересно, но я не понял. Пожалуйста, поясните

Идея в следующем: портфель (чего угодно - работ, проектов, программ, подпортфелей) состоит из компонент.
Взаимосвязанные компоненты показываются как roadmap.
Связь между компонентами проставляется, если они в одной группе, и наборы сценариев в компонентах пересекаются.
Группа - независимые наборы компонент.
Для каждой компоненты проставляются доходы, расходы, длительность (в месяцах написано, но ничто не мешает понимать под этим годы), месяц начала, а также в какие сценарии входит эта компонента, а также группа, в которую входит компонента.

На выходе (вкладка profile) рисуется фин. рез. портфеля по месяцам, трудозатраты суммарные, а также совокупные показатели портфеля - ROI, фин. рез., и вероятность убытков (на основе сценариев). Для сценариев зашиты жестко вероятности 1/6, 4/6, 1/6.

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

Если проставлять все три галочки сценариев, то будет считаться что их как-будто нет. Если не проставлять галки для компоненты вообще - она не будет участвовать в расчете.

Другой пример. Один проект, две стадии, но три сценария. Тогда будет 6 компонент (все в одной группе). 2 компоненты - позитивный сценарии (на две стадии), 2 стадии-компоненты - нейтральный сценарий, и 2 - негативный сценарий.

Что настораживает - слишком простой пример:
1) Должна получиться сеть, а ее нет
2) Не увидел тип связи между проектами

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

Цитата:

---

Сообщение от Andruxa

Нарисованные связи - всего лишь для наглядности, что за чем по времени.

---

Да, а еще если менять сценарий на одном компоненте, связь начинается с компонентом с таким-же сценарием

Весь мой опыт показывает, что в объемных программах мероприятий (т.е. портфелях) проекты образуют сеть с множеством вариантов. Если сети нет-значит или ограничение метода, или есть метод, обходящий это ограничение (например, включать в портфель только проекты, не образующие сеть, а потом объединить их каким-нибудь мультипортфелем)
Из примера я понял (может неправильно):
1) Множества (А...С) и (Е...F) между собой никак не связаны
2) А-В-С и E-F связанные и выполняются только в указанной последовательности
3) Связь внутри множеств только "конец-начало"
Согласитесь, в ходе проекта все графики "плывут" и подлежат оптимизации. Потому посчитанный профиль также должен строиться с учетом динамики, плыть вместе с проектами. Не мне Вам рассказывать, как эти задачи решаются толстыми РМ системами. Так понимаю, Вы хотите срезать угол? :)

Цитата:

---

Сообщение от Михаил_Шустер

Весь мой опыт показывает, что в объемных программах мероприятий (т.е. портфелях) проекты образуют сеть с множеством вариантов. Если сети нет-значит или ограничение метода, или есть метод, обходящий это ограничение (например, включать в портфель только проекты, не образующие сеть, а потом объединить их каким-нибудь мультипортфелем)
Из примера я понял (может неправильно):
1) Множества (А...С) и (Е...F) между собой никак не связаны
2) А-В-С и E-F связанные и выполняются только в указанной последовательности
3) Связь внутри множеств только "конец-начало"

---

Правильно поняли пример, только связь не конец-начало даже, а что позже начинается, то связано с тем, что раньше начинается (если пересекаются сценарии и группы).

Что касается сети, то взаимосвязи я понял какие имеются ввиду. Нет, такие взаимосвязи я не учитывал, это не диаграмма Гантта, хотя может и жаль.

Цитата:

---

Согласитесь, в ходе проекта все графики "плывут" и подлежат оптимизации. Потому посчитанный профиль также должен строиться с учетом динамики, плыть вместе с проектами. Не мне Вам рассказывать, как эти задачи решаются толстыми РМ системами. Так понимаю, Вы хотите срезать угол? :)

---

Ну, план-факт я не рассматривал. И уж тем более оптимизацию - не потому что это сложно, а потому что я делал простенький прототип, потратив на него 20 часов. И да, сдвигая одну компоненту по времени, другие не сдвигаются, что означает, что связей в привычном понимании - нет. Я не стал это рассматривать не только потому, что это надо закодировать - не столь сложно (даже проще, чем автоматически что-то рисовать), сколько нужно вводить зависимости.

Для меня интерес при разработке этой штуки представляли следующие вещи:
1. Чтобы весь интерфейс был графическим,
2. Чтобы характеристики портфеля доставались наиболее простым способом - то есть ввёл, посмотрел, поменял, посмотрел ну и так далее.

То, что Вы, Михаил, описываете, надо строить диаграммой Гантта. Вот её-то мне и не хотелось делать :) Таким образом угол я срезал, да. Но не в ущерб смыслу экономическому, а скорее удобству изменения роадмапа.

Хотя защищать свою наглядность не буду со связями. Прибивание связей между компонентами по типу конец-начало и сдвигание - хорошая идея. Только это не будет отображаться наглядно на моей диаграмме - она не совсем time-line.

А, вот и нашел первую багу. Трудозатраты складываются независимо от сценариев. Это поправлю сегодня вечером... хотя... ими ведь можно и не пользоваться... :) ...хотя поправлю.

Цитата:

---

Сообщение от Andruxa

делал простенький прототип, потратив на него 20 часов

---

Это Вы руками 20 часов работали, а головой-то гораздо больше. Раз год назад было задумано :)
Андрей, а можно сформулировать область применения? Как в формуле изобретения: ...для..., отличающаяся тем, что... Мне тема интересна (вообще не собирался здесь появляться), внедряюсь в ааагромной отраслевой программе, где управление последовательностью проектов ведется совершенно как Бог на душу положит. Правда, ROI там вообще не катит, но это другой вопрос. Придумал несколько безумных профилей и бросил

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

Так скажем, уже приведенное изделие - показывает, что порядок имеет влияние на "профиль" этого самого фин. реза.

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

Цитата:

---

Сообщение от Andruxa

за исключением пожалуй, чрезмерно для моих интересов мощного Спайдера.

---

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

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

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

На мой взгляд, для получения суммарного фин. реза, фин. реза по месяцам, ROI, и вероятности убытков - достаточно вводимых данных (доходы, расходы, какие сценарии, длительность, старт).

Новая версия - http://www.fayloobmennik.net/1586460 - с трудозатратами и поэтессами. Обновлен пример! :)

Старую версию удалил.

Цитата:

---

то есть, ограничения на входные данные, определяющие выход

---

кстати не сказал. Если длительность больше одного периода, то заданные income, costs, labour делятся равномерно на весь промежуток.

Всё, прикрутил графики получше, размер сразу раздулся до 24 Мб, но это я думаю не проблема ведь, да? :)

Предыдущую версию удалять не буду, сервис сам удалит за 30 дней.

http://www.fayloobmennik.net/1592934
Теперь юзабельно.

На том пожалуй и завершу доработки.

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

https://github.com/AndruxaSazonov/Components
Там можно найти код и версии 0.2 и версии 0.3.

Enjoy!

Если кто отрефакторит, добавит панель с табличными данными - скажу спасибо.