Все вокруг твердят о рисках, «риски надо учитывать», «риски нужно минимизировать», но мало кто системно объясняет, какие вообще риски бывают и как их классифицировать именно применительно к Delivery Management.
Итак, представьте: вы DM, ведете проект. В вашем чеклисте десятки пунктов, и среди них мутно сформулированное управление рисками. Разбиваем работу с рисками на три вопроса:
Источник риска. Откуда проблема может прийти? (Команда, технологии, бизнес или внешняя среда)
Тип проявления риска. Чем грозит? (Срыв сроков, падение качества или полный стоп проекта)
Стратегия ответа на риск. Что мы с ним делаем? (Принять, уменьшить, эскалировать или передать)
Пройдёмся по этим категориям.
Источники рисков
Можно выделить четыре основных источника:
Команда. Всё, что связано с людьми, исполнителями. Например, риск того, что какой-нибудь разработчик уволится посреди проекта. Или что в команде конфликт, влияющий на продуктивность. Или банально недостаток компетенций, взяли новых ребят, а у них не хватает опыта. Командные риски часто недооценивают, особенно технические менеджеры: мол, люди есть люди. Но для DM это реальная зона риска, влияющая на сроки и качество.
Технологии. Сюда попадают риски, связанные со стеком, инфраструктурой, кодовой базой. Выбрали новую фреймворк, есть риск, что он сырый и всплывут баги. Делаем продукт на старом легаси, риск технического долга. Сюда же железо, хостинг, любые технические зависимости. Например, риск, что сервер ляжет под нагрузкой, или что интеграция через API партнёра нестабильна.
Бизнес. Риски, рождающиеся из бизнес-решений и требований. Например, частая смена приоритетов со стороны стейкхолдеров, сегодня добавляем фичи, завтра всё бросаем и переделываем. Или недостаточное финансирование, банально кончатся деньги на половине проекта. Ещё риск в неправильных требованиях.
Внешняя среда. То, на что мы не можем влиять, но должны учитывать. Например, изменения в законодательстве. Или действия конкурентов, экономическая ситуация, пандемия, война, всё то, что извне может шарахнуть по нашему проекту.
Разделение на источники помогает при мозговом штурме: садимся и думаем, что может пойти не так в команде, в технологиях, в бизнес-среде и во внешнем мире. Так вы охватите максимум возможных проблем. Риски есть всегда в каждой категории, просто не всегда очевидны сразу.
Типы проявления рисков
Риск риском, но важно понимать, в чём конкретно будет ущерб, если он реализуется. Для Delivery Manager основными мерилами успеха проекта обычно являются время, качество и результат/цель. Исходя из этого, выделим три типа последствий:
Задержка (срыв сроков). Проект затянется, дедлайн уедет. Например, командный риск увольнения ведущего разработчика проявится как задержка – новый человек долго входит в курс. Риск новой технологии может проявиться тоже задержкой.
Снижение качества. Риск, который приводит к тому, что продукт работает хуже, чем должен. Например, риск сокращения бюджета может заставить урезать тестирование, в итоге больше багов, качество упало. Или риск техдолга, мы вроде в срок успели, но качество кода и стабильность системы страдают.
Полный стоп (срыв поставки). Худшее – проект вовсе не будет завершён или придётся поставить что попало. Здесь речь о риск-явлениях, убивающих саму возможность достичь цель. Например, риск внешней среды, внезапно регулятор запретил наш тип продукта, всё, проект можно хоронить. Или команда разбежалась, инвестор ушёл, поставка стопроцентно сорвана.
Один и тот же риск может иметь несколько типов проявления. Скажем, риск интеграционный API нестабилен в худшем случае может полностью стопнуть запуск фичи. В мягком случае вызовет задержку (будем долго дебажить) и снижение качества (в обходные пути наделаем костылей). Поэтому, классифицируя, помечайте, чем именно грозит риск: временем, качеством или финалом.
Все это нужно, чтобы правильно расставить приоритеты. Риски полного стопа – самые проблемные, им внимания максимум. Риски по качеству тоже важны, но, возможно, бизнес скажет,что главное вовремя, а баги потом поправим, тогда вы осознанно принимаете качество-риск. Всё это решения, и DM должен видеть, какой вид риска он берёт на себя.
Стратегии реагирования
Риски обнаружены и описаны. Дальше решаем, что с каждым делать. Классически в управлении проектами выделяют 4 стратегии работы с риском:
Принятие. Признаём риск и не делаем ничего особого, просто продолжаем работу, наблюдая. По сути, риск есть, осознаём, но живём с ним. Например, команда сообщает, о том что у нас есть технический долг, потенциально может замедлить разработку. DM оценивает и решает, что пока принимаем, в этом спринте всё равно времени нет рефакторить, справимся, риск задержки приемлем.
Смягчение. Предпринимаем меры, чтобы уменьшить вероятность или влияние риска. Самое распространённое, что приходит в голову при слове управление рисками. Например, видим риск, что новый разработчик может не справиться, тогда даем ему ментора, проводим ревью тщательнееб снижаем вероятность ошибок и их влияние.
Эскалация. Если риск выходит за рамки нашей ответственности или полномочий, мы поднимаем вопрос на уровень выше. DM эскалирует на спонсора, на руководство. Эскалация не устраняет риск напрямую, но привлекает более сильные ресурсы или внимание тех, кто может решить.
Трансфер. Передаём риск на сторону, через контракты, страховки, аутсорс. Например, риск юридических проблем можно частично передать, наймя юридическую фирму, которая возьмёт ответственность. Или риск простоя инфраструктуры, заключаем договор с облачным провайдером.
Иногда выделяют ещё избегание. Когда мы принимаем решение вообще не входить в ситуацию, ведущую к риску. Но в контексте DM обычно проект уже идёт, и избежать, значит убрать часть функционала или полностью поменять план.
На каждый существенный риск должен быть выбран и задокументирован один из этих подходов. И не навсегда, стратегия может меняться по ходу проекта. Сначала, допустим, риск принимаем, потом он растёт, решаем смягчение подключить.
Технический долг
Теперь возьмём технический долг. Обычно разрабы говорят о нем: вот, накопился долг, надо бы рефакторить, а то плохо всё... С точки зрения кода это проблема качества. Но DM должен перевести это на язык рисков.
Технический долг относится к категории технологии, проблема в кодовой базе, архитектуре. Но корни могут быть и в команде (например, не хватает навыков писать чисто, потому и долг) и в бизнесе. Однако классифицируем его именно как технологический риск.
Типы проявления:
Задержка. Техдолг почти гарантированно бьёт по срокам новых фич. Каждый следующая задача делается медленнее, потому что приходится разгребать легаси. Если риск не адресовать, проект может начать сильно буксовать, сроки релизов поползут.
Снижение качества. Накопленный долг = кривой код = баги, уязвимости, падения. Продукт начинает работать хуже, пользователи страдают, поддержка завалена тикетами. Таким образом, риск техдолга реализуется как риски качества: недовольный заказчик, худшие метрики.
Полный стоп. И до такого доводит. Если долг критический, команда может просто отказаться внедрять что-то новое, слишком сложно, систему ломает, все взаимосвязи спутаны. В итоге фича не реализуется принципиально, проект останавливается или требует многомесячного ремонта, перед тем, как двигаться дальше. Это худший сценарий.
Один долго, а закрывает все три типа риска.
Стратегия ответа:
Сначала DM должен признать технический долг как риск. Назвать вещи своими именами: да, у нас риск задержек и падения качества из-за состояния кодовой базы. Занести в риск-реестр.
Далее решить, что делаем. Допустим, пока срок релиза жёсткий, и бизнес не даёт времени на рефакторинг. Возможно, на ранних этапах риск принимается, осознанно идём на то, что качество подупадёт, но ставим другую приоритетную цель. Однако, принимайте, наблюдайте. Нужно мониторить показатели: скорость команды, количество багов. Как только видим тревожные звоночки, время менять стратегию.
Смягчение. В контексте техдолга это, очевидно, погашение долга, выделяем время в спринтах на рефакторинг, пишем тесты, улучшаем архитектуру. DM здесь важно обосновать бизнесу: тратим время сейчас, чтобы снизить риск срыва потом. Адекватный бизнес поймёт. Тут же митигация может включать привлечение дополнительных ресурсов: может, нанять эксперта, который распутает самое узкое место? Это тоже снижение риска.
Эскалация. Бывает, что команда бьёт тревогу, а руководству всё равно. Если вы, как DM, убеждены, что риск серьезный, ваша задача донести до высшего руководства. Эскалация может выглядеть как отчёт о состоянии проекта с акцентом: , что технический долг достиг такого уровня, что угрожает сорвать поставку X к Y дате”. Цель в том, чтобы заручиться поддержкой на самом верху для выделения времени/ресурсов.
Трансфер. Технический долг на сторону не отдашь, код ваш. Но элемент трансфера может быть, например, часть муторной работы отдать внешней команде. Тогда риск частично переходит к ним, правда, за качество внешней работы вы тоже рискуете, так что будьте осторожны.
В итоге тех. долг превращается в понятный риск менеджерского уровня, риск задержки и снижения качества из-за накопленных дефектов архитектуры. Такой формулировкой легче оперировать на совещаниях, с бизнесом, все понимают, чем черевато.
Итоги
Предвосхищая вопрос: а зачем вообще вся эта классификация? Не проще ли списком выписать, что может случиться, и придумать, что делать? Проще, но чревато. Когда риски не систематизированы, велик шанс что-то пропустить.
С помощью схемы мы:
Покрываем всю картину. Любой риск можно разложить по этим измерениям. Например, потеря экспертизы из-за ухода сотрудника = источник: команда, тип: задержка, стратегия: смягчение.
Общаться с разными стейкхолдерами на понятном им языке. С командой говорим про конкретные проблемы, с бизнесом про сроки и качество. При эскалации про стоп-факторы. Все эти грани одного риска, и нужно держать их в голове.
Приоритизировать. Структура сразу показывает, какие риски критичнее. Если что-то угрожает полным стопом, то оно уйдёт в топ списка, даже если вероятность мала. Если риск чисто по качеству возможно, можно принять в краткосрочной перспективе.
Документировать и учиться. Формализованная таксономия удобна для отчетов. Проект закончился, можно проанализировать: сколько у нас было рисков в категории команда, сколько технологии, какие стратегии чаще срабатывали.
Классифицируя риски, вы планируете наперёд: что буду делать, если X случится? А если Y?.
Риск-менеджмент — самая сложная часть работы DM, потому что тут нужно и технику знать, и людей понимать, и бизнес чувствовать. Универсальной формулы нет. Но структурированный подход, как описанный, даёт каркас, чтобы не забыть ничего важного.
Пусть ваши поставки будут details, predictable, fabric и successful.
Работа с рисками — одна из тех зон, где Delivery Manager быстро ощущает разницу между «координирую задачи» и «руковожу поставкой». Если хочется системно укрепить именно эту часть практики — в курсе Delivery Manager разбирают архитектуру процессов, работу с большими командами и инструменты, которые помогают держать под контролем сроки, качество и риски в портфеле проектов. Это хороший способ превратить разрозненный опыт в устойчивую управленческую систему.
Если хотите понять формат обучения — записывайтесь на бесплатные демо-уроки от преподавателей курса:
27 ноября: «Антикризисный Delivery: как управлять проектами, когда всё идёт не по плану». Записаться
3 декабря: «Зачем нужен Delivery Manager, если есть Project и Product?». Записаться