Замечено, что за менеджерами может тянуться хвост проблемных проектов. Чем опытнее менеджер — тем длиннее. Самая большая проблема — то что хвост этот мешает двигаться и развиваться дальше. Коллеги могут припоминать что-то типа «э.. это Васька. Он знаешь уже сколько проектов завалил». И очень хочется этот хвост отрубить. Ретроспективы помогают мало (как правило — мало времени на глубинный разбор сложных проблем). Нужно что-то посильнее.

В любой момент можно вспомнить, что Вася когда-то накосячил и сказать, что он всегда так делает.

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

Хансей

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

Итого, что требуется: 

• Заниматься непрерывным самоанализом;
• Быть искренне заинтересованным в решении проблемы;
• Быть искренним с собой, коллегами и клиентами;
• Подходить к анализу систематично;

Кому интересно узнать больше — почитайте книгу Джеффри Лайкера «Дао Toyota». Опять же, Япония... У нас за «хансей» могут сразу в морду дать. Нужно что-то более систематичное. И более западное :) 

Root Cause Analysis
(собственно, с английского «анализ причин»).

Цель анализа: докопаться до глубинных проблем. Предложить решения на каждом уровне проблемы. Убедиться, что меры помогут. Внедрить предложенные меры.

Кого можно привлекать: Можно самостоятельно, можно привлекать небольшую группу. 

Лучше проводить непосредственно с вашим начальником/клиентом: он видит проблему, ищет решение с вами и, таким образом, вы получаете индульгенцию.

Как проводить:

1. На первом этапе нужно выявить проблемы. Зафиксировать их. Мне удобно это делать в майндмэпе (XMind) или на маркерной доске (ну или ватмане).
2. Построить диаграмму причинно-следственных связей по выявленным проблемам. Для этого нужно по каждой проблеме задавать вопросы: «почему?», «почему это произошло?», «по какой причине?». Искренне, как бы ни было неприятно это сознавать — сообщать о причинах проблем. Записывать причины на диаграмме, строить причинно-следственное дерево.
3. Не уходить в неконструктивные ветки («В программе баг, потому что Вася мудак»). Исходить из того, что все люди хорошие, но в рабочей системе есть какие-то ограничения, которые мешают им правильно выполнять процесс. Стараться найти такие ветки, которые являются истинными причинами и ограничениями.
4. После того, как дерево проблем построено, пройдите по всем веточкам и всем узлам, предложите противодействия, которые нейтрализуют проблему (одно или несколько конкретных действий, инноваций или изменений рабочего процесса).
5. Убедитесь, что изменения помогут. Убедитесь, что эти изменения можно внедрить и их внедрение рационально. Поговорите об этом с вашим начальником. Согласуйте с ним, какие именно изменения вы будете внедрять. Договоритесь о способе внедрения. Запланируйте работы в собственный google calendar или в календари тех сотрудников, которых планируется привлечь к внедрению изменений.
6. Внедрите изменения. Проанализируйте последствия. Сообщите о результатах вашему начальнику. Без внедрения вся проделанная ранее работа — бессмысленна. 

Пример диаграммы

Я лично предпочитаю обычное дерево, но многим удобно использовать Fishbone-диаграмму (рыбий скелет или диаграмму Исикавы).

Источник: https://blog.sibirix.ru/2012/10/05/root-cause/ Там же, кстати, есть пример заполненной диаграммы.