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

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

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
$$

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

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

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

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

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

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

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

Итак, во-первых, их необходимо идентифицировать и классифицировать, например

по типам неблагоприятных событий:

• технологический риск
• финансовый риск
• предпринимательский риск
• человеческий риск и др.

Они также могут классифицироваться как 

• внешние 
• внутренние.

А также риски могут наступить от какого-то

• действия
• бездействия.

Впрочем, более детальная классификация может быть почерпнута здесь.

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

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

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

Поэтому они должны постоянно пересматриваться. Кем? Очень хороший вопрос. У каждого риска должен быть владелец, то есть тот, кто администрирует его.

А если риск неидентифицирован и неблагоприятное событие случилось? То ответственность несут акционеры при чем в долях участия. Это должно быть прописано в уставе.

Что такое администрация риска?

Ну, во-первых, это каждому риску дать 

• вероятность наступления неблагоприятного события $p$, 
• ущерб, выраженный в деньгах $D$,
• приблизительное время наступления $t_D$.

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

При чем все эти три величины в общем случае могут рассматриваться как случайные величины и зависимы от времени $t\in[0;T]$. На самом деле никто их таковыми не рассматривает. Но это не значит, что их нельзя рассматривать как случайные величины. Это все равно, что решать задачу о передаче энергии/импульса одной тележке другой на плоскости, при этом зная, что земля круглая.

Каждому риску на данный момент времени должно быть проставлено какое-то одно числовое значение, например,

• математическое ожидание ущерба в простом случае равное $pD$
• максимальная вероятность наступления неблагоприятного события
• средняя вероятность наступления неблагоприятного события
• максимальный ущерб
• средний ущерб и т.д.

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

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

После идентификации и сортировки рисков что с ними можно делать? Вот что:

• Принять на себя
• Передать другому/другим
• Игнорировать

Все зависит от стратегии, которую изберет владелец риска.

Принять на себя

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

По поводу что такое ресурсы - это отдельная тема.

Передать другому/другим

Риск также можно передать другим или другому. Чем больше субъектов, тем хуже администрируется риск. При передаче риска другому субъекту, может оказаться, что субъект не захочет риск брать не себя. По крайней мере просто так. Поэтому вместе с риском надо предлагать "пряник" в виде

• денежного вознаграждения, например
• купить полис КАСКО
• нанять фрилансера
• нанять аутсорсера
• поделить с кем-то прибыль будущих периодов
• информации (это тоже ресурс)
• пообещать, что 
• выплатишь премию
• повысишь в должности/зарплате
• познакомишь с влиятельными людьми (да-да, знакомства - это тоже ресурсы)
• купишь бриллиантовые сережки и т.д.

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

Передача риска особенно актуальна, когда для тебя риск больше, чем для субъекта. Поэтому и происходит передача риска другому субъекту за вознаграждение.
Риски могут быть переданы частично, то есть при неблагоприятном событии ущерб делится в каких-то долях, например, половина на половину среди двух аутсорсеров, а на владельце нет риска. Или ущерб делится на трех в равных долях среди владельца и двух фрилансеров. Это должно быть оговорено заранее. Аутсорсер также может передать риски другому, допустим фрилансеру. Фрилансер другому студенту и т.д.

Игнорировать
Игнорировать риски - не такая уже бессмысленная стратегия. 

• Во-первых, игнорируешь те риски, которые не идентифицируешь. 
• Во-вторых, игнорируешь те риски, которые непонятно, что это благоприятное или неблагоприятное событие.
• В-третьих, игнорировать можно и нужно те риски, которые не существенны. Например, ущерб слишком мал при достаточно большой вероятности или ущерб слишком велик при очень маленькой вероятности. Все зависит от той функции, которая дает число.
• В-четвертых, игнорируешь те риски, до которых не дошли руки.
• В-пятых, игнорируешь те риски, у которых стоимость принятия на себя или передачи другому больше чем максимальный ущерб.
• В-шестых, человек так устроен, что не хочет бояться рисков. Действует на авось.
• В-седьмых, риск может компенсироваться теми "пряниками", которые он получит, если не случится наблагоприятное событие и т.д.

Да, и главная особенность рисков - они могут не случаться!!!

Когда риски не случаются, можно получить пряники, то есть ущерб со знаком "минус". Это самое приятное для предпринимателя. Кто получает пряники по умолчанию? Как правило - владелец риска. Однако, он может ими поделиться с теми, кто принял на себя эти риски, а в некоторых случаях и обязан, если об этом договорились заранее.

Риск-менеджмент - математические наброски

Довольно много написано про риски здесь

Здесь мы попытаемся кратко определиться что такое риск-менеджмент в ИТ и как формализовать риск-менеджмент для разработки ПО.

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

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

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

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

Риски могут появляться, случаться и уходить. 

Рассматриваем промежуток времени $T$. 

В самом простом случае риск $R$ может случиться с некоторой вероятностью $p$. При этом ущерб может составить $D$ и случиться в некоторый момент $t\le T$. Таким образом, в самом простом случае риск $R$ описывается тройкой $(p, D, t)$. При чем матожидание $M$ ущерба равно
$$
  M = pD.
$$

Это в самом простом случае. Обобщая, можно предположить, что ущерб может варьироваться в зависимости от риска, например, ущерб может составить 100 рублей с вероятностью 0.1 или 1000 рублей с вероятностью 0.001. Таким образом, матожидание ущерба равно
$$
  0.1*100+0.001*1000=20.
$$
В общем случае ущерб может быть описан как интеграл Лебега
$$
  M=\int D dp,
$$
при чем $\int dp = P\le1$. При этом считаем, что $P>0$
Определим $P_D$ как условная вероятность при ущербе
$$
  P_D=\frac{p}{P},
$$
чтобы определить $M$ как матожидание
$$
  M=P_D\mathbb{E}D
$$
по вероятностной мере $p/P_D$.
Следующее обобщение для рисков - это то, что время наступления неблагоприятного события $t$ может быть случайной величиной и иметь некоторое распределение $p_t$.
$$
  \int p_t(\omega) = 1.
$$
Тогда
$$
  M=\int\int Dtdpdt = P_D\mathbb{E}\mathbb{E}D
$$
по двум мерам $p/P_D$ и $p_t$.
Также можно внедрить время изменения рисков, потому что они достаточно быстро меняются, то есть рассматривать тройку $p(t), D(t), t(t)$. $p_(t)\to 0$ при $t\to T$. Хотя это бывает не всегда, то есть риски переходят и на следующие периоды.

Следующее обобщение - это то, что рисков может быть одновременно несколько, допустим $n$: $R_1$, $R_2$,...$R_n$. и они могут быть связаны между собой, например, риск $R_2$ может случиться тогда, когда случится риск $R_1$.
Также какой-то риск может случиться при стечении обстоятельств, то есть при реализации нескольких рисков одновременно. То есть мы можем говорить о некотором графе (не обязательно иерархическом) рисков.

Ну и так далее.

Вероятностное пространство, Вероятность и Случайная Величина

Вероятностное пространство описывается как тройка объектов

Вероятностное пространство

$\Omega$ - непустое пространство событий $\omega$.
$\mathcal{A}$ - сигма-алгебра событий подмножеств $\Omega$.

При этом $\Omega$ без $\mathcal{A}$ существовать может вполне.
А вот $\mathcal{A}$ существует только тогда, когда определено $\Omega$. Иногда говорят о двойке объектов $(\Omega, \mathcal{A})$ - измеримое пространство.
Самая простая $\mathcal{A}$ состоит всего лишь из двух элементов: $\{\varnothing, \Omega\}$.

$\mathbb{P}$ - сигма-аддитивная мера или функция, действующая из $\mathcal{A}$ в $[0;1]$, определенная на двойке $(\Omega, \mathcal{A})$ с дополнительным свойством
$$
\mathbb{P}(\Omega) = 1.
$$
Также могут быть определены другие сигма-аддитивные меры $\mu$ на пространстве $(\Omega, \mathcal{A})$, но без условия $\mu(\Omega) = 1$

Двойка $(\Omega, \mathcal{A})$ может существовать без $\mathbb{P}$, а вот $\mathbb{P}$ должно быть обязательно определено на каком-то пространстве $(\Omega, \mathcal{A})$. То есть мера вероятности существует тогда, когда определено пространство. На одном и том же пространстве могут быть определены сколько угодно вероятностных мер.

Борелевская сигма-алгебра $\mathcal{B}$, определенная на прямой $(-\infty;+\infty)$ - это минимальная сигма-алгебра, содержащая все открытые интервалы этого пространства.
Эта сигма-алгебра устроена достаточно просто: это объединение счетного числа точек, открытых и закрытых слева и/или справа отрезков, а также всех открытых и закрытых полуинтервалов (неограниченные слева или справа).
Двойку множество вещественных чисел $\mathbb{R}$ c борелевской сигма-алгеброй $\mathcal{B}(\mathbb{R})$ рассматривают как измеримое пространство.

Борелевская сигма-алгебра может быть определена и на каком-то конечном отрезке, допустим $[0;1]$. Тогда она содержит объединение счетного числа точек, открытых и закрытых слева и/или справа отрезков, которые находятся внутри отрезка $[0;1]$.

Казалось бы, эта сигма-алгебра покрывает все возможные случаи подмножеств множества $[0;1]$, допустим. Однако, это не так. Неборелевским множеством, допустим, является множество точек, разница которых есть рациональные числа. Поэтому в теории вероятностей, чтобы не рассматривать такие дурацкие случаи, всегда указывают, что мы рассматриваем только борелевские множества.

Случайная величина $\xi$ - это функция, действующая из $\Omega$ в множество действительных чисел $\mathbb{R}$. При этом она должна быть измерима относительно $\mathcal{A}$, то есть обратная функция, действующая из $\mathbb{R}$ в $\Omega$ от всех борелевских множеств должна принадлежать $\mathcal{A}$:
$$
  \{\omega :\xi(\omega)\in B\}\equiv\xi^{-1}(B)\in\mathcal{A}
$$
для всех борелевских $B$, определенных на $(-\infty;+\infty)$. В теории вероятностей всегда рассматривают измеримые относительно какого-то измеримого пространства функции.

Кстати, вероятностная функция $\mathbb{P}$ тоже измерима относительно двойки $(\Omega, \mathcal{A})$ и может также рассматриваться как случайная величина.

Вопрос на засыпку: может ли случайная величина существовать без вероятностной меры?
Правильный ответ - да. В определении случайной величины нет указания на вероятностное пространство. Поэтому и может.

Однако, случайная величина без вероятностной меры в теории вероятностей не интересна, поэтому и рассматривают распределение случайной величины  в связке с вероятностной мерой:
$$
  P_\xi(B) = \mathbb{P}\{\omega: \xi(\omega)\in B\}, B\in\mathcal{B}(\mathbb{R}).
$$
Это определение распределения случайной величины $\xi$ на $(\mathbb{R}, \mathcal{B}(\mathbb{R}))$.

Функцией распределения случайной величины $\xi$ является функция $\mathbb{R}\to[0;1]$
$$
  F_\xi(x)=\mathbb{P}\{\omega:\xi(\omega)\lt x\}, x\in\mathbb{R}.
$$
Функция распределения существует всегда.

Это что касается одномерных борелевских сигма-алгебр, множества вещественных чисел, случайных величин. Но это может быть перенесено достаточно просто на двумерные, $n$-мерные и даже бесконечномерные аналогичные понятия.

Редизайн веб-сервисов

Есть такое выступление про редизайн веб-сервисов

https://www.youtube.com/watch?v=8BJqquNzGbM

Ильи Трегобова

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

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

При этом

• Силу привычки нужно рассматривать в разрезе возрастных страт -  чем старше человек, тем больше сила привычки/привязанности.
• Количество пользователей в разных возрастных стратах.
• Чувство уважения увеличивается чем старше человек становится.
• Чувство того, что получит пользователь взамен появляется не сразу (может быть вообще никогда).
• Количество конкурентов подобных сервисов уменьшается при росте удобства и/или усложнения сервиса.

В результате мы получим не качественные характеристики типа

• революционный/эволюционный,
• плохо/хорошо,
• много/мало,

а количественные целевые показатели (сколько), при этом их не должно быть много:

• какой прирост пользователей (берется из статистики сайта, типа Yandex.Metrika)
• лояльность пользователей (например, равно отношению кол-ва пользователей, кликнувших кнопку Нравится на общее количество проголосовавших)
• кол-во ресурсов, выраженных в деньгах, потраченных на редизайн (исходя из бухгалтерии проекта по редизайну).
• какова прибыль от проекта по редизайну.

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

Если мы не может посчитать целевой показатель за какой-то промежуток времени, то его и не нужно рассматривать.

Таким образом, владелец сервиса получит понимание того,

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

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

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

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

• опрос пользователей о переходе на новый дизайн до редизайна
• опрос пользователей о новом дизайне после редизайна
• поддержка старого дизайна
• добавление новой функциональности только в новый дизайн и т.д.

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