ЛК
Меню
Кто не рискует, тот не управляет: как работать с рисками в реальных условиях

Кто не рискует, тот не управляет: как работать с рисками в реальных условиях

В этом выпуске «Kanban Talks» мы обсуждаем тему, которую слишком часто упускают в повседневной практике — риски и их управление. Гость выпуска — Андрей Гирин, управляющий партнер и лидер изменений, делится личным опытом, подходами и проблемами, с которыми сталкивается большинство команд и менеджеров, когда речь заходит о работе с неопределенностью.

Что такое риск и почему он до сих пор остается недооцененным

Риск — это событие, которое может произойти с определенной вероятностью и повлечь за собой негативные последствия. Два ключевых параметра, которые его определяют:

  • Вероятность наступления события,
  • Стоимость последствий (то, что мы теряем, если риск реализуется).

Если оба этих параметра значимы, это — полноценный негативный риск, с которым нужно работать. А вот что именно с ним делать — зависит от контекста.

Важно понимать, что типология рисков зависит от деятельности. Если речь идёт о проектах — это проектные риски. В операционке — операционные. В информационной безопасности — риски, связанные с доступом и уязвимостями. В каждом случае свой «ландшафт».

Опыт из ИТ: когда риски перестают быть теорией

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

«Если вдруг падает сервер — нужно не просто быстро поднять его, но и быть уверенным, что ничего по пути не потерялось. А ещё лучше — сделать так, чтобы он вообще не падал.»

Здесь он впервые осознал, что доступность — это всегда баланс между компонентами:

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

И если, например, отваливается авторизация — сервис может деградировать, даже если «твоя» часть работает. Это типичный межсервисный риск, который сложно локализовать, если не обсуждать заранее с коллегами и не выстраивать архитектуру с учётом таких взаимозависимостей.

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

  • защита от несанкционированного доступа,
  • недопущение перехвата писем,
  • минимизация возможности подмены учётных записей.

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

Как риски стали осознанным объектом управления

С переходом в управление проектами Андрей впервые столкнулся с тем, что рисками можно управлять по процессу:

  • выявлять,
  • оценивать,
  • выбирать способ работы с ними,
  • отслеживать.

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

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

Почему команды забывают о рисках?

Существует несколько причин:

  • Риски не видны, пока не случится что-то критическое.
  • Работа с ними не даёт немедленного результата — нет «быстрой победы».
  • Команды чаще фокусируются на delivery, а не на устойчивости.

При этом в таких сферах, как финтех или страхование, культура управления рисками развита. Причина проста: там риски напрямую связаны с деньгами. Но в разработке и создании продуктов — всё иначе.

Что делают компании с рисками (и чего не делают)

Способы работы с рисками довольно базовые:

  • Снижаем вероятность наступления события.
  • Снижаем последствия, если событие всё же случится.
  • Принимаем риск как есть.

Но проблема в другом — в большинстве случаев команды останавливаются на выявлении. Рисковую ситуацию описали, назначили «ответственного», а дальше действий нет. Риск случается, и команда разводит руками: «не получилось, не фартануло».

Пример: логистика и физические компоненты

Один из недавних кейсов: сборка продукта зависела от поставки физических компонентов.

Логистика — под угрозой из-за внешнеполитической ситуации. Риск? Очевиден.

Решения, которые могли бы работать:

  • проработка альтернативных маршрутов доставки,
  • создание буфера — запаса комплектующих,
  • договор с другим поставщиком на случай срыва.

И это всё — стандартные действия, которые должны следовать после выявления риска. Но часто до них не доходит.

Один из самых недооценённых рисков — «Bus Factor»

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

«Почему-то большинство менеджеров вообще ничего с этим не делает. А зря. Это то, за что они, по сути, получают деньги.»

Примеры действий:

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

Хуже всего, когда в попытке «оптимизации» менеджеры разводят двух разработчиков по разным компонентам, создавая не один, а два bus-фактора.

Управление рисками на практике: от фастфуда до IT

Во второй части беседы с Андреем Гириным мы переходим от определения и частных кейсов к системному подходу к управлению рисками в разных типах организаций — от фастфуда до высокотехнологичных IT-команд.

Как работает mitigation бас-фактора в Макдональдсе

Если перенести концепцию bus-фактора (критическая зависимость от одного сотрудника) из мира IT в классический бизнес, вроде сети ресторанов быстрого питания, — на удивление, она работает отлично. В случае с Макдональдсом риск потери ключевого сотрудника практически несущественен.

За счёт глубокой стандартизации процессов, ротации сотрудников между станциями и сниженного порога входа (обучение за часы, а не недели), компания легко компенсирует отток персонала. Даже если внезапно вся смена «выиграет в лотерею и уедет на Мальдивы», новые сотрудники смогут быстро заменить предыдущих без ущерба качеству работы.

Кроме того, управление графиками с учётом циркадных рыночных циклов — утренние и вечерние пики, ночное затишье — позволяет компании эффективно распределять нагрузку и избегать перегрева персонала.

Можно ли стандартизировать разработку?

Возвращаясь в IT, Андрей поднимает важный вопрос: можно ли добиться такой же предсказуемости в интеллектуальном труде? Ответ — условно да. При условии, что код пишется не в стиле «лишь бы работало», а с расчётом на поддерживаемость:

  • Простая архитектура,
  • Покрытие тестами,
  • Комментарии и документация,
  • Живая база знаний,
  • Код-ревью с едиными правилами.

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

Баланс между скоростью и устойчивостью

Однако в реальной разработке возникает конфликт: требования к качеству кода и процессам могут мешать скорости поставки. Продакт жалуется, что из-за всех «этих ваших правил»:

  • нужно проходить код-ревью у перегруженного тимлида,
  • писать лишние комментарии и теги,
  • тратить время на тесты.

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

Хорошо для кого: для сотрудника или для организации?

Следующий логичный вопрос — что считать «хорошо» для компании, если у сотрудника может быть противоположное ощущение? Андрей предлагает чёткий ориентир:

  • У компании должен быть набор KPI, отражающих её здоровье (аналог «температуры тела»).
  • Должна быть понятная стратегия движения вперёд.
  • Отклонения от KPI говорят о системной проблеме, которую надо корректировать.

Простой пример: если ради роста выручки ухудшается пользовательский опыт — это сигнал, что нужно переоценить подход.

Kanban, SAFe и инструменты управления рисками

Здесь в игру вступают масштабируемые методы. В SAFe, например, используется инструмент ROAM:

  • Resolved — риск устранён,
  • Owned — назначен ответственный,
  • Accepted — принят без изменений,
  • Mitigated — есть план снижения.

Риски визуализируются на доске (физической или электронной), обсуждаются на PI-планировании, назначаются ответственные. Такой реестр — не формальность, а живой инструмент.

Дополнительно Kanban предлагает обратные петли (feedback loops): на митингах фиксируются узкие места и события, которые могут перерасти в риск. Иногда — реактивно, иногда — на опережение.

PDCA: цикл, без которого не работает ничего

В финале Андрей подчёркивает: любой подход работает только в цикле PDCA (Plan-Do-Check-Act). Без этого риск-реестр превращается в пыльный архив.

Вывод: Риски — это не абстрактная угроза. Это управляемый объект. Даже если вы не корпорация вроде Макдональдса, вы можете выстраивать процессы, которые снижают зависимость от людей, событий и случайностей. Главное — действовать системно, а не по наитию.