Блог: Управление рисками

Давайте представим, что Вам поручили руководить проектом, задача которого автоматизировать важный бизнес-процесс заказчика. Целью проекта является оптимизация использования людских ресурсов заказчика. Проект проходит как обычно: сроки двигаются в приемлемых рамках, качество программного кода находится в пределах ожиданий, в последний момент вскрываются несущественные проблемы, решать которые в первой версии нет времени. Успех, провал, или получилось как обычно?

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

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

1. Задумка: определение, чем ИТ-решение может помочь потенциальным пользователям;
2. Проектирование: составление требований и выработка решения, удовлетворяющая им;
3. Эксплуатирование: извлечение той пользы, ради которой решение задумывалось;
4. Списание: выведение решения из эксплуатации.

Т.е. цель любого ИТ решения – удачная эксплуатация: извлечение заказчиком ожидаемой практической выгоды. Проектирование программного решения, будь то выбор коробочного продукта или написание уникальной программы с нуля – это задача. Сложная, болезненная, длительная – бесспорно, но все-таки задача, причем далеко не единственная.

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

Программное решение как работало, так и будет работать – с ним как раз ничего и не случится. Однако один человек не сможет эффективно обслуживать бизнес-процесс, если объем работ по обслуживанию был рассчитан на троих. Точнее, сможет, но не долго. После первого месяца незавершенной работы накопится на два месяца вперед, и ситуация будет только ухудшаться от месяца к месяцу. Какой же это успех? Простите, поставщик ПО, это просто полный провал!
Вот и получается, что поставленные задачи выполнены на крепкую ”четверку” с плюсом, а цель оказалась безнадежно упущена. Когда это становится очевидным, кого-то, кто руководил проектом, вызовут дать объяснения, как вообще такое произошло, и кто за весь этот хаос должен отвечать. Два извечных вопроса: можно ли было что-то предпринять раньше, и если нет, то как выходить из такой ситуации?

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

Тони Хейворд как исполнительный директор 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ть лет. Если мы сделаем то, что мы просим, мы Вам можем гарантировать только первые три месяца работы. Остальное – в зависимости от того, как именно будут материализоваться риски…

Казалось бы, на тему того, что лучше — waterfall или agile -– все те, кто хотели, уже сломали все копья. И казалось бы, большинством голосов согласились, что будущее все-таки скорее за agile. И тем не менее складывается ощущение, что процесс поиска аргументов за agile не отпускает «евангелистов».

Как-то на одной scrum-конференции один участник задал вопрос: как можно совместить Scrum и 9001 сертификацию? Встает один scrum-«евангелист», и начинает доказывать, что сертификат 9001 со Scrum-ом не совместим никоим образом, и вообще пережиток прошлого и никому он не нужен. Когда высказался, я (Алексей Янчук) решил взять слово. Говорю: 9001 и Scrum совмещаются очень просто. 9001 описывают всю компанию, Scrum — узкую область написания софта и взаимодействия с представителем пользователей. Опишите в 9001 как вы скраммите — и дело сделано.

После меня встает евангелист, и начинает убеждать публику, что я, как бы это так помягче сказать, нес ересь. 😉 Вызвало улыбку. Говорю: коллега, вы знаете, есть Scrum, а есть зарплата, которую вам платят. Вы знаете, откуда она берется? Так вот, говорю, как человек, который отвечает за выбор подрядчиков, открою вам страшную тайну. Никто никогда не читает десятки предложений. Выбирают два-три для детального прочтения, остальные, увы, идут в мусор. Эти 2-3 выбираются в первую очередь — сюрприз — по формальным признакам. Поэтому фирма, у которой есть Scrum и 9001 по определению придет на финиш раньше, чем Scrum от «евангелие».

В споре, что лучше — waterfall или agile — почти всегда забывают о том, что есть еще третья сторона — бизнес. Он же клиент. Он же заказчик. Он же тот, кто оплачивает работу. Я регулярно устраиваю sit down встречи с заинтересованными сторонами, где в неформальной обстановке обсуждается текущее положение дел. На одной из таких посиделок заказчик как-то пожаловался на опыт внедрения Scrum.

Что произошло? До Scrum-а была регулярная проблемы с тем, что разработчики обещали сроки, которые практически никогда не выполнялись. А теперь — он говорит — стало еще хуже. Если раньше мы знали, что обещанное к концу второго квартала будет работать к началу четвертого, то теперь мы даже понятия не имеем, когда над нашими задачами начнут работать.

Как же так? — спрашиваю я — ваш подрядчик весь из себя такой Scrum-сертифицированный? В чем проблема спланировать и закоммититься под несколько спринтов — есть в этом есть такая бизнес-необходимость? Да дело в том — отвечает заказчик, — что команда дает коммитмент только под следующий спринт. Исходя из того, что насыпалось в этот [цензура] бэклог. А сыпется туда достаточно!

О чем это мы? О том, что споры о том, что лучше — waterfall или agile — это по большому счету споры ни о чем. Невозможно написать идеальную спецификацию — которая бы не вызывала вопросов, и в результате которой получилось бы то, что на самом деле хотели. Поэтому любой ИТ проект будет похож на плавание галсом против ветра, в идеале не сильно отклоняясь от общего направления. Будь то waterfall или agile.

Успех или неуспех определяется в первую очередь лидерством: знать, куда идем, зачем, как работать с изменениями и ожиданиями заинтересованных сторон и почему мы делаем то, что делаем. Во вторую — командой, и только в третьих — инструментами. На английском есть такое хорошее выражение: «a fool with a tool is still a fool.» Что на русский можно перевести, как «заставь дурака Богу молиться, так он лоб себе расшибет».

• Подготовь мне оценки сбоев в нашем продукте следующего поколения.
• Я могу подготовить их, если вам нравятся цифры на основе галлюцинаторных предположений.
• Они мне как-бы нравятся.
• Думаю, у нас есть понимание.

Пару лет назад вышел у нас спор с одним проблемным сотрудником, который активно пытался выдвинуться на agile волне. Ему была поставлена задача разработать crash-recovery процедуру для семейства продуктов, которые разрабатывала наша группа. Сотрудник упорно пытался отбрыкаться от этой задачи, убеждая нас, что это все пустая трата его времени и наших денег. YAGNI, YAGNI, YAGNI! – пытался он нас убедить – ведь это же функционал, который мы хотим видеть только потому, что мы боимся, что он нам в один день понадобиться. А если мы внедрим супер правильные agile техники в проект, то весь этот crash-recovery не нужен, потому что софт просто не будет сбоить. И делал все, что угодно, но только не то, о чем его просили. В итоге задачу отдали другому сотруднику, а с agile евангелистом пришлось расстаться.

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

Понятно, что глупо валить проблемы с сервером БД на нас, разработчиков прикладного ПО. Разумеется, что-то в наших приложениях вызывает этот сбой. Вряд ли мы сознательно делаем что-то «нелегальное». Соль ситуации в том что именно мы, разработчики ПО, а не производитель БД, отвечаем за обеспечение целостности данных для бизнес-пользователей. Это нам пользователи мечтают выставить счет за вынужденный простой, а не производителю БД. И именно наша задача выработать подход, как пользователям работать дальше с учетом возникшей проблемы.

Ситуация в цифрах: убытки от часа простоя одного пользователя с учетом всех задержек и простоев в бизнес-цепочке оценивается в 300 у.е. Таких пользователей 30-40 в день. Риски оперирования на нецелостных бизнес-данных 4000 у.е. на транзакцию, таких транзакций 20-30 тысяч в день. Производитель БД активно изучает проблему, но ничего не обещает. Но и о прекращение работы речь не идет, поскольку останавливать бизнес на неопределенный срок никто не собирается. Поэтому на повестке совещания по данному кризису стоит ровно один вопрос: как оперировать продуктами, чтобы не влететь в астрономические убытки?

Может ли в такой ситуации YAGNI-евангелист предложить что-то, кроме как открыть экстренный спринт с юзер стори «как пользователь, я хочу быть уверен, что я могу продолжать работу после аварии на сервере БД»? Да, может: например, размахивать руками и уверять, что авария сервера БД – это мелочь. Прикладной же софт очень надежный. Верьте мне… Ага, счас! «Слушай, на кону вот столько денег. Ты серьезно предлагаешь пользователям оперировать следующие пару недель с проблемами неизвестного характера и неизвестными последствиями?» ‑ спросят опытные эксплуатационщики? Вряд ли найдется, что ответить.

* * *

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

Что-то нам подсказывает, что Pointy-hair boss и Дилберт в этом комиксе друг-друга так и не поняли.