Риски, паникеры и негодяи.

Авторы: Алексей Янчук, Константин Кондратюк

Тони Хейворд как исполнительный директор BP, безусловно, является главным ответственным за разлив нефти в Мексиканском заливе. Другой вопрос, является ли тем негодяем, каким из него хочет сделать пресса? Эмоциоанльный ответ – да. Разумный – нет.
Из тех фактов, которые были озвучены в СМИ, можно восстановить следующую картину. За две недели до аварии на скважение Deepwater Horizon инженеры обнаружили проблемы в оборудовании для предотвращения разрывов труб. Их надо было бы устранить, но для этого надо было остановить добычу на несколько дней – о чем и доложили менеджменту. Менеджмент, конечно же, «проигнорировал», т.е. принял решение – продолжать добычу нефти. Что стало после – уже история. Чего не хватает в этой картине?
Не хватает одной детали: обнаруженные инженерами проблемы оказались бы существенными только в случае наступления «катострафического, но маловероятного события». Делела ли BP нечто экстраординарное? Наверное, не более того, что делают все, когда речь идет о том, что мы считаем (или хотим считать) маловероятным. Мой коллега любит шутить, что проблема со статистикой начинаеится, когда ты сам становишся её частью. BP не повезло, что это маловероятное событие впервые наступило имеено для них, а не для, скажем, Shell или Chevron.
Особенность ИТ то, что риски и их последствия не только умозрительны, но и слишком редко материализуются на практие в что-то действительно болезненное. На основании чего определяются риски с точки зрения безнес-менеджера без опыта в ИТ? На основании тыканья пальцем в небо. Какими могут оказаться реальные последствия, например, решения нагнать съехавший график важного проекта, урезав тестирование по самый минимум? Ведь номинально продукт будет работать в срок, а что еще надо? А 99,9% страшков из «анализа рисков» не только ни разу не случались в реальной жизни, но и не произойдут вообще.
Давайте посмотрим, как оцениваются потенциальные убытки от простоев ИТ системы за один рабочий день (назовем это L). В самом простом (и поэтому чаще всего и используемом) случае это количество пользователей (u), умноженное на коэффициент использования системы в день (k), умноженное на стоимость работы в час (p). L = u * k * p. В чем «физический смысл» значения p? Можно долго рассуждать на эту тему, но по правде говоря это всего лишь число в таблице Эксель, которое используется в рассчетах.
Можно соглашаться или не соглашаться с приведенными выше наблюдением. Давайте представим, что руководство попросило Вас как менеджера в ИТ сделать нечто, выходящие за Ваши представления об максимально допустимом уровне риска. Естествнно, что Вы постараетесь переложить риски сврех того, что Вы считаете разумным, на руководство. Вы подготовились, сделали расчёты, такие красивые цифры получились... А руководство Вам говорит: не верю! Не верю, что реальные убытки будут вот столько, сколько Вы тут насчитали! Прекратите паниковать; лучше займитесь работой, вместо того, чтобы тратить время на бесполезную ерунду! Вы говорите, что у Вас не хватает людей в команде? Наверное, их у Вас слишком много, раз у Вас есть время делать бумажки. И, кстати, постарайтесь без этих убытков, на дворе и так кризис!
Что ж, так совпали звезды, что Вам приходится выбирать, кем быть. Паникером – пытаясь убедить окружающих в реальности рисков, в которые никто, кроме Вас, не верит. Или негодям – принимать на себя рискованные решения, чтобы выполнить поставленную задачу. Есть еще третий вариант: оценить, сколько времени есть до того, как у предполагаемых Вами рисков появится более-менее внятные шансы стать реальностью.
Мы привыкли рассматривать риски по размеру последствий и вероятности их наступления. Хотя честнее было бы рассматривать риски с точки зрения времени и способа материализации. Сделать такую оценку не просто. Поэтому мы чаще слышим, что «это авария ждала, чтобы случиться», и совсем не слышим, что «эту аварию ждали с 25ой на 26ую неделю этого года, но она почему-то случилось на 24ой неделе». Однако и не так сложно, как может показаться на первый взгляд. Для этого надо а) найти слабое место, б) определить, что по этому место может «ударить» и в) оценить, когда срабатает триггер «ударного механизма».
Итак, заказчик решил сэкономить и решил исключить функционал контроля качества из продукта. Что ж, действительно, отсутствие контроля качества не сделает погоды после запуска продукта. Но если посмотреть более длительный период эксплуатации, то после 3го месяца пользователи ошибки и неточностей из-за отсутствия контроя качества будет заметны, но не будут сказаться на ежедневной работе. После года работы из-за количество неточностей и ошибок в данных персонал будет заметно не справляться с поставленным SLA. После этого проблемы будут разрастаться экспоненциально. Достоверно определить возможные сценарии развития на втором году можно будет только после 9ти месяцев работы продукта. Вам система нужна на 5ть лет. Если мы сделаем то, что мы просим, мы Вам можем гарантировать только первые три месяца работы. Остальное – в зависимости от того, как именно будут материализоваться риски...

RSS-материал подписаться на рассылку

Опрос

Какой тренинг Вам наиболее интересен?:
 

Яндекс.Метрика