В инженерии есть правило: перед критичным действием — pre-check.
Скрипт не спрашивает “как ты, код?”.
Он проверяет факты — и либо запускает процесс, либо останавливает его.
С людьми в компаниях всё наоборот: перед задачами с высокой ценой ошибки мы часто полагаемся на “кажется, я норм”.
Ниже — два условия, при которых “чек состояния” становится допуском к работе, а не корпоративной формальностью.
Идея простая: вы перестаёте гадать про ‘самочувствие’ и начинаете снижать вероятность ошибок до того, как они случились.
Pre-flight check для кода и для человека: одна и та же логика
В инженерии никто не доверяет “ощущениям” системы перед критичным действием.
Перед сборкой, тестами или деплоем стоит pre-check: набор проверок, который отвечает на один вопрос:
“Система в корректном состоянии, чтобы вообще начинать?”
Если проверки не пройдены — операция не стартует.
Потому что цена ошибки слишком высокая.
Pre-check работает потому, что проверяет не “ощущения”, а условия безопасного старта.
Если условие не выполнено — система либо не запускает процесс, либо переводит его в безопасный режим.
Тот же принцип применим к людям: вместо “настроения” фиксируем маркеры риска и запускаем/не запускаем high-stakes действие по пороговому правилу.
Условие №1. Вместо “мнения” — якоря и факты
В прошлой статье мы разобрали, почему самооценка зачастую врёт.
Самая частая ошибка чеков состояния — спрашивать субъективное мнение.
Мнение в просадке неточное. А в компании ещё и социально искажённое.
Решение: заменить “оценку ощущения” на факты и якоря, чтобы человек не гадал, что значит “3 из 5”.
Как это выглядит
Вместо:
“Оцени стресс по шкале 1–5”
Делаем:
1) Факты (да/нет)
- Сон меньше 6 часов?
- Есть раздражение/злость прямо сейчас?
- Хочется ‘быстрее закрыть’ и не перепроверять?
- Внимание не держится на одной задаче или “скачет” каждые 2–3 минуты?
- Есть телесный маркер напряжения (челюсть/плечи/дыхание)?
Это маркеры про наблюдаемое поведение и симптомы, которые статистически повышают вероятность ошибок, конфликтов и импульсивных решений.
Мы не доказываем ‘истину’, мы ловим маркеры повышенного риска — как в инженерных чекапах.
2) Якоря к шкале
- 1/5 — “туман в голове, много ошибок на мелочах”
- 3/5 — “могу работать, но медленнее; нужна перепроверка”
- 5/5 — “чистая голова, устойчивый фокус, решения принимаются спокойно”
Человек перестаёт “угадывать” цифру.
Он сверяет себя с описанием.
Условие №2. Честность должна быть выгодной: чек → действие, а не чек → отчёт
В корпоративной среде честность не работает не потому что люди “врут”.
А потому что у честности нет выгоды.
Если после чека ничего не происходит, он превращается в ритуал.
Если “не допущен” создаёт риски (“лишние вопросы”), человек выбирает формально положительный ответ.
Решение: чек должен сразу выдавать решение и конкретное действие.
Как это выглядит
Зелёная зона:
“Ок, работаем как обычно.”
Жёлтая зона:
“Есть риск ошибок. Компенсации: чек-лист, вторая проверка, меньше многозадачности, медленнее темп.”
Красная зона:
“Не заходи в high-stakes задачу сейчас. Сначала протокол снижения риска (2 минуты). Потом повторный чек и решение.”
В рабочей системе ‘красная зона’ — это не метка слабости, а стандартная защита от ошибки: как ‘не деплоим без тестов’.
И главное: это можно калибровать.
После high-stakes задачи фиксируете факт: был инцидент/переделка/ошибка/конфликт / срыв дедлайна или нет — и уточняете пороги под реальную работу команды.
1 раз в неделю смотрите связку: маркеры → инциденты. Если при ‘жёлтой зоне’ инциденты повторяются — порог ужесточается. Если при ‘красной’ инцидентов нет — порог смягчается.
Ключ: система не “фиксирует состояние”.
Она управляет следующим шагом.
Пороговое правило: чтобы решение было не “по ощущениям”
Без порогового правила это не допуск. Это опрос.
Нужно чёткое правило, как в инженерии:
- если порог пройден — работаем
- если нет — включаются компенсации или откладываем high-stakes действие
Примеры порогов
- “если общий показатель ниже X — high-stakes действие не стартует”
- “если два критичных маркера в красной зоне — сначала протокол стабилизации”
- “если жёлтая зона — обязательна перепроверка/вторая пара глаз”
Для трейдинга порогом может быть “общий индекс состояния < 3.5 → не входить в рынок”.
Для IT-релиза — “красный маркер по Фокусу или Контролю → отложить деплой на 1 час”.
Главное — правило должно быть конкретным и не зависеть от настроения в моменте.
Порог задаётся под процесс и роль: релиз/дежурство/переговоры.
Итог
Чтобы “допуск по состоянию” работал, а не превращался в формальность, в нём должны быть две базовые инженерные детали:
- Якоря и факты вместо расплывчатого “как ты себя чувствуешь?”
- Честность выгодна: чек сразу даёт решение и действие, а не уходит в “отчётность”
- Пороговое правило: решение не зависит от настроения
Это делает процедуру допуска устойчивой к человеческой природе.
Следующая статья серии
Как внедрить допуск за 2 недели и не убить доверие: два сценария.
Разберём, почему при неправильном внедрении система умирает (люди начинают “отмечаться”), и как сделать так, чтобы статус “красная зона” (не готов к high-stakes задаче) защищал сотрудника, а не превращался в инструмент контроля.