Как решать сложные проблемы

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

Как проблема маскируется под готовое решение

Вспомните последнее совещание, где обсуждали проблему. Как она звучала? «Нужно больше контроля». «Не хватает координации». «Нужно больше ресурсов». Это не формулировки проблем. Это уже готовые решения, замаскированные под проблемы. Если так ставить вопросы, до причины не добраться.

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

Если ремонтная бригада разбирает свою работу, ее границы – все внутри ее участка: подготовка, порядок операций, передача инструмента, внутренние ожидания. То, на что можно реально влиять. Но если тот же ремонт разбирает руководитель, границы нельзя ограничивать бригадой. В них нужно включать и себя: приоритеты, координацию между бригадами, порядок решений, задержки в самой системе управления. Иначе причина почти всегда окажется «внизу», хотя часть ее находится на его уровне.

Второе – сформулировать проблему как разрыв. Не ощущение и не оценку, а разрыв между тем, что есть, и тем, что хочется получить. Формула простая: «Сейчас – [факт]. Цель – [результат]».

В формулировке проблемы не должно быть готового решения. «Нам не хватает ресурсов для быстрого ремонта» – это уже ответ. Проблема звучит иначе: «Ремонт занимает восемь часов, цель – два часа». Точная формулировка не решает проблему сама. Но без нее идет спор о средствах, а не решение вопроса.

Как искать причины возникновения проблемы

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

Разберем на примере. Руководитель хотел сократить время ремонта и поставил камеру. В первый месяц длительность сократилась на 20%, потом эффект исчез. Что произошло? Чтобы ответить, нужно пройти по всем четырем слоям:

• Слой 1 – факты. Только то, что можно увидеть и измерить, без интерпретаций и оценок. Камера в первый раз дала минус 20% времени на ремонт, потом эффект исчез. Потери времени видны на стыках между сменами, при хождениях за инструментом, при простоях. Хронометража нет. Данных по отдельным операциям тоже нет. Это все, что известно, остальное пока предположения.
• Слой 2 – правила. Формальные регламенты и негласные договоренности – то, как здесь принято действовать. Канал для предложений снизу формально есть, но с ремонтными бригадами не работает. Негласное правило бригады: не высовывайся. Негласное правило руководства: контролируй и улучшай. Оба нигде не записаны, но оба реально работают.
• Слой 3 – стимулы. Люди ведут себя не так, как написано в инструкции, а так, как им выгодно или безопасно. Логика руководителя понятна: видеть процесс, чтобы улучшать его – отсюда камера. Но камера легко считывается как сигнал недоверия. В такой среде инициатива не кажется безопасной. А значит, те, кто лучше всех видит реальные потери времени, предпочитают молчать.
• Слой 4 – ограничения. Реальные барьеры, которые нельзя быстро изменить в рамках задачи. Технологическая последовательность операций фиксирована. Состав бригад тоже. Это важно: часть условий действительно жесткая. Но это еще не объясняет, где именно теряется время внутри ремонта.

Когда все четыре слоя заполнены, картина становится объемной. Камера оказалась не решением, а диагностическим ходом. Наблюдение временно изменило поведение, но не затронуло правила и стимулы, поэтому эффект быстро исчез. Но сама картина еще не дает решения. Следующий вопрос – что именно здесь является точкой изменений.

Как определить точку изменений

Когда проблема видна сразу в нескольких слоях, появляется соблазн исправить все одновременно.

Новый руководитель приходит в команду с горящими глазами. Он сразу запускает несколько инициатив: меняет процессы, вводит новые правила, перестраивает коммуникацию, обновляет метрики. Через три месяца команда измотана, половина инициатив заброшена, сопротивление растет. Попытка изменить все сразу рассеивает энергию и не дает понять, что именно сработало. Системный подход требует другого: найти одну точку, воздействие на которую даст максимальный эффект на всю систему. Это и есть точка изменений. Это необязательно самая заметная точка, чаще всего она лежит в слое правил или стимулов – там, где незаметно формируется поведение участников.

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

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

Фокус на одном рычаге дает еще одно преимущество: видна причинно-следственная связь. Нажали – система отреагировала. Не отреагировала – получили важную информацию для следующего шага.

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

Как проследить, что решение работает, а не вредит

Точка изменений найдена. Но как понять, что воздействие работает? И как не сломать то, что уже работает нормально?

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

Этого можно было избежать, если бы с самого начала зафиксировали три контрольных показателя:

• Целевой показатель – что именно хочется улучшить. Конкретно и измеримо. Не «улучшить сервис», а «сократить среднее время восстановления сервиса с 2 часов до 30 минут».
• Показатель сохранности – что нельзя ухудшить. В этом кейсе – общее время простоя клиентов в месяц. Вышли за обычный порог – стоп, разбираемся.
• Ранний признак риска – сигнал, что что-то пошло не так. Он должен сработать задолго до серьезного сбоя. Например: количество аварий пошло вверх, значит, система реагирует не так, как рассчитывали.

Эти показатели делают решение управляемым. Вы не просто запускаете изменение и надеетесь. Вы заранее знаете, на что смотреть и когда остановиться.

Почему решения надо проверять как гипотезы

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

• Владелец – конкретный человек, который запускает эксперимент и отвечает за результат. Не команда и не отдел, а сотрудник.
• Стоп-условие – это заранее заданное правило, при котором эксперимент приостанавливается или останавливается. Оно привязано к значениям показателей сохранности и раннего признака риска.
• Ретро – обязательный разбор через [Х] недель. Не для отчета, а чтобы честно ответить: гипотеза подтвердилась или нет, и что делать дальше.

Даже если эксперимент не сработал, это не провал. Вы получили знание о своей системе. Это ценнее красивого плана, который никто не проверял.

Вопросы для самопроверки перед принятием решения

• Я правильно задал границы разбора?
• Я могу сформулировать проблему как разрыв: что есть сейчас и что хочу получить?
• В моей формулировке проблемы нет готового решения?
• Я посмотрел на все четыре слоя: факты, правила, стимулы, ограничения?
• Я нашел одну точку изменений, а не список того, что надо исправить?
• У меня есть три контрольных показателя: целевой, сохранности и ранний сигнал риска?
• Я готов запустить решение как эксперимент: с владельцем, стоп-условием и датой ретро?

Если на все семь вопросов ответ «да», решение готово к запуску. Если хотя бы один ответ «нет», разбор лучше продолжить. Именно здесь чаще всего прячется следующая проблема.

Выводы

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

Также читайте: