После большого падения собрали постмортем. Красивый: таймлайн поминутно, five whys, список action items, ответственные напротив каждого пункта, всё разослали по всем спискам рассылки. Команда поскорбела, поучилась на ошибках, разошлась с чувством выполненного долга.

Через полгода — то же падение. По той же причине.

Открываем тот постмортем. А там — те же action items. Все до единого. Не сделан ни один. Зато оформлен был аккуратно: и таблички, и цвета, и owner проставлен.

Первая реакция на эту историю — «ну бардак, ну разгильдяи, не довели до конца». Реакция понятная и неправильная. Потому что если присмотреться, постмортем не провалился. Он отлично сработал. Просто работа у него была не та, что написана на упаковке.

Я вхожу в чужие инженерные команды со стороны — посмотреть, что у них происходит на самом деле, и навести порядок. И почти в каждой натыкаюсь на одно и то же: значительная часть процессов в компании существует не чтобы что-то делать, а чтобы что-то изображать. Это не патология отдельной конторы. Это закономерность, у неё есть механика, и её стоит уметь видеть — особенно если ты за эти процессы отвечаешь.

Постмортем как поминки

Вернёмся к разбору, после которого ничего не поменялось. Зачем он был нужен, если чинить никто не собирался?

Затем же, зачем нужны поминки. Случилось плохое. Людям больно, тревожно и немного стыдно. Нужен ритуал, который эту боль обработает: собраться вместе, проговорить, что произошло, обозначить, что «мы приняли меры», и разойтись с ощущением, что теперь всё под контролем. На поминках не лечат — лечить уже некого. На поминках прощаются и идут жить дальше.

Постмортем, после которого не меняется ни один дефолт, делает ровно это. Он не инструмент починки — он инструмент закрытия гештальта. Он снимает тревогу, восстанавливает ощущение контроля и даёт начальству строчку «провели разбор, выработали меры» для следующего созвона с бизнесом. Все эти функции — настоящие и важные. Просто ни одна из них не имеет отношения к тому, чтобы падение не повторилось.

И вот тут — главное различие, вокруг которого крутится вся статья. Есть процессы-инструменты: они существуют, чтобы менять реальность. И есть процессы-символы: они существуют, чтобы менять ощущение от реальности. Снаружи они выглядят почти одинаково — те же встречи, те же документы, те же owner’ы в таблице. Отличаются только результатом, и то если за ним проследить.

Почему символов становится больше

Процессы-символы не заводят специально. Никто не приходит на стендап со словами «давайте сделаем ретро, которое не будет ни на что влиять». Они вырастают сами, и вот из чего.

Во-первых, символ дешевле инструмента. Чтобы постмортем реально что-то изменил, кто-то должен взять его action items, выбить под них время в спринте, продавить приоритет против фич, довести до конца и проверить. Это дорого и неприятно — приходится с кем-то конфликтовать за ресурс. А провести красивый разбор и разослать — дёшево и приятно. При прочих равных система дрейфует в сторону дешёвого.

Во-вторых, символ безопаснее. Пока ты соблюдаешь ритуал — у тебя есть алиби. «Мы же провели разбор», «у нас есть дашборд», «мы следуем процессу». Если рванёт снова, ты не виноват: ты всё сделал по регламенту. Символ перекладывает ответственность с человека на процесс, а это очень удобно. Инструмент так не умеет — инструмент либо сработал, либо нет, и спрос персональный.

В-третьих, символ нельзя «не пройти». Инструмент даёт обратную связь: тест либо красный, либо зелёный, мониторинг либо поймал, либо проспал. Символ обратной связи не даёт — ретро прошло «успешно» по факту того, что оно состоялось. А процессы без обратной связи не эволюционируют. Они просто накапливаются: завели — и оно живёт вечно, потому что отменить его — значит признать, что оно было лишним, а это неловко.

Сложите это вместе, и получится естественный градиент: в любой достаточно взрослой компании символов со временем становится всё больше, а инструментов — всё меньше, если кто-то сознательно не чистит. Дашборд, на который никто не смотрит, но всем спокойнее, что он есть. Ретро, где третий спринт подряд проговаривают одно и то же. Чек-лист перед релизом, который заполняют не глядя. Согласование, которое всегда «согласовано». Всё это когда-то, возможно, работало. Теперь — изображает.

Это не глупость, это availability bias организации

Тут легко свалиться в «менеджеры идиоты, развели бюрократию». Не идиоты, и дело не в бюрократии.

Организация, как и человек, реагирует на то, что видно. Громкое падение видят все: оно болит, за него ругают, его обсуждают на всех уровнях. На него бросают ресурсы мгновенно. А тихий риск — недоделанный action item, единственный человек, который знает, как разворачивается прод, отсутствие реального теста под сценарий — невидим ровно до того момента, пока не рванёт. Поэтому он всегда проигрывает борьбу за приоритет видимому.

Это availability bias, только на уровне компании: что доступно вниманию, то и кажется важным. Символ удобно ложится в эту ловушку, потому что символ — это и есть «видно». Красивый постмортем видно. Дашборд на стене видно. А вот сделанный action item, который тихо предотвратил падение, которого поэтому не случилось, — не видно вообще. Предотвращённого пожара нет в ленте инцидентов. Награждать и замечать нечего.

Так организация и обучается: вкладываться в то, что заметно, а не в то, что работает. Не потому что глупая, а потому что у неё, как у всех, кривые стимулы.

Один вопрос, который всё вскрывает

Хорошая новость: чтобы отличить инструмент от символа, не нужен аудит. Нужен один вопрос, который ты задаёшь про любой процесс:

«Что изменилось после прошлого раза?»

Постмортем: предыдущие action items — сделаны? Если открываешь архив и видишь те же пункты, не закрытые с того раза, — перед тобой ритуал. Поминки.

Ретро: проблема, которую обсуждали в прошлый раз, в этот раз ушла или всплыла снова? Если всплывает третий спринт подряд и каждый раз её «берут на заметку» — это не ретро, это групповая терапия. Тоже полезно, но называется иначе.

Дашборд: когда по нему последний раз приняли решение? Не «посмотрели», а изменили из-за него поведение. Если никогда — это обои.

Согласование: хоть раз заворачивали? Если за год не было ни одного «нет» — это не контроль, это турникет, который всегда открыт. Его можно снять, и ничего не изменится, кроме того, что станет быстрее.

Везде один и тот же тест: процесс должен оставлять след в реальности. Нет следа — символ.

Что с этим делать (и чего НЕ делать)

Самая дорогая ошибка человека, который это разглядел, — прийти и с энтузиазмом всё поотменять. Особенно если ты новый и хочешь показать, что навёл порядок. Не делай так. Вот почему.

Символ почти всегда выполняет какую-то настоящую функцию, просто не ту, что заявлена. Постмортем-поминки реально снимает тревогу команды — снеси его молча, и вместо спокойствия получишь людей, которые после каждого инцидента не понимают, «а мы вообще что-то с этим делаем». Дашборд, на который никто не смотрит, иногда оказывается тем, на который смотрит ровно один человек ровно в одной критической ситуации. Прежде чем резать, разберись, какую тревогу или какую подстраховку процесс на самом деле держит.

Поэтому порядок такой.

Сначала — инвентаризация, тем самым вопросом. Пройдись по регулярным процессам и честно отметь, где есть след в реальности, а где нет. Список символов обычно выходит длиннее, чем ждёшь.

Потом — не «отменить», а «вернуть обратную связь». Чаще символ можно превратить обратно в инструмент, не убивая. Постмортем, у которого action items никто не доводит, чинится не отменой, а одним правилом: новый разбор начинается с проверки статуса старых пунктов, и пока они не закрыты, новые не заводятся. Внезапно у ритуала появляется зубы. Ретро по кругу чинится тем, что одна проблема за раз доводится до конца до следующего ретро. Дашборд — тем, что у каждого графика есть владелец и ответ на вопрос «какое решение ты по нему принимаешь».

И только то, что не удаётся вернуть в работу и что не держит никакой реальной тревоги, — убираешь. Тихо, по одному, наблюдая, не сломалось ли что-то незаметное. Если через месяц никто не вспомнил — значит правда был лишним.

Зачем это всё видеть

Театр надёжности безобиден ровно до того дня, когда ты начинаешь принимать его за надёжность. Пока ты понимаешь, что постмортем — это поминки, а дашборд — обои, ты держишь в голове, что настоящая надёжность лежит где-то ещё, и ищешь её. Беда приходит, когда символы начинают всех убаюкивать: разборы проводятся, дашборды висят, чек-листы заполняются — и все искренне считают, что система под контролем. А она ровно настолько под контролем, насколько процессы оставляют след в реальности. То есть, в зрелой компании без регулярной чистки, — наполовину.

Так что в следующий раз, когда вокруг какого-то процесса будет особенно много торжественности — красивые слайды, обязательность, ритуальность, — задай тот вопрос. Что изменилось после прошлого раза? И если ответа нет, ты хотя бы будешь знать, на каких похоронах присутствуешь.

Я вхожу в чужие инженерные команды под NDA и навожу порядок — оттого пишу без лица и без названий компаний. Такие разборы, как этот, и байки из практики, из которых они вырастают, веду в Telegram, там же главами выходит книга «Театр на проде»: https://t.me/theshadowcto. Если узнали свою компанию — заходите, у нас её узнают на каждой второй странице.