В этом выпуске «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). Без этого риск-реестр превращается в пыльный архив.
Вывод: Риски — это не абстрактная угроза. Это управляемый объект. Даже если вы не корпорация вроде Макдональдса, вы можете выстраивать процессы, которые снижают зависимость от людей, событий и случайностей. Главное — действовать системно, а не по наитию.