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

Не апокалипсис, а рядовая ситуация: зачем управлять рисками

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

Угрозы разделяют на внешние и внутренние, при этом отдельно выносим «черных лебедей» — обстоятельства непреодолимой силы. Грамотно составленная карта рисков не делает наступление риска невозможным. Скорее, подкладывает соломку в те места, где проект выглядит наиболее тонко. Опыт и готовые шпаргалки помогают воспринимать наступление риска не как апокалипсис, а как рядовую, хоть и неприятную, ситуацию.

Это черный лебедь, он ждет удачного момента, который будет неудачным для нас. © David Clode/Unsplash

Не все риски можно и нужно нивелировать

Угрозы делятся по значимости: от низкой до высокой. Обычно в компании или отдельной команде разрабатывают собственный грейд, где самый низкий приоритет присваивается тому риску, который готовы игнорировать, а самый высокий — пожару или катастрофе. Если угроза внешняя и исходит, например, от регулятора, для её оценки потребуется понимание потерь. Бывает, что, несмотря на кажущуюся важность, компания готова принять риск и не корректировать продукт в угоду репутации или прибыли. Обычно при разработке заранее определяют риск-аппетит — это максимальный уровень угрозы, на который готовы пойти.

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

Как управлять рисками

Процесс управления рисками состоит из 5 этапов:

1. Идентификация факторов риска.
2. Оценка и обработка рисков.
3. Разработка стратегии управления рисками.
4. Реализация мер по управлению рисками.
5. Мониторинг и контроль.

Раскроем пункты подробнее.

Идентификация факторов риска: как выявить возможные угрозы

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

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

Оценка и обработка рисков: как проанализировать риски

Подобно тому, как для оценки эффективности используют метрику KPI (key performance indicator), для риска тоже разработали метрику — KRI (key risk indicator), которая рассчитывается в зависимости от:

• угроз, которые идентифицированы и учтены;
• аппетита к риску в компании.

В карте рисков присваиваем каждой угрозе количественный и качественный показатель. Под количеством подразумеваем частотность наступления риска. Например:

• 1 — на Землю упадет астероид, человечество прекратит существование, и проект закроется.
• 10 — разработчик Петя простудится на корпоративе и задержит сдачу своей части работы.

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

Лайфхак: задавайте бизнесу, себе и команде вопрос: для чего мы делаем разработку? Риски, которые влияют на достижение цели продукта, будут наиболее значимыми.

Отрицание, гнев, торг, депрессия и принятие: как управлять рисками

Лайфхак: ответьте на вопрос, что мы будем делать, когда риск реализуется?

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

1. Избегание. Стратегия, в которой всеми силами избегаем риска, и наша карта мер включает все возможные шаги, которые не позволят угрозе случиться. Пример: усиливаем команду дополнительными специалистами, если понимаем, что сроки сорвутся.
2. Снижение. Минимизируем влияние риска на проект. Здесь мы прорабатываем контрмеры и возможные документы и регламенты, чтобы, если угроза случится, последствия не потопили проект. Пример: если заказчик может уйти с рынка, заблаговременно продумываем альтернативы, чтобы не потерять основной источник прибыли.
3. Передача. В этой стратегии мы передаем риск третьей стороне. Пример: делаем заказчика материально ответственным за изменения требований.
4. Принятие. Выбираем ничего не делать, и не потому, что на команду разом напало смирение и фатализм. Возможная причина — потери при реализации риска кратно ниже профита в том или ином виде.

Лайфхак: закладывайте в бюджет статью на непредвиденные расходы.

Управление проектами в IT — это работа с высоким уровнем неопределенности. Даже если вы тщательно проработали возможные риски, меры митигации, а команда состоит только из профессионалов, все равно что-то пойдет не так. Именно поэтому при оценке сроков и ресурсов закладывайте в среднем +20% от финальной стоимости.

Как мониторить и контролировать риски

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

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

Также важно наладить эффективную и системную коммуникацию: без нее не выстроить работу. А без консистентного понимания всех членов процесса того, куда мы идем, сформировать адекватную карту рисков будет сложно. Здесь выстроить коммуникацию мне помогают инструменты:

• Followup/agenda.
• Матрица коммуникаций.
• Карта эскалаций.
• Шаблон для сбора БТ.
• Дайджест релиза/разработки.

Инструменты и программы для управления рисками

Визуализировать и управлять рисками помогают инструменты: от флипчартов и листов бумаги до специализированного ПО. Руководители проектов используют цветовую матрицу, диаграммы «галстук-бабочка», Исикавы и Парето, контрольные карты Шухарта, контрольные листы.

В специализированном софте среди российских решений выделю: АВАКОР, RISKGAP, 1С:ERP. Управление холдингом, а среди зарубежных: Vendor360, Resolver, nTask.Не стоит забывать, что инструмент должен служить цели и быть удобным. Часто доски в Miro или Google-таблицы уже достаточно.

Черный лебедь для IT: пример успешного управления рисками

Поделюсь историей об изменениях в логистических цепочках, которые произошли в 2022 году. Это был огромный черный лебедь для всего российского рынка IT. Я хорошо помню это время: каждый день что-то менялось, и каждый день — в худшую сторону. Проблемы с поставками ощутились через полгода, когда запасы на складах исчерпались. С одной стороны, компании искали, как оплатить товар, с другой — способы этот товар доставить.

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

Ахиллесова пята работы: пример провала и выводы из ошибки

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

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

1. Чем больше спешите, тем выше вероятность наломать дров.
2. Иногда отсутствие человека лучше, чем какой-нибудь человек.
3. Делайте выводы из наблюдений, не игнорируйте факты и, наконец, действуйте.

Вместо вывода

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

В работе задавайте вопросы:

• Для чего мы делаем разработку?
• Что мы будем делать, когда риск реализуется?

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