Проект «Добротерра». Экстремальный режим

Всем добрый день.

Пожалуй, сегодняшняя статья – эта последняя статья, которую бы мне хотелось написать в отношении перспективного инвестиционного проекта «Добротерра». Я потратил достаточно много времени и сил для того, чтобы изучить данный проект, его сильные и слабые стороны, основываясь на имитационной статистической модели. Надеюсь, что результаты, которые я здесь приведу помогут не только вкладчикам, но и создателям проекта. (Не смотря ни на что, в проекте наступил скам 02.06.2016.)

Кому интересно изучить полную экспериментальную «историю» с проектом «Добротерра», вот ссылки на предыдущие статьи: ссылка №1, ссылка №2.

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

1) Когда в списке заявок на оплату все заявки не оплачиваются уже более 5 дней;

2) Когда начинает накапливаться большое количество желающих оплатить заявки, при этом этих самых заявок не хватает.

Это чисто моё видение, сформированное на почве экспериментов с моделью и, конечно, в полной мере оно может не отражать реальность.

Как теоретически можно решить эти проблемы?

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

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

Пришлось ввести в программу дополнительную функцию.

Что она делает?

Когда достигается некое критическое соотношение w=m/n между количеством «людей», желающих сделать новый вклад или реинвестировать (n), и количеством доступных заявок на оплату плюс количеством «работающих» депозитов (m), происходит генерация бонусных депозитов (в виде заявок на оплату) количеством (m) для некоторой случайной группы «людей» из всего списка «люде», желающих сделать новый вклад или реинвестировать.

Под каким «соусом» акций это можно «выдавать» в проекте – творческое дело администрации. Но это работает и решает проблему с нехваткой заявок.

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

Что делает эта функция? В момент времени, когда в топе подвисают заявки на срок более 5 дней, функция «принудительно» «оплачивает» их. Вот такой «некий» механизм «проталкивания» заявок оказался необходим. Как будут решать эту проблему администраторы проекта – также зависит от их творческой фантазии.

Я лишь могу сказать, что с течение времени подобные «заторы» заявок будут появляться все чаще, все в больших объёмах… И в конце концов это и приведет к остановке «сердца» проекта. Рано или поздно наступает ситуация, когда необходимо «протолкнуть» слишком много заявок… больше, чем есть в топе и в этот момент программа останавливает вычисления. Будет ли так по факту? Я не знаю.

При этом в топе зависают именно те заявки, которые максимальны по своему размеру. Сейчас это что-то около 300$. Статистически такая ситуация вполне объяснима. И даже если бы минимальный вклад ограничивался 100$, подвисали бы заявки именно на 100$. Кому будет интересно – обращайтесь, я объясню подробно почему это происходит.

А теперь немного про экстремальность…. В чем она состоит?

Я провел моделирование в очень «неприятной» для проекта ситуации, когда максимально возможное количество вкладчиков в день линейно и очень быстро падает и, примерно, через пару месяцев не превышает 5 человек в день (может быть случайное число 0, 1, 2, 3, 4 и 5, но не более). Я обещал сделать нечто подобное в прошлый раз.

Вот эта ситуация, отображенная на графике черным цветом, по изменению максимально допустимого количества вкладчиков в день с течением времени (данные по количеству вкладчиков нормированы от 0 до 1). dt4_max_mВначале резкий линейный спад и за тем некоторая стационарность. Красная прямая линия приведена как пример равномерного линейного спада максимально допустимого количества вкладчиков в день с течением времени. Наша «ситуация» – черная линия.

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

dt4_mРезкое падение среднего числа новых вкладчиков с течением времени примерно за два месяца и за тем стационарность… Исходная концепция «отрабатывает» верно.

И так, с одной стороны, у нас на «борту» модели есть две «антискамовых» функции, что я описал выше… с другой «неудачные» экстремально-экспериментальные обстоятельства в виде «притока» новых вкладчиков.

Что вы думаете? В такой «ипостаси» проект получается стабилен и надежен, несмотря ни на что.

Пример (лишь один из вариантов) графика «движения» депозитов в проекте (данные по количеству депозитов нормированы от 0 до 1). Количество депозитов в заданный момент времени случайно (локальная случайность), но возрастает в глобальном смысле по своему «размаху».

dt4_dНалицо нестационарная «раскачка» проекта. То появляются новые депозиты, то отработавшие выходят в виде заявок на оплату… И эта раскачка все больше по амплитуде… в конце не выдерживает «сердце»…

А вот пример графика из этого же «итерационного» «случая» по количеству заявок (данные по количеству заявок нормированы от 0 до 1).

dt4_r

Здесь виден глобальный закономерный трендовый рост, не смотря на то что процесс случаен. В один «прекрасный» момент заявок становится слишком много, и они подвисаю на срок более 5 дней…. Автоматика «не справляется»… ситуация не «разруливается»… Все. «Смерть».

В предыдущей статье я писал, что количество виртуальных «людей», зарегистрировавшихся в проекте хоть и случайно, но линейно растет. И мне это не нравилось…

Сейчас график несколько лучше.

dt4_mhЧерная линия на графике – это кривая роста количества участников в проекте. А красная линия приведена для примера, чтобы показать, что рост количества участников в проекте все же отличен от линейного.

После 1000 итераций моделирования работы проекта я получил такую эмпирическую функцию распределения вероятностей (ЭФРВ) по времени «жизни» проекта с «вечными» бонусами и «антискамовыми» функциями:

dt4_edf

Красивый, более-менее гладкий график. Ни каких искусственных «отсечек» при моделировании.

Некоторым тестовым «экземплярам» проекта удалось прожить очень долго… Но такие ситуации крайне маловероятны.

Ещё раз немного поясню график. По оси абсцисс отложено время «жизни» проекта. А по оси ординат вероятность события, что проект «проживет» менее заданного времени.

Пример. Нужно определить вероятность, с которой проект проживет менее 400 дней. Смотрим на графике по оси абсцисс цифру 400. Ищем точку пересечения с кривой. Там, где эта точка, по оси ординат, будет вероятность этого события. Она равна что-то около 0.6, ну, или около 60%. То есть вероятность события, что проект проживет менее 400 дней равна 60% или можно сказать наоборот. Вероятность того, что проект проживет более 400 дней равна 40%.

Программа позволяет определять вероятности подобных событий очень точно. Я сделал несколько вариантов для различных вероятностей. Кому что нравится. Выбираете.

  • Время работы программы: 36:13:19
  • Старт проекта: 2016-05-23
  • С вероятностью 90 % проект закроется позже указанной даты: 2016-12-30
  • С вероятностью 90 % проект ‘проживет’ больше указанного количества дней: 221
  • С вероятностью 80 % проект закроется позже указанной даты: 2017-02-10
  • С вероятностью 80 % проект ‘проживет’ больше указанного количества дней: 263
  • С вероятностью 70 % проект закроется позже указанной даты: 2017-03-12
  • С вероятностью 70 % проект ‘проживет’ больше указанного количества дней: 293
  • С вероятностью 60 % проект закроется позже указанной даты: 2017-04-13
  • С вероятностью 60 % проект ‘проживет’ больше указанного количества дней: 325
  • Максимальная рассчитанная дата закрытия проекта: 2020-01-27 (крайне маловероятна)
  • Максимальное рассчитанное время жизни проекта: 1344 (крайне маловероятна)

Вот примерно получается такая штука получается.

И ещё в дополнение диаграмма частот по времени жизни проекта.

dt4_h

Здесь все просто. Самый высокий «столб» – это наиболее вероятное время «жизни» проекта. Самый низкий – наименее вероятное. Получается столбец на интервале от 200-300 самый высокий. То есть наиболее вероятно, что проект «проживет» 200-300 дней. Более точные данные даёт ЭФРВ. А это так, для «грубой» прикидки.

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

Хотелось бы сказать ещё пару слов в адрес администраторов новых проектов.

Если Вы думаете оценивать свое детище имитационно-статистическими методами на этапе создания, то, во-первых, желательно это делать заранее, за 2-3 недели до старта проекта, чтобы выявить все потенциально «сложные» ситуации и заблаговременно предусмотреть в проекте механизмы по их нивелированию. Во-вторых, ежедневная статистика по притоку новых вкладчиков в проект и по размерам сделанных ими вкладов могла значительно повысить точность моделирования. Мне не нужны здесь абсолютные цифры. Достаточно относительных. Здесь меня интересует только ЭФРВ, которую я получу сам.

На этом у меня все.
dobroterra.com

Похожие статьи:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *