Сегодня пошел слух, что TG замедлят, поэтому самое время поговорить о рисках. Почти все крупные сбои в ИТ-проектах рождаются задолго до релиза. Не в коде и не в проде — а в требованиях, которые на первый взгляд выглядят вменяемо. Из-за этого меняется роль системного аналитика. Он всё чаще отвечает не просто за описание требований, а за системные риски ещё до того, как появится первая строка кода. Аналитик первый видит, где начинается неопределённость. И, по сути, последний, кто может убрать её без потерь. Настоящая работа с рисками начинается не с ТЗ, а с вопросов. Что будет, если требование поймут по-разному? Как мы вообще проверим, что сделали «хорошо»? Если эти вопросы не заданы, риск никуда не девается — он ждёт своего момента. Если заданы, риск становится управляемой частью требований. И в следующий раз, когда требование покажется мелочью, стоит спросить: какой риск за ним прячется? В приложении — чек-лист работы с рисками. Проверьте свой проект.