«Есть определённые риски по срокам» — фраза вроде бы осторожная. Только после неё всё ещё непонятно, что именно может случиться, от чего это зависит и что с этим делать.
Цели
Как объяснить риск проекта без тумана из «может быть»
Назовите, что именно может случиться, при каком условии, что это изменит и какое действие или решение потребуется. Не прячьте риск за расплывчатыми формулировками.
Локальный инструмент
Соберите карточку перед записью
Начните с главной мысли. Добавьте только нужные слушателю детали. Ptichi не интерпретирует и не отправляет ваш текст.
Интерактивная карточка пока не работает. Упражнение ниже можно выполнить со своими заметками и диктофоном.
Для рабочего разговора полезнее собрать риск из четырёх частей:
событие → условие → последствие → действие.
Например:
Если доступ не подтвердят до 14:00, мы не начнём тест сегодня. Тогда окно запуска в пятницу окажется под риском. Сейчас эскалируем доступ; в 14:30 дадим новый статус.
Здесь риск не стал страшнее. Он просто перестал быть туманом.
Риск — это не уже случившаяся проблема
Сравните:
Если поставщик не пришлёт файл до четверга, мы не успеем проверить данные к пятничному запуску.
Это риск: событие ещё может не произойти.
А вот:
Поставщик не прислал файл в четверг. Проверку переносим; новую дату запуска подтвердим после получения файла.
Это уже текущая проблема или задержка.
Называть случившийся факт «риском» иногда звучит мягче. Для управления ситуацией от этого обычно не легче.
Если событие уже произошло, полезнее перейти к объяснению задержки, а не продолжать говорить о возможности.
Укажите условие, а не только тревожный ярлык
Есть риск по срокам.
Сообщение короткое, но пользоваться им трудно.
Срок пятничного запуска под риском, если тест восстановления не пройдёт сегодня до конца дня.
Теперь слушатель знает, что именно отслеживать.
Условие особенно важно, когда риск не требует действия прямо сейчас. Тогда вместо общего «держим на контроле» можно назвать триггер:
Пока действий от вас не нужно. Если нагрузочный тест вечером не пройдёт, завтра утром вынесем решение по дополнительной мощности.
Скажите, что изменится, если риск реализуется
Техническое описание риска может быть правильным и всё равно бесполезным для человека вне вашей команды.
Есть риск повторной блокировки очереди при параллельной обработке.
Для технической команды этого может быть достаточно. Для владельца процесса понадобится последствие:
При повторной блокировке часть загрузки остановится и пятничное окно может сдвинуться. Проверяем сценарий сегодня; до 17:00 будет понятно, нужна ли дополнительная остановка обработки.
Не нужно убирать технический термин любой ценой. Нужно довести объяснение до того уровня, на котором слушатель понимает решение.
Не придумывайте вероятность ради солидности
Вероятность срыва — 70%.
Число выглядит серьёзно. Но если никто не может объяснить, откуда оно взялось, это декоративная математика.
Если надёжной оценки нет, так и скажите:
Вероятность сейчас не оцениваем. Ключевая проверка — вечерний тест; после него станет понятно, остаётся ли пятничное окно реалистичным.
Неопределённость не обязательно нужно лечить процентами.
Что требуется от слушателя
Перед созвоном определите, какой из вариантов у вас сейчас:
| Ситуация | Что сказать явно |
|---|---|
| Только информировать | Что может произойти и какой сигнал вы отслеживаете |
| Нужен выбор способа снижения риска | Какие варианты есть и чем они отличаются |
| Нужное решение | Что нужно решить и к какому моменту |
| Нужна эскалация | Почему текущая команда не может удержать последствие сама |
| Пока действий нет | Какой факт станет следующим триггером |
Иначе сообщение о риске легко превращается в устное чтение risk register. У risk register уже есть жизнь. Не обязательно давать ему ещё и сольный номер.
Репетиция на один риск
Возьмите один реальный, но не конфиденциальный риск и запишите короткое объяснение как сказали бы обычно.
При прослушивании попробуйте восстановить четыре вещи:
- Что именно может произойти?
- При каком условии или событии?
- Что это изменит для проекта, пользователя или решения?
- Что мы делаем сейчас или какой факт запускает действие?
Если одного элемента нет, во втором дубле добавьте только его. Не переписывайте одновременно темп, интонацию и весь текст.
Затем скажите тот же риск другими словами без списка перед глазами.
Проверка слушателем
Если можете дать запись коллеге, не показывайте ему свой план заранее. Спросите:
Что здесь может случиться? От чего это зависит? Что будет дальше?
Если человек услышал «всё плохо», но не может назвать событие и условие, драматическая серьёзность не компенсировала структуру.
Когда нужен другой формат
Если негативное событие уже произошло — это не риск, а текущая проблема; переходите к статусу или задержке.
Если требуется выбрать между вариантами снижения риска, одного короткого устного сообщения может быть мало: понадобятся данные, стоимость, последствия и обсуждение.
Если вероятность действительно измерена по понятной модели, не выбрасывайте её ради простоты — просто назовите источник оценки.
Ptichi должен помогать репетировать риск не как «тревожный голос», а как восстанавливаемое сообщение: что может произойти → от чего зависит → что изменит → что делаем дальше. Пока desktop-продукт не выпущен, тот же A/B-цикл можно сделать обычным диктофоном.
Что на этой странице можно проверить
На странице есть пример, написанный редакцией Ptichi специально для разбора и репетиции.
Что не подтверждает: Это редакционный пример, а не результат пользователя, эксперимент или доказательство эффективности Ptichi.
На странице есть ограниченное упражнение «записать — послушать — сравнить», которое можно выполнить с обычным диктофоном.
Что не подтверждает: Само упражнение не доказывает, что Ptichi улучшает речь или что второй дубль перенесётся на других слушателей и ситуации.
Проверено: