Реестр рисков внедрения глазами аналитика: как увидеть проблемы до релиза
На внедрении 1С проблемы редко появляются внезапно. Чаще они долго лежат на поверхности, просто их никто не называет рисками.
Заказчик “потом даст пользователей для тестирования”. Старые данные “как-нибудь перенесем”. По правам “разберемся ближе к запуску”. Интеграцию “проверим, когда будет готово”. Ключевой пользователь “сейчас занят, но потом посмотрит”. Процесс “в целом понятен”, хотя на встречах каждый отдел описывает его по-разному.
Все это уже риски. Только пока они не записаны, с ними трудно работать.
В 1С-проектах аналитик часто видит такие вещи раньше остальных. Она разговаривает с заказчиком, разбирает реальные процессы, уточняет данные, описывает сценарии, обсуждает права, согласует проверки и видит, где красивая схема начинает расходиться с реальной работой пользователей.
Но если аналитик держит риски только в голове, они быстро теряются в потоке задач. Сегодня кажется: “Надо не забыть про старые документы”. Через неделю уже новый созвон, новый срочный вопрос, новая доработка. А перед релизом оказывается, что старые документы не заполнены, пользователи не готовы, права не проверены, обмен не протестирован, а заказчик ожидал совсем другой результат.
Реестр рисков нужен не для красивого управления проектом. Он нужен, чтобы заранее видеть места, где внедрение может споткнуться.
Для меня реестр рисков — это не отдельная бюрократия. Это способ не держать тревогу в голове. Если я вижу слабое место, его лучше записать, назвать владельца и договориться о следующем действии. Иначе риск превращается в “я же говорила”, но уже после релиза.
В этой статье разберу, как аналитику 1С вести реестр рисков внедрения: какие риски фиксировать, как не превратить таблицу в формальность и как использовать ее в реальной работе с заказчиком, разработчиками, тестировщиками и руководителем проекта.
Риск — это не только “что-то плохое случилось”
Риск часто путают с уже случившейся проблемой.
Если пользователи не могут зайти в систему после запуска — это уже проблема. Если за две недели до запуска еще не проверены роли и права — это риск.
Если обмен с внешней системой падает на продуктиве — это проблема. Если интеграцию ни разу не проверяли на данных, похожих на реальные, — это риск.
Если руководитель заказчика отказался принимать результат — это проблема. Если критерии приемки не согласованы заранее — это риск.
Для аналитика важно видеть риски именно до того, как они превратились в пожар.
Я бы формулировала риск простым языком:
Риск — это условие, из-за которого внедрение может пойти не так, если заранее ничего не сделать.
Такое определение удобнее, чем формальные фразы из учебников. Оно помогает быстро понять, что нужно записывать в реестр.
Например, фраза “права потом посмотрим” на проекте звучит спокойно. Но если внедряется 1С:Документооборот, где доступ зависит от рабочих групп, ролей, грифов, участия в процессе и вложенных файлов, это уже не “потом”. Это будущая очередь обращений в поддержку.
Зачем аналитику свой взгляд на реестр рисков
На проектах реестр рисков часто ведет руководитель проекта. Это нормально. Но у аналитика свой ракурс.
Руководитель проекта чаще смотрит на сроки, ресурсы, бюджет, доступность команды, договоренности с заказчиком. Аналитик ближе к содержанию: процессам, данным, ролям, сценариям, ограничениям типовой конфигурации, качеству спецификации требований и реальным пользователям.
Именно аналитик может первой заметить:
- заказчик не может описать единый процесс;
- разные подразделения понимают один термин по-разному;
- старые данные неполные или грязные;
- права доступа обсуждаются слишком поздно;
- ключевые пользователи не участвуют в проверке;
- интеграция зависит от другой команды, но ее никто не подключил;
- критерии приемки звучат размыто;
- в спецификации требований много допущений, которые никто явно не подтвердил.
Если эти наблюдения не фиксировать, они остаются личной тревогой аналитика. А личная тревога плохо работает как инструмент управления.
Реестр рисков превращает тревогу в предметный разговор: вот риск, вот причина, вот возможные последствия, вот владелец, вот действие, которое нужно сделать.
Я не считаю, что аналитик должна отвечать за все риски проекта. Но аналитик точно может первой вытащить на поверхность риски по процессу, данным, правам, интеграциям и приемке. Это как раз та зона, где лучше сказать заранее, чем героически разбирать последствия после запуска.
Как отличить риск от обычного замечания
Не каждую мысль нужно записывать в реестр. Иначе он быстро превратится в мусорную таблицу, которую никто не открывает.
Я бы фиксировала риск, если есть хотя бы один из признаков:
- из-за этого может сорваться срок;
- потребуется существенная переделка;
- пользователи не смогут работать после запуска;
- будут искажены данные;
- может пострадать учет, отчетность или зарплата;
- будет нарушен доступ к закрытой информации;
- возникнет зависимость от другой команды;
- заказчик может не принять результат;
- после релиза поддержка получит поток обращений.
Например, “пользователь просит поменять название кнопки” — не всегда риск. А вот “пользователи из двух отделов по-разному понимают статус документа, и от этого зависит маршрут согласования” — уже риск.
Еще пример. “Нет финального варианта печатной формы” — может быть обычным вопросом, если срок не горит. Но если печатная форма нужна для запуска обмена или отправки документов контрагентам, это уже риск внедрения.
Здесь помогает простой вопрос: что будет, если мы ничего не сделаем? Если ответ звучит как “ничего страшного, уточним позже”, возможно, это просто рабочий вопрос. Если ответ звучит как “перед релизом придется срочно переделывать маршрут, отчет или обработку”, это уже риск.
Минимальная структура реестра рисков
Реестр рисков не должен быть сложным. Если для его заполнения нужно десять минут вспоминать методологию, им перестанут пользоваться.
Для практической работы мне достаточно такой структуры:
| Поле | Что писать |
| Риск | Что может пойти не так |
| Причина | Почему риск появился |
| Последствие | Что будет, если ничего не сделать |
| Вероятность | Низкая, средняя, высокая |
| Влияние | Низкое, среднее, высокое |
| Владелец | Кто должен помочь снизить риск |
| Действие | Что делаем для снижения риска |
| Срок | До какой даты нужно выполнить действие |
| Статус | Открыт, в работе, снижен, принят, закрыт |
Главное поле здесь — не вероятность и не влияние. Главное поле — действие.
Если в реестре есть риск, но непонятно, что с ним делать, это просто запись для тревоги. Хороший риск в реестре должен подталкивать к следующему шагу: провести встречу, запросить данные, согласовать владельца процесса, проверить права, подготовить тестовые сценарии, уточнить интеграцию.
Если у риска нет владельца и следующего действия, это не управление риском. Это просто строка в таблице.
Как формулировать риск, чтобы его поняли
Плохая формулировка риска звучит так:
“Есть риск по данным”.
Формально запись есть. Практической пользы мало. Непонятно, какие данные, почему риск, что будет, кто должен реагировать.
Лучше формулировать конкретнее:
В старых договорах не заполнен реквизит “Тип договора”. Если завязать новый маршрут на этот реквизит без заполнения истории, часть документов пойдет не по тому маршруту или не попадет в отчет.
Такая запись уже помогает действовать. Видно объект, причина, последствие и направление решения.
Еще пример плохой формулировки:
“Проблемы с пользователями”.
Лучше:
Ключевые пользователи бухгалтерии не выделили время на проверку сценариев в тестовой базе. Если проверку перенести на последние дни перед запуском, есть риск обнаружить ошибки уже после релиза.
В реестре рисков лучше писать живым рабочим языком. Не нужно усложнять фразы ради солидности. Чем понятнее запись, тем выше шанс, что ее реально обсудят.
Риск 1. Заказчик не описал реальный процесс
Один из самых частых рисков — работа идет по регламенту на бумаге, но не по реальному процессу.
На встрече заказчик уверенно рассказывает: “Заявка создается, руководитель согласует, бухгалтерия проверяет, потом документ идет в работу”. А когда просишь показать последние 3–4 реальные заявки, выясняется, что сначала все обсуждается в чате, потом кто-то правит Excel, потом документ создается задним числом, а в 1С фиксируется только финальная часть процесса.
Если автоматизировать только красивую схему со встречи, пользователи быстро найдут обходные пути.
На проекте это обычно всплывает не сразу. В тестовой базе все может выглядеть нормально, потому что проверяют “идеальный” сценарий. А после запуска пользователи начинают работать так, как привыкли: сначала согласовали в чате, потом завели документ, потом попросили “просто закрыть задачу, потому что уже договорились”.
| Риск | Описанный процесс не совпадает с реальной работой пользователей |
| Последствие | После запуска пользователи продолжат работать вне 1С, а система станет формальной |
| Действие | Проверить процесс на реальных примерах документов и согласовать фактический сценарий |
Что может сделать аналитик: попросить показать реальные документы, последние обращения, переписку по процессу, текущие Excel-файлы, роли участников и нестандартные случаи.
Обычно именно на реальных примерах всплывают детали, которые не попадают в регламент: замещение, ручное согласование, “сначала позвонить”, разные правила для филиалов, документы задним числом, отдельные договоренности с бухгалтерией или юристами.
Риск 2. Нет владельца процесса
Иногда на встречах много участников, но никто не принимает финальное решение.
Один отдел хочет один маршрут, второй — другой, руководитель подключается редко, ключевой пользователь говорит “мне так удобнее”, а разработка ждет понятной спецификации требований.
В такой ситуации аналитик легко оказывается между всеми. Она собирает мнения, пытается примирить противоречия, но не может сама принять бизнес-решение.
Самый неприятный вариант — когда решение вроде бы “все обсудили”, но никто не готов поставить финальную точку. Через неделю появляется новый участник, приносит другое мнение, и требования снова едут.
| Риск | Не определен владелец процесса, который принимает финальные решения |
| Последствие | Требования будут меняться, согласование затянется, результат могут не принять |
| Действие | Определить владельца процесса и зафиксировать порядок принятия решений |
Здесь важно не пытаться “дожать” решение самостоятельно. Аналитик может показать варианты и последствия, но владельца процесса должен определить заказчик.
Если владельца процесса нет, почти любая спорная ситуация возвращается к аналитику. А аналитик не должна заменять бизнес-ответственного. Она может помочь сформулировать решение, но не должна принимать его за заказчика.
Риск 3. Требования звучат как решение, а не как проблема
Заказчик часто приходит сразу с готовым решением: “добавьте кнопку”, “сделайте отчет”, “добавьте согласующего”, “дайте доступ всем руководителям”.
Иногда это действительно правильное решение. Но часто за ним скрыта другая проблема.
Например, заказчик просит новый отчет. После вопросов выясняется, что ему нужно не столько отчет, сколько контроль просроченных заявок. Возможно, достаточно настроить уведомления, вариант существующего отчета или дополнительный статус.
Выглядит мелочью, пока команда не сделала ровно то, что попросили, а бизнес через месяц не сказал: “Отчет есть, но проблему он не решает”.
| Риск | Команда реализует предложенное решение, не проверив исходную проблему |
| Последствие | Доработка будет сделана, но бизнес-проблема останется |
| Действие | Уточнить цель, ожидаемый результат и способ проверки результата |
Хороший вопрос в такой ситуации:
Что изменится в вашей работе, когда это появится в 1С?
Если после этого вопроса заказчик не может объяснить результат, с задачей лучше не спешить. Сначала нужно понять боль, а уже потом выбирать решение.
Риск 4. Старые данные не готовы к новой логике
Это один из самых неприятных рисков, потому что он часто всплывает поздно.
Добавили новый реквизит, новый статус, новую проверку, новый маршрут. На новых документах все работает. Потом пользователи открывают старые документы и видят пустые поля, неверные отборы, странные статусы или документы, которые не попадают в отчет.
Например, внедряется новый реквизит “Категория договора”. На новых договорах он заполняется, маршрут работает, отчет выглядит нормально. А потом руководитель просит отчет за прошлый год, и половина строк пустая. Не потому что отчет плохой, а потому что исторические договоры никто не заполнял.
В 1С старые данные почти всегда важны. Особенно если речь идет о договорах, кадровых документах, взаиморасчетах, заявках, процессах согласования или отчетности.
| Риск | Новая логика зависит от данных, которые не заполнены в старых документах |
| Последствие | Отчеты и маршруты будут работать только для новых документов, старые данные придется исправлять вручную |
| Действие | Решить, что делать с историей: не трогать, заполнить вручную, обработать автоматически, перенести только активные документы |
Я бы отдельно выносила этот риск почти во все задачи, где появляется новый реквизит или меняется логика обработки документов.
И здесь важно не просто написать “проверить старые данные”. Нужно договориться: какие документы считаем историей, какие переносим, кто проверяет заполнение, нужно ли делать обработку и что показываем в отчетах по старым периодам.
Риск 5. Права доступа обсуждаются слишком поздно
Права доступа часто оставляют “на потом”. Сначала обсуждают форму, процесс, отчет, маршрут. А потом на тестировании выясняется, что один пользователь не видит документ, второй видит лишнее, третий может изменить закрытые данные.
В 1С:Документообороте это особенно чувствительно: рабочие группы, грифы доступа, роли, участие в процессах, доступ к файлам. В ЗУП — кадровые и зарплатные данные. В БП — организации, бухгалтерские документы, закрытые периоды, регламентированный учет.
Живой пример из тестирования: администратор проверил сценарий, у него все работает. Потом заходит обычный согласующий и не видит вложенный файл. Или видит документ, но не может выполнить задачу. Или наоборот — пользователь видит больше, чем должен. Формально функционал готов, но для реальных ролей он не проверен.
| Риск | Модель доступа не согласована до разработки и тестирования |
| Последствие | Функционал готов, но пользователи не могут им пользоваться или получают лишний доступ |
| Действие | Согласовать роли, группы пользователей, доступ к документам, файлам, отчетам и действиям |
Права лучше проверять не абстрактно, а по ролям: инициатор, согласующий, руководитель, бухгалтер, кадровик, администратор, наблюдатель, внешний участник.
Риск 6. Интеграции вспоминают перед самым запуском
В 1С почти любое изменение может затронуть обмены. Документ уходит в другую базу. Реквизит передается во внешнюю систему. Статус приходит из ЭДО. Отчет строится по данным, которые загружаются регламентным заданием.
Если интеграции не обсудить заранее, можно получить неприятный сюрприз: в одной базе все работает, а обмен падает или передает неполные данные.
На практике это часто выглядит так: в пользовательском сценарии все проверили, карточка заполняется, отчет строится. А потом включают обмен, и выясняется, что новое поле не передается, формат не согласован, в другой системе такого значения нет, а ответственный за внешнюю систему вообще не участвовал в обсуждении.
| Риск | Изменение объекта 1С не учтено в интеграциях и обменах |
| Последствие | После запуска данные не передаются, передаются неверно или требуют ручной сверки |
| Действие | Проверить связанные обмены, ответственных за внешние системы и сценарии тестирования интеграции |
Вопрос, который стоит задавать почти всегда:
Эти данные куда-нибудь уходят или откуда-нибудь приходят?
Если ответ “да”, риск по интеграции лучше сразу занести в реестр. Даже если кажется, что изменение маленькое.
Риск 7. Пользователи не готовы проверять результат
На проектах часто считают, что пользователи подключатся к проверке “когда будет готово”. Но если они не видели сценарии заранее, не выделили время и не понимают, что именно проверять, приемка легко превращается в хаос.
Пользователь открывает тестовую базу, видит незнакомую форму, проверяет один простой случай и говорит: “Вроде работает”. После запуска начинаются реальные сценарии, исключения, разные подразделения, права, старые документы, печатные формы.
Например, ключевой пользователь проверил обычный договор на небольшую сумму. Все прошло нормально. А после запуска пошли договоры по филиалам, срочные согласования, замещения, возвраты на доработку, договоры с нерезидентами. И оказалось, что половина важных сценариев вообще не проверялась.
| Риск | Ключевые пользователи не участвуют в проверке до запуска |
| Последствие | Ошибки и неудобные сценарии обнаружатся на продуктиве |
| Действие | Согласовать список проверяющих, сценарии приемки, сроки проверки и тестовые данные |
Здесь важно заранее договориться, кто именно принимает результат. Не “бизнес посмотрит”, а конкретные люди по конкретным сценариям.
Риск 8. Нет понятных критериев приемки
Если критерии приемки не зафиксированы, результат легко становится бесконечным.
Команда сделала доработку по согласованной спецификации требований. Заказчик посмотрел и говорит: “Да, но мы еще думали, что будет уведомление”, “А почему старые документы не заполнены?”, “А почему в Excel не выгружается?”, “А почему в отчете нет группировки по подразделению?”.
Часть этих вопросов может быть разумной. Но если границы не обсуждали заранее, начинаются споры.
Выглядит как обычное уточнение, но по факту это уже расширение объема. И чем позже это всплывает, тем сложнее спокойно договориться.
| Риск | Критерии приемки не согласованы до разработки |
| Последствие | Результат будут дорабатывать без четкой границы завершения |
| Действие | Зафиксировать сценарии проверки, данные, роли, ограничения и то, что не входит в текущий объем |
Я бы всегда отдельно фиксировала, что не входит в задачу. Это не формальность, а защита от бесконечного расширения объема.
Хорошая фраза для согласования: “В этом этапе мы делаем маршрут, роли и отчет. Исторические документы, массовое заполнение и изменение обмена — отдельные задачи”. Иногда одна такая фраза экономит несколько недель споров.
Риск 9. Сроки согласованы без учета реальной занятости
Еще один частый риск — срок уже назвали, но никто не проверил доступность людей.
Аналитик занята другим проектом. Разработчик уходит в отпуск. Ключевой пользователь доступен только по пятницам. Тестировщик подключится после релиза другой задачи. Внешняя команда по интеграции отвечает раз в неделю.
Формально план есть. Фактически он держится на предположении, что все будут доступны в нужный момент.
В 1С-проектах это особенно заметно на стыке с бухгалтерией, кадрами и закрытием периода. В календаре задача стоит “на приемке”, а по факту пользователи заняты зарплатой, отчетностью или закрытием месяца.
| Риск | Сроки согласованы без учета доступности участников |
| Последствие | Задача будет стоять в ожидании ответов, проверки или разработки |
| Действие | Проверить доступность аналитика, разработчика, тестировщика, заказчика и внешних команд |
Этот риск особенно важен перед релизами, отпусками, отчетными периодами и закрытием месяца.
Если запуск запланирован на конец месяца, а в проверке участвует бухгалтерия, стоит заранее спросить, будет ли у них время. Иначе тестирование может совпасть с закрытием периода, и формально доступные пользователи фактически будут недоступны.
Риск 10. Пользователей не обучили новому процессу
Даже хорошая доработка может провалиться, если пользователи не поняли, как с ней работать.
Особенно если меняется привычный процесс: раньше писали в чат, теперь нужно создать документ; раньше согласовывали по почте, теперь через процесс в 1С; раньше отчет собирал один сотрудник, теперь данные должны заполнять все подразделения.
На тестировании это может не проявиться. Один ключевой пользователь проверил сценарий и все понял. А после запуска в процесс входят десятки обычных пользователей, которые не были на встречах, не видели обсуждений и не понимают, почему теперь нужно делать иначе.
| Риск | Пользователи не готовы работать по новому процессу |
| Последствие | После запуска будут ошибки, обходные действия и поток обращений в поддержку |
| Действие | Подготовить инструкцию, короткое обучение, примеры и канал для вопросов после запуска |
Иногда короткая инструкция с 5 скриншотами экономит больше времени, чем еще одна доработка интерфейса.
Если после запуска пользователи пишут “а куда теперь нажимать?”, это не всегда проблема интерфейса. Иногда это риск обучения, который просто не закрыли до релиза.
Как работать с реестром рисков на встречах
Реестр рисков бесполезен, если его заполнили один раз и забыли.
Я бы использовала его как рабочий инструмент на встречах:
- на обследовании — фиксировать первые риски по процессам, данным и ролям;
- при согласовании требований — проверять, закрыты ли вопросы по исключениям, правам, старым данным и интеграциям;
- перед разработкой — смотреть, нет ли открытых рисков, которые могут изменить объем;
- перед тестированием — проверять готовность сценариев, пользователей и данных;
- перед запуском — проходить по рискам с высоким влиянием;
- после запуска — смотреть, какие риски стали реальными проблемами и почему.
На встрече удобно обсуждать не весь реестр, а только открытые риски с высоким влиянием и те, по которым подошел срок действия.
Если риск висит без движения, нужно задать простой вопрос: мы его снижаем, принимаем или просто делаем вид, что он исчезнет сам?
Для меня хороший реестр рисков — это не таблица ради отчетности. Это список разговоров, которые нужно провести до релиза, чтобы потом не разбирать пожар в поддержке.
Кто должен быть владельцем риска
У каждого риска должен быть владелец. И это не всегда аналитик.
Если риск связан с отсутствием владельца процесса — его должен закрывать заказчик или руководитель проекта. Если риск связан с интеграцией — нужен ответственный за вторую систему. Если риск связан с правами — нужен человек, который принимает решение по доступам. Если риск связан с тестированием — нужен владелец приемки.
Аналитик может обнаружить риск, описать его и предложить действие. Но она не должна становиться владельцем всех рисков подряд.
Иначе получается ловушка: аналитик видит проблему, записывает ее, напоминает всем, пытается получить решения, а потом еще отвечает за то, что бизнес не выделил пользователей или внешняя команда не проверила обмен.
Реестр рисков помогает разделить ответственность. Не в смысле “найти виноватого”, а в смысле “понять, кто может реально повлиять на ситуацию”.
Пример простого реестра рисков
Ниже пример, как может выглядеть небольшой рабочий реестр рисков на 1С-проекте.
| Риск | Последствие | Владелец | Действие | Статус |
| Не согласован владелец процесса согласования договоров | Маршрут будут менять после начала разработки | Заказчик | Назначить владельца процесса и согласовать правила принятия решений | Открыт |
| В старых договорах не заполнена категория | Новый маршрут и отчет будут работать только для новых документов | Аналитик + заказчик | Решить, заполняем ли историю и за какой период | В работе |
| Ключевые пользователи не выделили время на приемку | Ошибки найдут после запуска | Руководитель проекта | Согласовать график проверки и список сценариев | Открыт |
| Не проверена передача нового реквизита в обмен | Данные не уйдут во внешнюю систему | Ответственный за интеграцию | Проверить формат обмена и тестовый сценарий | Открыт |
Такой реестр не выглядит сложно, но он уже помогает. По нему видно, где нужны решения, кто должен участвовать и что делать дальше.
Типовые ошибки при ведении реестра рисков
Первая ошибка — писать слишком общо. “Риск по срокам”, “риск по данным”, “риск по заказчику”. Такие записи не помогают действовать.
Вторая ошибка — записывать риск без владельца. Если неясно, кто может повлиять на ситуацию, риск будет просто висеть.
Третья ошибка — не указывать действие. Риск без следующего шага быстро превращается в фон.
Четвертая ошибка — вести реестр отдельно от реальной работы. Если риски не обсуждаются на встречах, не связаны со сроками и не влияют на решения, команда перестает воспринимать их серьезно.
Пятая ошибка — превращать реестр в инструмент давления. Если риски используют только для обвинений, люди начинают скрывать проблемы. А хороший реестр должен делать наоборот — помогать говорить о проблемах раньше.
Мини-чек-лист рисков для аналитика 1С
Перед важным этапом проекта я бы проходила по короткому чек-листу.
- Понятен реальный процесс, а не только регламент.
- Определен владелец процесса.
- Согласованы ключевые роли пользователей.
- Проверены исключения и нестандартные сценарии.
- Понятно, что делать со старыми данными.
- Согласованы права доступа.
- Проверены отчеты, отборы и поиск.
- Проверены интеграции и обмены.
- Есть критерии приемки.
- Понятно, кто проверяет результат.
- Пользователи готовы к изменениям.
- Есть план обучения или инструкция.
- Открытые риски имеют владельца и действие.
Этот чек-лист не заменяет полноценное управление проектом. Но для аналитика он хорошо работает как страховка от типовых проблем, которые всплывают ближе к релизу.
Итог
Реестр рисков внедрения — это не формальная таблица для руководителя проекта. Для аналитика 1С это способ заранее зафиксировать то, что может сломать процесс, сроки, приемку или работу пользователей после запуска.
Риски часто видны задолго до релиза: неясный владелец процесса, старые данные, спорные права, неподключенные пользователи, неучтенные интеграции, размытые критерии приемки, разные ожидания у подразделений.
Если эти вещи не записывать, они остаются в голове и всплывают поздно. Если записывать и регулярно обсуждать, у команды появляется шанс среагировать заранее.
Хороший реестр рисков не должен быть большим и сложным. Достаточно фиксировать риск, последствие, владельца, действие и статус. Главное — чтобы по каждой записи было понятно, что делать дальше.
Риск, записанный вовремя, часто дешевле любой срочной доработки после релиза.
Если аналитик видит риск и молчит, проект может узнать о нем слишком поздно. Если аналитик фиксирует риск и выносит его на обсуждение, это уже не тревога в голове, а управляемая часть внедрения.