Как AWS управляет рисками в DS проектах

Том Де Марко в книге “Вальсируя с медведями” утверждал, что “Управление рисками – это управление проектами для взрослых.”

Если вы с таким же пиететом относитесь к риск менеджменту, то подход, описанный в “Managing Machine Learning Projects” вам точно понравится.

Автор — V.M. Megler, PhD, Principal Data Scientist @ AWS. Она придумывает в AWS методы и индустриализирует их в компании.

Подобно Де Марко, Вероника основной упор делает на управлении рисками. Как она предлагает с ними работать?

Для каждого проекта создается Scorecard — список рисков. Это список из заранее определенных рисков (Вероника предлагает этот список в статье).

Риски автор разбивает на 4 группы: project (что-то вроде бизнес-рисков), financial (финансовые риски), Data Quality, project processes (что-то что, можно потерять в процессе разработки).

На фазе старта (Inception) проекта по всем рискам проходятся и отмечают их состояние следующим образом:

• Риска нет — письменно обосновывают и отмечают “does not apply”
• Если риск есть — указывают потенциальное влияние (impact), как риск митигировать и отмечают как does apply. Риск может быть внешним и тогда его нужно эскалировать.

Проводятся регулярные ревью, на которых обновляют статус риска. Быстро проверяют риски из “does not apply” — не всплыл ли старый риск? Статусы (пере)отмечают цветами от red-yellow-green по их критичности .

Потом данные по всем рискам группируют в summary для репортинга руководству.

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

• research (quick and dirty, кучу методов пробуем)
• development (есть понятный метод решения, фокус на выведении в прод)

Разделение имхо жестковатое (по крайней мере в такой постановке) и замедляет работу над продуктом — иногда может стоит и самый первый бейзлайн вывести в прод. Кажется, автор тоже что-то такое подозревает, так как описывает какие проблемы такое разделение может вызвать.

Не уверен, что описанный подход широко применяется в AWS, никаких указаний на опыт или успехи команд не приводится. Впрочем, документ интересный, список рисков как минимум имеет смысл посмотреть и подумать.

https://d1.awsstatic.com/whitepapers/aws-managing-ml-projects.pdf