Эскалация. Казнить нельзя помиловать.
Дедлайн прошёл. Только теперь инженер идёт к своему руководителю: у нас проблема, подрядчик не отвечает, мы сроки сорвали, заказчик в гневе.
Почему руководитель узнал о проблеме тогда, когда её уже нельзя было решить, а не тогда, когда она только появилась? Рискну предположить потому что инженер считал эскалацию признанием собственной беспомощности. "Сначала попробую сам, ну а если совсем не получится, тогда уже дёрну руководителя". Знакомая логика, да? Что? совсем не знакома? Хочется спросить "Саш, что ты мелешь?" Ну ок, а если так: Чернобыль. Вокруг реактора уже валяются куски графита с крыши, а Дятлов продолжает утверждать, что реактор цел. Так нагляднее? Это и есть эскалация в режиме "я разберусь сам, просто чуть попозже скажу". Ну как, клёво разобрался?
Эскалация вполне нормальный инструмент для ситуаций, где решение зависит от кого-то за пределами ваших полномочий. Подрядчик не отвечает, другая команда блокирует работу своим приоритетом, заказчик не даёт данные, нужное решение выше вашего уровня доступа. В каждом из этих случаев эскалация остаётся порой единственным рабочим инструментом.
Разница между плохой и хорошей эскалацией примерно такая же, как между жалобой и отчётом. Плохая звучит как "Ваш этот @username, ничего не делает, решите". Сразу глаза кровью наливаются и хочется отправить в пешее эротическое путешествие. Потому как это очевидное перекладывание проблемы.
Готовьте эскалацию с нормальной структурой: вот проблема, вот её влияние на срок или результат, вот что мы уже пытались сделать, вот варианты решения, вот что конкретно нужно. Эта версия сохраняет за вами инициативу и просит конкретное решение, а не сочувствие. Если у вас нет ответа на "что уже сделано", возможно, ещё рано эскалировать. Если у вас нет вариантов и просите просто "разрулите", вы перекладываете свою работу, а не эскалируете.
Давно ставшая мемом фраза "Хьюстон, у нас проблема" ровно та структура, о которой я говорю: коротко, без нытья, сразу суть. Экипаж не сидел молча, гадая, показалось им или нет. Проверили приборы, убедились, что теряют кислород и мощность, и тут же вышли на связь. Потому что чинить взорвавшийся бак в открытом космосе в одиночку не входит даже в самый упоротый список должностных обязанностей. Эскалировали меньше чем через минуту после взрыва. И выжили.
Эскалируйте по триггеру, а не по ощущению. Если решение вне вашей зоны влияния, если блокировка тормозит другую команду, если дедлайн под явной угрозой, это триггер, а не повод "подождать ещё немного". И это принципиально другая позиция, чем "я не справился". Провала здесь нет!
Эскалируйте, пока есть варианты выбора, а не когда вариант остался один: сообщить о том, что всё уже сорвано. Главная ценность эскалации в том, что она даёт время среагировать!
Вспомните последнюю ситуацию, где вы неделями пытались решить проблему сами, прежде чем сказать о ней наверх. Посчитайте, сколько дней прошло между появлением проблемы и моментом, когда о ней узнал руководитель. Если разница больше пары дней, значит, в вашей компании эскалация до сих пор воспринимается как признание в собственном непрофессионализме.
· 27.08
Триггер работает только когда он не в голове инженера, а в самой задаче. Дата, после которой эскалация обязательна, ставится при постановке, и напоминает система, а не совесть. Второе - у эскалации должен быть адрес. Не "наверх", а конкретный человек и срок его ответа. Без этого даже хорошо оформленная эскалация уходит в пустоту. И проверка на культуру простая. Если за последний год хоть кого-то отчитали за раннюю эскалацию, дальше можно не настраивать - люди считают риск быстрее, чем читают регламент.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· вчера
Про триггер в системе согласен, дату эскалации стоит фиксировать при постановке, это точно надо обговаривать на старте. Но не соглашусь, что это само по себе отключает психологические блокираторы. Система напомнила, а человек всё равно тянет... «ну ещё пару минут\часов\дней». Дело не только в постановке задачи, а в страхе или упрямстве. Триггер снимает вопрос "когда", а не вопрос "решусь ли". Про адрес, ну тут как посмотреть. Во например PM на проекте, адресатом может быть его непосредственный руководитель? Может. А может быть сейл, через которого он давит на заказчика? Может. А может проектный офис? Да конечно может. Адрес почти всегда не универсален, и просто прописать одного адресата заранее не получится. Я склоняюсь к тому что нужен регламент и здравый смысл самого исполнителя, чтобы понять, кому конкретно в той или иной ситуации эскалировать. Ну а насчёт культуры...Подписываюсь без всяких "но". Тем, кто сначала просит эскалировать, а потом ругает за это, помогает только лоботомия.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· вчера
Про блокираторы соглашусь. Триггер не лечит страх, он меняет только одно - кто несёт риск молчания. Пропущенная дата в задаче становится видимым событием, а не личным решением. Страх остаётся, но перестаёт быть бесплатным. Про адрес - да, универсального нет. Поэтому я бы писал его не в регламенте, а в самой задаче, рядом с датой: кто снимает вот эту блокировку. Тогда адресат определяется на трезвую голову при постановке, а не в момент, когда уже горит. Регламент даёт рамку, но выбирать в панике по нему всё равно никто не будет.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· вчера
Дмитрий, "страх остаётся, но перестаёт быть бесплатным" - хорошая формулировка, но позволь уточню. В бизнесе бесплатных действий вообще не бывает, это фундамент в основе любой бизнес-культуры. Молчание никогда было бесплатным, просто цена была отложенной и невидимой, а не нулевой. Триггер не создаёт эту цену из ниоткуда - он переносит её из будущего, когда всё рвануло. Зрелый живой процесс - это не просто рамка, а, если позволишь, план эвакуации при пожаре. Он существует именно потому, что кто-то уже посчитал риски и митигировал базовые сценарии заранее. Про адрес в задаче. Это хорошо работает там, где риск повторяемый и предсказуемый, например в эксплуатации. В проектах чаще, увы, зависимость всплывает внезапно. Полагаю, тут вопрос предсказуемости. Где риск известен - фиксируй адрес при планировании или постановке задачи. Где риск нельзя предсказать заранее - нужна процедура выбора адреса в моменте.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён