Как перестать наступать на одни и те же грабли или «разбор полётов» без поиска виноватого

Бывало у вас в компании, что одна и та же проблема возникает периодически в одной и той же команде или в разных? А, возможно, каждая из этих команд каждый раз изобретает свой велосипед, хотя самая первая давно уже нашла оптимальное решение, просто никто кроме неё об этом не знает?

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

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

Концепцию принципа «чёрного ящика» я бы выразил в трёх утверждениях:

1. Если произошла ошибка или неудача, самое опасное для организации – это поиск виноватых, т.к. это снижет уровень доверия и повышает уровень бюрократии в компании.

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

3. Решение системной проблемы должно быть системным – т.е. скорее всего будет подразумевать изменение в процессах.

Т.е. переставая искать виноватых мы делаем разбор ситуаций безопасным для её участников, и они могут более открыто помогать в поиске причин и не зацикливаться на ужесточении регламентов и увеличении объёмов передаваемой документации. Сотрудник могут сфокусироваться, что же в корне было сделано не так и без обвинений и наказаний просто исправить эту системную ошибку. Люди уже не стремятся выработать такое решение, которое отведёт все обвинение от них в будущем, породив при этом новую бюрократию в процессе. Они действительно стараются найти, что было сделано не так ранее, без поиска и наказания виновного, но с желанием найти решение, которое не замедлит существенно процесс, но при том позволит избежать повторения неприятной ситуации.

Изменение подхода к разбору ошибок в долгосрочной перспективе ведёт в целом к изменению культуры. У компании Beyond Taylor есть такая визуализация:

У Эдвардса Деминга есть замечательная мысль на этот счёт:

Ниже описал не единственный способ проведения таких разборов, но опробованный мной для разбора разных ситуаций с разным составом и количеством участников от 3 до 12

Участники встречи – это основные участники ситуации, которую разбираем. Это далеко не всегда просто команда, скорее всего там участвовали и другие люди (бизнес, безопасность, другая команда). Команду тоже не обязательно звать целиком, можно только тех кто принимал непосредственное участие в ситуации. У вас нет задачи раздуть число участников.

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

Встреча состоит из 3 этапов:

1. Описать ситуацию

2. Найти системную причину

3. Зафиксировать первые шаги по изменению процессов для устранения системных причин

В самом начале встречи расскажите о цели встречи и основных правилах.

Затем опишите план встречи (3 этапа, которые проговорили выше)

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

Либо можно совместно со всеми участниками сформулировать ситуацию прямо на встрече.

Шаг наиболее творческий, можно использовать любой подход к поиску корневых причин. Я опишу свой любимый способ с использованием техники «5 почему».

1. Сначала просим участников накидать все причины возникшей ситуации

2. Когда чувствуете, что идеи иссякли, уточняете «это все вероятные причины?»

3. Если больше идей нет. Спросите: «Какая самая главная или самая веская причина?» Иногда сразу нельзя понять, какая. В таких случаях стоит копать вглубь по всем причинам 1-го уровня.

4. Задаем вопрос к главной причине 1-го уровня: «Какие причины этого?»

5. Так получаем второй уровень и повторяем, пока не упремся в системные причины вроде: «Политика компании», «Требования регулятора» и т.д. Либо пока не иссякнут идеи участников. Обычно корневая причина достаточно системная и нередко находящаяся за пределами контроля одной команды

Системные причины – как правило причины, у которых нет своих причин, т.е. в них не входит ни одна стрелка на схеме.

Во время генерации причин, будьте внимательны к формулировкам:

⛔ Просите переформулировать, если причины записывают как ярлыки вроде

· «Отдел Х – козлы»

· или «YYYы вообще не умеют работать»

⛔ Также избегайте писать причины, подразумевающие конкретные решения типа

· «У нас нет процесса N»,

· «Они не следуют стандартам отрасли»

· или «Плохо ведут задачи в таск-трекере».

Иначе вы зациклитесь на одном решении, а нам на данном этапе это не нужно.

✅ Формулировки должны быть в виде того, что «болит»:

· «Не можем поставлять в срок»,

· «Продакты не знают реальных статусов»,

· «Интеграция занимает половину срока проекта» и т.д.

Пример

Чёрным здесь обозначены системные причины. Можно заметить, что они находятся на разной глубине.

Этот шаг достаточно стандартный для Agile-ретроспектив.

Для каждой найденной системной/корневой причины:

1. Нужно понять, что сделать, чтобы предотвратить подобные ситуации в будущем.
Тут нужно быть аккуратным в плане того, чтобы не придумать настолько сложный процесс, что он окажется дороже, чем ущерб от рассматриваемой ситуации.
Примеры таких решений могут быть:
🤨 «Забрать доступы у … к …»
🤨 «Добавить этап согласования с …»
🤨 «Описывать все требования по ГОСТ, BPMN и т.д.»
Необязательно все эти формулировки плохи, но как только что-то такое появляется, убедитесь, что затраты на новый процесс существенно меньше ущерба от рассматриваемой ситуации иначе, они того не стоят.
👍 Хорошими примерами могут быть любые способы автоматизировать и исключить или снизить человеческий фактор. Конечно, затраты на автоматизацию тоже стоит сравнить с ущербом от рассматриваемой ситуации.

2. Если решение достаточно сложное или объёмное, то обязательно зафиксируйте первый шаг, кто его сделает и в какой срок.

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

Из моей практики, такие реестры часто превращаются в кладбища идей или информационные холодильники. Поэтому обычно команды эти находки выносят на очередную Общую Ретроспективу, IP-итерацию, Вечеринку факапов или другую встречу, где можно поделиться инсайтами на всю компанию или хотя бы на весь большой продукт, чтобы остальные не наступали на те же грабли и, возможно, взяли на вооружение ваши идеи.

Тут можно скопировать шаблон в Miro

Либо загрузить бэкап в формате RTB для импорта в Miro или другой инструмент.

С подготовкой и проведением такой сессии может помочь автор этой статьи – Денис Тучин