Разработка ПО

Здесь я приведу свои домыслы по поводу

Simulation. Пользователь сервиса

Самое главное чтобы понимать пользователя сервиса - это понять какую задачу/проблему решает пользователь с помощью сервиса.
Пользователь интернет сервиса обладает некоторыми свойствами и функциями.
Какими?
Как он узнаёт о сервисе? Как он передает данные о сервисе? Какие параметры нужно учитывать?
Нас интересует единственный целевой параметр - количество пользователей сервиса.

Жизненный цикл пользователя сервиса:

1. Ничего не знает
2. Знает, но не пользуется
3. Пользуется редко
• Расскажет другим как бы между делом
4. Понимает, что это полезно
• Рассказывает другим
5. Пользуется часто
• Уже всем своим знакомым рассказал
6. Пользуется часто и не может не пользоваться
• Не рассказывает друзьям

Пользователь как правило может переходить из одного состояние в соседнее, то есть на 1 вверх или на 1 вниз, но не изменяется на 2 и больше. Смерть (не дай Бог) может вернуть из любого состояния в состояние 1. Его мы не будет рассматривать.
Итак, я бы выделил несколько характеристик пользователя:

• Возраст
• Кол-во часов, находящихся в интернете в среднем каждый день
• Кол-во друзей в соцсетях
• Любопытство
• Функциональность сервиса
• Наличие конкурентов с подобной функциональностью
• Чувство уважения, которое испытывает пользователь со стороны владельца ресурса
• Изменчивость сервиса
• Частая
• Редкая
• Стоимость
• Привычка
• Реклама в сервисе
• Чувство необходимости

1to2.Как распространяется информация о том, что появился сервис? 

• Реклама
• Поисковик
• Google
• Yandex
• Yandex Market
• Mail.Ru
• Yandex Direct
• Радио
• ТВ
• Сарафанное радио
• Сказал между делом онлайн/офлайн
• Социальные сети
• Сказал в оффлайне

2to1. Как забывается информация?

• Забывается информация в силу того, что не пользуется. Человек склонен к очистке памяти, потому что человеческий мозг оптимизирует деятельность.

2to3. Что заставляет пользователей начинать пользоваться сервисом?

• Кто-то сказал
• Где-то услышал / увидел
• Кто-то сказал из разных источников может быть независимых (по его мнению)
• Наличие свободного времени
• Любопытство (которое ослабевает с возрастом)

И так далее.
Необходимо нарисовать таблицу 6х6.

	1	2	3	4	5	6
1		2to1
2	1to2		3to2 3to2new	4to2new
3		2to3		4to3
4			3to4		5to4
5				4to5		6to5
6					5to6

И каждый из 10 случаев необходимо расписать. У каждого пользователя так и происходит. По крайней мере для моделирования исходим из этого. Различие заключается лишь в параметрах.

Для моделирования параметры можно варьировать случайным образом согласно какому-то распределению (часто умозрительному)

Каждый переход мы должны запрограммировать. А также запрограммировать создание новых пользователей на основе того, что плохого не посоветует. Если пользователю не нравится, то он как правило промолчит. Если пользователь находится на стадии 4, то рассказывает всем подряд какой сервис хороший. То есть надо расписать еще состояние 4to2new и 3to2new.

Вот такой агрегат необходимо запрограммировать и посмотреть как ведет себя система.

Аналитически эту систему описать и решить очень сложно. Вот поэтому и прибегают к имитационному моделированию. То есть рассматривают модель как много мелких независимых объектов с приблизительно одинаковыми алгоритмами. Алгоритмы программируются и могут (а в ИТ должны) быть случайными.

В дальнейшем рассмотрим проектную деятельность.

Simulation. Что это такое?

Итак, что такое Simulation? Я выделяю несколько аспектов:

• Моделирование элементов на микроуровне
• Свойства элементов:
• Могут создаваться как объекты какого-то класса в ООП
• Типы элементов могут различаться
• Их должно быть достаточно много
• Элементы относительно независимы
• Изменение элементов может быть стохастическим. То есть некоторые параметры могут рассматриваться как случайные величины с некоторым распределением
• Элементы двигаются согласно каким-то правилам
• Элементы для наглядности визуализируются и изменяются во времени
• Элементы сохраняют в себе некоторые параметры, то есть имеют память
• Элементы имеют алгоритмы взаимодействия с другими объектами в зависимости от типов
• На модели можно влиять через параметры.
• На модели можно влиять через ограничения.
• На модели можно влиять через алгоритмы взаимодействия
• Модели должны давать некоторые интересующие нас параметры. Эти параметры для наглядности должны откладываться по оси времени.
• Модель - всего лишь модель, которая может предсказывать дальнейший ход событий.
• Модели должны иметь обратную связь.
• По моделям можно определить достаточно устойчивую статистику.

Возможно, этот список неполон, но от этого можно отталкиваться.

Имитационное Моделирование

К имитационному моделированию прибегают, когда:

• дорого или невозможно экспериментировать на реальном объекте;
• невозможно построить аналитическую модель: в системе есть время, причинные связи, последствие, нелинейности, стохастические (случайные) переменные;
• необходимо сымитировать поведение системы во времени.

Цель имитационного моделирования состоит в воспроизведении поведения исследуемой системы на основе результатов анализа наиболее существенных взаимосвязей между её элементами или другими словами — разработке симулятора (англ. simulation modeling) исследуемой предметной области для проведения различных экспериментов.

В классификации 

• Агентное
• Дискретно-событийное
• Системная динамика

Имитационное Моделирование я рассматриваю как первые два.

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

Simulation. Balls

Есть очень простая задача. Понять что такое Имитационное Моделирование.

Я тут на скорую руку создал простой проект на Delphi7, который мне дал некоторое представление что же такое Simulation Modeling, то есть Имитационное Моделирование.

Вот так выглядит реализация проекта

Создан тип TBall

type TBall = class

  private

  public

    shape: TShape;

    WinControl: Twincontrol;

    balls: TList;

    id: string;

    x, y, d, vx, vy, ax, ay: integer;

    l: TLabel;

    constructor Create(balls0: TList; WC0: TWinControl; x0, y0, d0: integer; color0: TColor);

    procedure Move(dx, dy: integer);

    procedure Edge();

    procedure Intersection(x0, y0: integer);

  end;

implementation

constructor TBall.Create(balls0: TList; WC0: TWinControl; x0, y0, d0: integer; color0: TColor);

begin

  balls:=balls0;

  shape:=TShape.Create(WC0);

  WinControl:=WC0;

  shape.Left:=x0;

  shape.Top:=y0;

  shape.Shape:=stCircle;

//  shape.Shape:=stRectangle;

  shape.Height:=d0;

  shape.Width:=d0;

  shape.Brush.Color:=color0;

  shape.Parent:=WC0;

  x:=x0;

  y:=y0;

  d:=d0;

  l:=TLabel.Create(WC0);

  l.Parent:=WC0;

end;

procedure TBall.Edge();

begin

  if x>Wincontrol.Width-d-0 then x:=Wincontrol.Width-d-0;

  if x<0 nbsp="" then="" x:="0;</p">

  if y>WinControl.Height-d-0 then y:=WinControl.Height-d-0;

  if y<0 nbsp="" then="" y:="0;</p">

end;

procedure TBall.Intersection(x0,y0: integer);

var i: integer;

begin

  for i:=0 to balls.Count-1 do begin

    if balls[i]<>self then begin

      if (x

         (x+d>TBall(balls[i]).x)and(y+d>TBall(balls[i]).y) then begin

        x:=x0;

        y:=y0;

      end;

    end;

  end;

end;

procedure TBall.Move(dx, dy: integer);

begin

  x:=x+dx;

  y:=y+dy;

  Edge;

  Intersection(x-dx, y-dy);

  shape.Left:=x;

  shape.Top:=y;

  if l<>nil then begin

    l.Caption:=' '+id+' ';//IntToStr(x)+' '+IntToStr(y);

    l.Left:=x+Trunc(d/2)-Trunc(l.Width/2);

    l.Top:=y+Trunc(d/2)-Trunc(l.Height/2);

  end;

end;

Форма TForm называется Main. Содержит панель Panel1 на весь экран, и таймер TTimer1.

Вот код:

procedure TMain.FormCreate(Sender: TObject);

var b: TBall;

begin

  Width:=266;

  Height:=238;

//  Caption:=IntTostr(Panel1.Width)+' '+IntTostr(Panel1.Height);

  balls:=TList.Create;

  b:=TBall.Create(balls, Panel1, 0, 0, 40, clGreen);

  b.id:='1';

  balls.Add(b);

  b:=TBall.Create(balls, Panel1, 50, 50, 40, clGray);

  b.id:='2';

  balls.Add(b);

  b:=TBall.Create(balls, Panel1, 100, 100, 40, clFuchsia);

  b.id:='3';

  balls.Add(b);

  b:=TBall.Create(balls, Panel1, 150, 150, 40, clYellow);

  b.id:='4';

  balls.Add(b);

  b:=TBall.Create(balls, Panel1, 200, 200, 40, clRed);

  b.id:='5';

  balls.Add(b);

  b:=TBall.Create(balls, Panel1, 0, 300, 40, clBlue);

  b.id:='6';

  balls.Add(b);

end;

procedure TMain.Timer1Timer(Sender: TObject);

var i: integer;

    dx, dy: integer;

begin

  for i:=0 to balls.Count-1 do begin

    dx:=(Random(3)-1)*5;

    dy:=(Random(3)-1)*5;

    TBall(balls[i]).Move(dx, dy);

  end;

end;

Разберем тип TBall. Он должен содержать конструктор с начальными параметрами, такими как координаты, скорость и ускорение, если будем учитывать кинетическое движение шарика. Объект может быть вовсе не шарик, а, допустим, квадратик. Шарик просто красивее.

Шарики в данном случае создаются при создании формы. Шарики могут создаваться не только при создании формы, но и при каком-то условии, например, при ударении шарика верхней границы. Шарики двигаются в рамках каких-то условий, например, границ прямоугольника. За это отвечает процедура Edge.Также шарики должны знать друг о друге. За это отвечает переменная balls списка TList. Для чего нужно знать про другие шарики? Чтобы они не наезжали друг на друга. За это отвечает процедура Intersection. Также процедура Move отвечает за движение в рамках этих ограничений влево и вправо. Движение влево и вправо генерируется случайно (-5, 0, 5 c равными вероятностяи) и навешивается на таймер для всех шариков.

Что это дает? Понимание как можно и нужно создавать имитационные модели.

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

Модели должны иметь регулярную обратную связь.

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

Короче, такой подход вполне применим для Имитационных Моделей в ИТ, а также в смежных областях. Чем я и собираюсь заниматься.

Что такое ресурсы

В этой статье я попытаюсь понять что такое ресурсы с точки зрения заказчика и исполнителя.
Надо понимать, что ресурсы не существуют сами по себе. Они необходимы для решения какой-то конкретной задачи. Задача может быть сформулирована в терминах достижения содержания с нужным качеством за какие-то ресурсы. Задача может быть оформлена как проект, то есть задача должна быть уникальна. Что такое ресурсы в данном случае?

PMBoK рассматривает 9 условных областей (доменов):

• Управление интеграцией проекта
• Управление содержанием проекта

• Управление сроками проекта

• Управление стоимостью проекта

• Управление качеством проекта

• Управление человеческими ресурсами проекта

• Управление коммуникациями проекта

• Управление рисками проекта

• Управление поставками проекта

• Управление заинтересованными лицами

На самом деле это деление весьма условное и, на мой взгляд, не полное. Например, здесь нет области Управления Изменениями. Это важно, потому что особенно в области ИТ постановки много раз могут изменяться. И это для ИТ нормально. Еще одна не совсем правильная на мой взгляд штука: эти домены должны быть сгруппированы. Например,вот так:

Содержание

• Управление содержанием
• Управление качеством
• Управление заинтересованными лицами
• Управление изменениями

Ресурсы

• Управление стоимостью
• Управление сроками
• Управление человеческими ресурсами
• Управление интеграцией (руководство)
• Управление коммуникациями (информацией)
• Управление лояльностью (сотрудников)
• Управление компетенцией (сотрудников)
• Управление карьерным ростом и др.
• Административные ресурсы
• Управление поставками
• Управление полномочиями и др.
• Технические ресурсы
• Риски
• Управление рисками

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

На другой чаше весов находятся ресурсы, которые необходимы для достижения необходимого содержания. Так что же такое ресурсы?
Я бы их разделил на 6 типов:

• Время
• Денежные (стоимость)
• Человеческие
• Технические
• Административные
• Риски

Как их лучше всего представить? Аналитики-публицисты любят представлять в виде диаграммы. Первые 5 ресурсов размещаем по кругу. В центре размещаем ресурс Риск. Он влияет на все остальные.

Время

Время - самый простой в администрировании ресурс. Он только уменьшается. Если человек не успевает что-то сделать за 8 часов рабочего дня, то может за счет собственных ресурсов работать и больше, чем 40 часов в неделю. Допустим, может работать 80 часов за счет своих ресурсов. При этом сотрудник должен понимать мотивацию. Потом, он не может так работать целый год.

Может ли 9 женщин за месяц родить ребенка? В управлении проектов можно, но при очень существенных допущениях и при достаточно бОльших ресурсах. 9 женщин должны работать параллельно и при этом все они должны сделать немного раньше, чем за месяц, потому что за оставшееся время необходимо 1/9 ребенка собрать воедино.Так что все со временем не так просто.

Денежные

С денежными ресурсами тоже не так все просто. Деньги заказчик может не заплатить, пока не сделан какой-то этап. Может платить сразу, но это бывает редко. Исполнитель не сразу получает деньги, но ЗП платить он должен регулярно. Возникает кассовый разрыв, который решается займом в банке или у кого-то еще. А это еще один риск. Таким образом, исполнитель обязан знать финансовый менеджмент и риски, связанные с ним.

Человеческие

Человеческие ресурсы наиболее сложные для администрирования. К ним я бы отнес не только управление сотрудниками, но прежде всего человеческие ресурсы менеджмента.

К таким ресурсам можно отнести

• компетенция
• информация / коммуникации
• лояльность
• карьерный рост
• обещания и др.

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

Технические

Если будут знания разработки серверной части ИС, но без сервера и интернета это делать невозможно. Поэтому необходимы технические ресурсы.

Административные

К административным ресурсам можно отнести

• полномочия
• влияния
• знакомства и др.

Их передают, ими делятся, но за какой-то другой ресурс.Знакомства могут только расширяться. Но через некоторое время они могут стереться. Как правило руководитель влияет на сотрудников. Или передает право влиять на сотрудников какому-то специалисту. Знакомства тоже можно рассматривать как ресурс, которым делятся и/или передают информацию о качествах того или иного специалиста, бизнеса и т.д.

Риски

Риски были рассмотрены в предыдущих статьях по риск-менеджменту.

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

Также надо рассматривать ресурсы со стороны пользователей каких-то ресурсов. Там другой набор ресурсов надо рассматривать. Но об этом в следующий раз.

Риск-менеджмент. Информационная система

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

Не существует какой-то волшебной ИС, которая бы покрыла все потребности в Риск-менеджменте какого-то бизнеса, как это делает, допустим, 1С в бухгалтерии (потому что бухгалтерия очень сильно зарегулирована РСБУ от Минфина). Более того, нет какого-то единого функционала ИС, который бы покрывал Риск-менеджмент в разных отраслях экономики, например, инвестиционный риск-менеджмент очень сильно отличается от операционного. Стратегический отличается от инвестиционного и т.д.

Но тем не менее, можно разработать такую ИС, которая бы обладала всеми необходимыми базовыми свойствами.

Функциональность ИС

• ИС должна охватывать как можно большее количество людей, таких как
• учредители,
• акционеры,
• менеджеры разного уровня,
• нанятые сотрудники оргединицы,
• аутсорсеры и др.
• ИС должна хранить информацию о каждом риске: название, владелец и т.д.
• Идентификация рисков:
• Каждый риск должен иметь уровень, на котором интересен риск, допустим, финансовый риск не интересен ИТ-отделу и наоборот
• Начальник отдела может просмотреть все риски своего отдела и отделов, которые находятся в подчинении согласно иерархической структуре компании. Например, CEO может просмотреть все риски всех оргединиц, CFO может просмотреть риски всех финансовых отделов.
• Каждый сотрудник имеет право вносить риски, с которыми сталкивается на своем рабочем месте.
• Начальник отдела администрирует риски своего отдела.
• Риски должны классифицироваться по типам: внешние/внутренние, финансовые/операционные/человеческие и т.д.
• Если риск не случился, то его нужно сделать неактивным, но не удалять.
• Риски могут быть связаны между собой, например, риск неустановки сервера резервных копий к какому-то сроку связан с тем, что есть риск непокупки сервера, а также отсутствия сотрудника с необходимой компетенцией, который настроит сервер к какому-то сроку. При этом он должен освободиться от других дел или не находиться в стадии увольнения. При чем этом риск зависит от двух рисков как минимум. То есть риск может зависеть от разных рисков разных оргединиц.
• Риск должен иметь владельца. Как правило, это начальник отдела.
• Риски должны иметь дату создания, кто его создал и дату закрытия (необязательно).
• Оценка рисков
• Риск должен быть оценен, то есть ему должно быть дано 3 параметра:
• вероятность того, что может случиться риск
• ущерб при риске
• время, в которое может случиться риск.
• Риск может быть описан как набор троек параметров.
• Вероятность, ущерб, время может быть указано в промежутке, например, от 10% до 20%, ущерб от 1000 до 2000 рублей, сроки от через месяц до через 2 месяца. Таким образом, можно описать матожидание в промежутке, например 100-400 рублей. Время же позволит дать приоритет по хронологии решения проблем.
• Все риски должны быть ранжированы и показаны на диаграмме ущерб/вероятность. При чем это может быть отрезок, потому что мы рассматриваем промежутки. Время может быть выделено через цвет.
• Для решения рисков необходимы ресурсы. Ресурсы тоже могут быть выписаны и оценены, например, необходимо от 1 до 2 дней, необходимы такие-то компетенции. Если нет такой компетенции в отделе, то надо попросить их. То есть для решения риска необходимо описание способов решения и приблизительный список ресурсов.
• Если риск не случился, то должно быть описано что получит ("пряник") владелец риска и как он перераспределит этот "пряник" среди исполнителей.
• Администрирование рисков
• Риск может быть эскалирован на уровень выше.
• Риск может быть решен своими силами, то есть взят на себя.
• Риск может быть передан кому-то за какие-то ресурсы, например аутсорсер за какие-то деньги.
• Риск может быть передан нескольким субъектам. Но тогда нужно перераспределить ответственность, если он случается.
• Риск может быть игнорирован.
• Если риск не случается, то есть сделаны все необходимые мероприятия, которые привели к тому, чтобы этот риск не случился. Возможно, что не было сделано ни одного мероприятия. 
• Если риск не случится, то должно быть описано кто какой пряник получил.
• Если риск случился, то необходимо подробно описать причину, чтобы в дальнейшем понимать как с ним работать.
• ИС должна поддерживать все эти возможности.

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

Основные сущности

Здесь приблизительно описаны некоторые основные сущности

• Риск
• Название
• Дата создания
• Субъект
• Оргединица
• Дата закрытия
• Типы рисков
• Субъект
• Фамилия Имя
• Оргединица
• Компания, возможно внешняя
• Оргединицы компании
• Название
• Вышестоящая оргединица
• Руководитель оргединицы
• Контактная информация
• Внешние компании/ИП
• Название
• Руководитель
• Справочники по типам рисков.
• Название
• Значение
• Мероприятия пересмотров рисков
• Риск
• Дата
• Карты рисков
• Риск
• Процент (от и до)
• Ущерб (от и до)
• Время, в течение которого может случится риск
• Связи между рисками
• Доли распределения рисков между субъектами
• Пряники, которые получат субъекты, если риск не случится
• Доли распределения пряников между субъектами и т.д.

Стратегия разработки, внедрения и поддержки

Здесь я привожу приблизительные действия для того, чтобы разработать и внедрить ИС.

Методология разработки и внедрения - Agile / XP или Scrum.

Инициация

1. Провести интервью с заказчиком для того, чтобы определить scope функционала ИС по администрированию рисков.
2. Разработать необходимую документацию, инициирующую проект по разработке ИС.

Планирование

1. Разработать и согласовать план, этапы, риски разработки, внедрения, поддержки.
2. Согласовать бюджет и план оплаты и scope по каждому этапу.

Разработка / Контроль

1. Используя Google Таблицы внести информацию в таблицы основных сущностей. Согласовать значения таблиц с заказчиком.
2. Развернуть базу данных и IDE на сервере заказчика или внешнем сервере.
3. Разработка начальных интерфейсов на Windows.
4. Внесение в интерфейсы необходимых значений.
5. Разработка функциональности через функции базы данных.
6. Тестирование функциональности представителями заказчика.
7. Интеграция ИС с другими ИС бизнеса.

Завершение

1. Установка ИС на компьютеры сотрудников.
2. Разработка и согласование всей завершающей документации

Дополнительная разработка

• Разработка web-версии ИС (или ее части).
• Разработка мобильной версии ИС (или ее чести).

Поддержка

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

Преимущества

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

Можно, конечно, ограничиться таблицами Google, но они имеют ряд недостатков:

• ограниченность в общем количестве учеток (50) одновременного просмотра
• ограниченность в количестве учеток (10) одновременного изменения
• не более чем двумерное представление сущностей
• невозможность написать достаточно сложный функционал

MS Excel не подходит для работы с рисками, потому что он не работает многопользовательском режиме. На самом деле работает в последних версиях, но необходимо устанавливать сервер и администрировать это решение.

Риск-менеджмент. Рисковые стратегии

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

Еще раз напомним, что неблагоприятное событие случается тогда, когда

• что-то делаешь и по-разному
• что-то не делаешь

Третьего не дано. Когда что-то делаешь, то затрачиваешь некоторые ресурсы. И в том и другом случае ты принимаешь риски, передаешь их или игнорируешь. Если риски не случаются, то может не быть ущерба, а даже наоборот, профит. Возьмем какую-то стратегию, которая дает нам максимальную прибыль $P$ и максимальный ущерб $D$. Могут быть еще промежуточные значения, которые распределены крайне неравномерно. То есть можно рассматривать случайную величину $\xi$, которая имеет некоторую функцию распределения $F_\xi(x)$, $x\in[-D; P]$.

Эта случайная величина может быть разложена на две положительные случайные величины $\xi_D$ и $\xi_P$:
$$
  \xi = \xi_P - \xi_D
$$
При этом тот случай, когда нет ни профита, ни ущерба может быть больше нуля:
$$
  \mathbb{P}(\xi = 0)= p_0>0.
$$

Для дискретной случайной величины

$$
  M = \sum_iP_ip_i-\sum_iD_ip_i
$$

Для абсолютно-непрерывной случайной величины

$$
  M = \int_0^PxdF_\xi(x)-\int_{-D}^0xdF_\xi(x).
$$

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

Таким образом, чистый средний профит $C$, который получит предприниматель

$$
  C = \mathbb{E}\xi-\mathbb{E}S.
$$

Если не делать ничего или почти ничего, то $S$ будет равно нулю или около того.

Поэтому если нулевая стратегия приносит доход $C_0$ больше, чем затратная стратегия, пусть и может быть приносящая при некоторых исходах большую прибыль, но в среднем приносящая $C_1$, при этом

$$
  C_0 > C_1
$$

то стратегия "ничего не делать" разумнее, чем "делать что-то".

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

Человек постоянно решает у себя в голове интуитивно и сознательно рисковые задачи, придумывает и оценивает различные стратегии. 

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

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