От поиска виноватых к изменению системы

Меня зовут Вячеслав Сидячкин и я работаю Agile Coach. Недавно столкнулся с ситуацией, которая сначала выглядела как типичный конфликт между двумя командами.

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

Я начал разбираться, как устроена система. Для этого я провел интервью с представителями Поддержки, Разработки, Customer Service и команды, которая занимается настройкой клиентов. Меня интересовали повторяющиеся события, причинно-следственные связи и ментальные модели участников. На основе этих интервью построил причинно-следственную диаграмму (Causal Loop Diagram).

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

Формально причины были разными: дефекты, настройки, проблемы совместимости или производительности. Но для клиента это всегда выглядело одинаково — «продукт не работает так, как ожидается».

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

После интервью я собрал представителей Поддержки, Разработки и Product Owner на общую встречу. Заранее попросил участников прочитать выдержки из интервью, чтобы они увидели общую картину не только через цифры, но и через опыт друг друга. На встрече сначала показал метрики потока, включая CFD (Cumulative Flow Diagram), и потом мы вместе разобрали диаграмму.

Это сильно изменило обсуждение. Если бы я просто принес готовое решение и объяснил, как, на мой взгляд, устроена система, скорее всего, разговор снова свелся бы к поиску виноватых. Но участники увидели на диаграмме собственные наблюдения и ситуации, которые сами описывали в интервью. Диаграмма перестала быть моей интерпретацией и стала общей моделью происходящего.

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

Во время анализа я также пытался определить, к какому архетипу системного мышления относится эта ситуация. Сначала предполагал Limits to Growth, но собранных данных оказалось недостаточно. На текущем этапе кейс больше напоминал Growth and Underinvestment: организация росла быстрее, чем инвестировала в способность поддерживать этот рост. Но даже без точной классификации модель оказалась полезной. Она помогла сделать предметом обсуждения не симптомы и не отдельные команды, а систему целиком.

Раньше я воспринимал причинно-следственную диаграмму прежде всего как инструмент анализа. Теперь смотрю на нее иначе. Причинно-следственная диаграмма оказалась способом сформировать общее понимание системы.

Пока каждая команда видит только свой участок работы, разговор почти неизбежно сводится к поиску виноватых. Поддержка видит долгие ответы Разработки. Разработка — плохо подготовленные тикеты. Product Owner — растущую очередь. Каждый по-своему прав, но никто не видит систему целиком.