Обычно на ретроспективе всё сводится к трём вещам: «надо лучше коммуницировать», «оценивали плохо» и «в следующий раз постараемся». Звучит бодро, но через два спринта всё повторяется. В последний раз мы сорвали дедлайн по реализации модуля на 2 недели. И вместо того, чтобы снова поговорить «в общем», я предложил инструмент, который отлично справляется с поиском проблем - диаграмму Исикавы (она же рыбья кость) и метод поиска корневых причин (5 почему?).

Диаграмма Исикавы - Это способ разложить проблему на категории причин, она помогла побороть проблему белого листа, и разложить по полочкам жалобы команд. Классические 6 категорий адаптировали под IT: 🔹 Люди — компетенции, загрузка, выгорание, текучка 🔹 Процессы — оценка, планирование, коммуникация, ревью 🔹 Технологии — legacy, инструменты, инфраструктура, тесты 🔹 Требования — неясные ТЗ, меняющиеся приоритеты, скрытые ожидания 🔹 Оценка — недооценка сложности, оптимизм, «авось пронесёт» 🔹 Внешние факторы — заказчик, смежные команды, бизнес-контекст

Как я это делал: По очереди собрались разными командами (разрабы, QA, аналитики, РП, PM), От каждой команды я просил рассказать все боли в работе, которые мешают им делать её во время (по их мнению). Далее распределили по категориям. Без критики. Просто факты.

Когда вся информация собрана и дублирующиеся проблемы убраны, оказалось 135 общих жалоб. Теперь надо найти корневые причины. Я так же по очереди созвонился со всеми командами и каждую жалобу конкретной команды разобрал по методике “5 почему”.

5 почему - Это способ поиска корневых причин проблемм. Нам нужно лечить не симптомы, а их корни. то, что вызывает проблемы. Как это работает: Каждую проблему записываем и задаём вопрос: “Почему?” - ответ на этот вопрос, как правило, тоже является чей-то проблемой. Задавая к ним вопросы “Почему?” ещё 3-4 раза - находится виновник. Процесс, или человек который, может, и не специально, но саботировал срывы дедлайнов. А итоге корневых причин было всего 15. Почти в 10 раз меньше. То есть 1 реальная проблема вызывала почти 10 жалоб у разных команд в разных категориях. Некоторые корневые проблемы, что нашли под рыбьим скелетом:

📌 В категории “Процессы” оказалось, что задачи, по которым нет чёткого понимания дальнейших действий отправлялись в статус “ожидает” без каких-либо комментариев. Никто кроме самого разработчика не знал почему там лежит задача, она терялась среди других. Вспоминали о ней, когда подходил дедлайн. ✅ Решением было составление процесса ожидания задач. Разработчик должен был написать комментарий - чего задача ждёт и отметить в тасктрекере кто может продвинуть задачу (либо ответить на вопросы, либо что-то сделать)

📌 В “Требованиях” - поголовно все жаловались на частое изменение требований, но никто не умел с этим работать. Требования не фиксировались, оставались “на ушах”, путались, забывались. Благодаря этому многие задачи в результате переделывались на самом последнем этапе разработки, когда выяснялось что до разработчика не дошли новые требования. ✅ Решением так же был новый процесс. Фиксация требований прям в задачу разработчика, в комментариях. Если задача выполнена больше чем на 70-80%, то требования фиксировались как “доработка” и на это составлялась другая задача. Таким образом задачи не растягивались в 2 раза, а все доработки выполнялись по плану.

Главный инсайт: Диаграмма Исикавы - это не про то, чтобы найти виноватого. Это про то, чтобы перестать лечить симптомы. Когда ты видишь всю “рыбу” целиком, становится очевидно: проблема почти никогда не в одной точке. Она на пересечении категорий.