Привет, Хабр! Меня зовут Алексей Лапунов, я ведущий менеджер цифровых продуктов департамента информационной безопасности и системного администрирования в ТЕХНОНИКОЛЬ Диджитал.
Первое найденное решение не всегда подходит для сложной проблемы. Оно может дать быстрый эффект, но не затронуть причину — и тогда через некоторое время всё возвращается. В статье я разберу подход, который помогает сначала понять, что именно происходит в системе, а уже затем выбрать и проверить решение.
Когда возникает проблема, мозг хочет справиться с ней как можно быстрее. Открытая задача вызывает напряжение, и любое действие в такой ситуации кажется лучше бездействия. Поэтому мы часто не ищем лучшее решение, а выбираем знакомое — то, которое уже помогало в похожей ситуации: тот же разговор с командой, перестановка приоритетов, заново введённый регламент. Мы узнаём ситуацию и запускаем привычный ответ. Так работает любая система, ориентированная на скорость, а не на точность решений.
Проблема в том, что большинство сложных задач не являются типовыми. У них разные корневые причины, поэтому шаблонный подход не устраняет истоки сбоя, а лишь временно маскирует симптом. И типовое решение убирает всего‑навсего внешние проявления, но не причину. Через месяц всё возвращается пусть и немного в другой форме, но с тем же источником. Компания снова тратит время, деньги и управленческое внимание.
Собрал пять главных принципов, которые я извлёк из ситуаций, где быстрое решение не сработало. Они перевернули моё понимание того, как работать со сложными ситуациями.
Принцип 1. Очертить границы и сформулировать разрыв
Вспомните любой созвон по горящему инциденту. Что обычно говорят? «Нужно больше контроля». «Не хватает координации». «Нужно больше ресурсов».
Ловушка в том, что это не формулировки проблем, а готовые решения, замаскированные под них. С такими вводными добраться до истинной причины невозможно.
Первое — фиксируем границы. Какой процесс разбираем, кто участники, где заканчивается зона нашей ответственности. Всё, что за границей, — внешний фон. Его не учитываем.
Локализовать рамку на уровне исполнителей логично, только если проблему решает сама команда — её интересуют подготовка, порядок шагов и передача инструмента. Если за дело берётся руководитель, границы нельзя сужать только до уровня исполнения. В анализ нужно включать и управленческий слой: приоритеты, координацию, порядок принятия решений и задержки, которые возникают в самом менеджменте. Иначе часть причин может остаться за рамками разбора.
Второе — формулируем проблему как разрыв между текущим состоянием и целевым результатом.
Формула простая: «Сейчас — [факт]. Цель — [результат]».
В формулировке проблемы нет места готовым ответам. Фраза «нам не хватает людей для быстрого ремонта» — это уже замаскированное решение. Проблема выглядит так: «сейчас ремонт занимает 8 часов, а целевой показатель — 2 часа». Точная формулировка сама по себе не решит проблему. Но без неё мы спорим об инструментах, а не о сути задачи.
Принцип 2. Разложить ситуацию на четыре слоя
Рамка отвечает за локализацию проблемы: она показывает, что сломалось, но за ней не видно причин — почему произошёл сбой. Здесь кроется главная ловушка: на этом этапе анализ чаще всего и заканчивают. Встречу провели, причину вроде бы нашли, решение внедрили. А через месяц проблема вернулась. Что не так? Дело в том, что мы обычно видим только верхний слой, а корень проблемы — глубже. В любой рабочей ситуации есть четыре слоя, и решение сработает только в том случае, если мы попадём в нужный.
Разберём на примере. Чтобы сократить время ремонта, руководитель установил камеру. В первый месяц длительность уменьшилась на 20%, а потом показатели вернулись к прежним значениям. Что произошло? Чтобы понять причину, разберём проблему на каждом из четырёх слоёв.
Слой 1. Факты. Фиксируем только то, что поддаётся измерению, без дополнительных интерпретаций и оценок. Нам известно: камера временно сократила длительность ремонта на 20%, потом произошёл откат. Плюс у нас есть источник объективных данных — запись камеры. На видео мы видим задержки на стыках смен, перемещения к месту хранения инструментов и паузы в работе. (Обратите внимание: назвать это «потерями» — уже интерпретация, ведь хронометража и данных по операциям у нас пока нет). Остальное — догадки.
Слой 2. Правила. Формальные регламенты и негласные договорённости — то, как процесс выглядит на бумаге и как он работает на самом деле. Канал для обратной связи существует, но пока не встроен в ежедневные процессы бригады. Негласная установка команды: «решать задачи привычным способом». Установка менеджмента: «усиливать контроль». Эти паттерны нигде не зафиксированы, но именно они формируют текущий рабочий процесс.
Слой 3. Стимулы. Поведение людей определяет не инструкция, а система мотивации, выгод и рисков. Логика руководителя прозрачна: получить прозрачность процесса, чтобы его оптимизировать. Но если инструмент (в нашем случае камера) воспринимается как элемент исключительно контроля, а не поддержки, он меняет мотивацию. Проявлять инициативу становится менее рационально, чем просто следовать базовому регламенту. В результате те, кто ближе всего к процессу, перестают подсвечивать зоны роста.
Слой 4. Ограничения. Фундаментальные рамки процесса, которые невозможно оперативно перестроить. Технологический регламент и состав бригады — это жёсткие вводные. Они создают границы, но сами по себе не отменяют необходимость искать узкие места внутри установленного окна ремонта. Когда все четыре слоя разобраны, картина становится объёмной.
Вывод: камера оказалась не решением, а лишь способом диагностики. Она дала короткий всплеск за счёт эффекта наблюдения, но не затронула ни правила, ни стимулы. Как только фактор новизны пропал, система вернулась в исходное состояние. Но сама по себе объёмная картина не даёт готового решения. Важно ещё определить, какой элемент требует вмешательства в первую очередь.
Принцип 3. Найти точку изменений
Когда проблему видно сразу на нескольких слоях, возникает искушение поправить всё и сразу.
Типичная ситуация: новый руководитель приходит в команду, у него горят глаза и много идей, как улучшить процессы. Он сразу же берётся за дело: вводит новые правила, перестраивает коммуникацию, обновляет метрики. Проходит три месяца — команда измотана, половина начинаний заброшена, а сопротивление только растёт. Попытка изменить всё разом рассеивает ресурсы и не даёт отследить, что именно сработало. Системность требует иного подхода: сфокусироваться на одном элементе, чтобы получить максимальный КПД. Это и есть точка изменений.
И это не обязательно самый очевидный элемент. Чаще всего он скрыт в слое правил или стимулов, там, где незаметно формируются негласные установки и поведение людей.
Вернёмся к кейсу с ремонтом. Первое импульсивное решение — хвататься за привычные механизмы: внедрить хронометраж, переписать регламенты, поменять состав смен. Но точка изменений находится глубже.
А теперь вспомним про камеру. Установка была понятным решением, но она сработала только как инструмент диагностики: зафиксировала на каких этапах происходят потери, но не устранила их причину. Причина кроется в слое правил. Установка руководителя на контроль порождает среду недоверия. Сотрудники, которые лучше камеры знают, где теряется время, не видят смысла проявлять инициативу. Решение начинается с изменения этой установки — с контроля на создание условий, в которых команда сама улучшает процесс. Гипотеза точки изменений: если сместить фокус менеджмента с контроля на создание условий для самостоятельной оптимизации, потеря времени начнёт сокращаться. У команды появится способ подсвечивать проблемы и видеть результат своих предложений.
Например, сделать регулярными короткие разборы. Бригада подсвечивает точечные потери времени, а руководитель публично фиксирует решения по каждому пункту и поощряет за предложения. Вместо привычного контроля появляется прозрачный алгоритм реакции. Изменение одного управленческого правила начинает менять и стимулы команды: подсвечивать проблемы становится выгодно.
Да, камера зафиксировала потери и временно сократила длительность ремонта. Но, напомню, это была диагностика. Камера помогла убрать лишь 20% простоев, но зафиксировать результат не удалось. Бригада может найти больше и удержать дольше.
Такой точечный подход позволяет сразу увидеть причинно‑следственную связь. Изменили один параметр — система отреагировала. Не отреагировала — тоже получили ценные данные для следующего шага.
А если точка изменений вне вашей зоны влияния? Задача меняется: вместо прямых правок вы ищете косвенное влияние через доступные вам процессы. А если и этого мало — подсвечиваете сбой тому, у кого есть полномочия. Иногда главный результат — не починить всё самостоятельно, а точно обозначить, где находится точка изменений.
Принцип 4. Задать три контрольных показателя
Точку изменений нашли. Но как убедиться, что решение сработало? И как не нарушить процессы, которые работают исправно?
Любое управленческое решение меняет среду. А у сложных систем отклик редко бывает изолированным — всегда возникают побочные эффекты.
Классический пример из практики: команда поставила цель сократить время восстановления сервиса после инцидентов. На верхнем уровне решение сработало мгновенно — ключевой показатель простоя существенно улучшился, а задача казалась решённой. Однако через два месяца выяснилось, что в погоне за скоростью команда перестала фиксировать паттерны ошибок, и контур обучения разомкнулся. Накопление данных о причинах сбоев прекратилось, поэтому продукт и процессы перестали улучшаться. В итоге крупные клиенты дольше страдали от повторяющихся сбоев, потому что их корневые причины никто не устранял.
Этой ситуации удалось бы избежать, если бы на старте были зафиксированы три контрольных показателя.
Целевой показатель — конкретный измеримый результат. Не «улучшить сервис», а «сократить время восстановления с 2 часов до 30 минут».
Показатель сохранности — что не следует ухудшать. В этом кейсе — суммарное время простоя клиентов за месяц. Превысили пороговое значение — останавливаем эксперимент и фиксируем причины.
Ранний признак риска — сигнал, что что‑то пошло не так. Например, если количество инцидентов начинает расти, значит, решение работает некорректно ещё до наступления критического сбоя.
Эти три показателя делают решение управляемым. Вместо запуска изменений вслепую вы заранее знаете, на что смотреть и когда остановиться.
Принцип 5. Проверить решение как гипотезу
Когда контрольные точки заданы, остаётся главное — относиться к решению как к гипотезе.
В рабочей среде решений с гарантированным результатом почти не бывает. Любая доработка требует тестирования в реальных условиях, где заданные метрики сразу покажут ее жизнеспособность.
Контроль эксперимента строится на трёх обязательных элементах.
Владелец — лично отвечает за проведение эксперимента и конечный результат. Ответственность не перекладывается на команду или отдел.
Стоп‑условие — неизменное требование остановки или отката эксперимента. Оно срабатывает при выходе за порог показателя сохранности или при появлении раннего признака риска.
Ретро — обязательный разбор через [Х] недель: подтвердилась гипотеза или нет, и каковы дальнейшие действия.
Даже если эксперимент не сработал, это не провал. Вы получили знание о своей системе. Это ценнее красивого плана, который никто не проверял.
Когда этот подход особенно нужен
В совокупности эти пять принципов дают системный подход к проблемам, с которыми не справляются базовые практики. Алгоритм эффективен на стыке команд и процессов — там, где обычно теряется ответственность и неясна точка приложения усилий.
Сложные проблемы редко решаются первым действием. Чаще результат появляется, когда мы сначала точно задаём рамку, потом ищем источник, затем находим зону изменений, проверяем решение через контрольные точки и запускаем его как эксперимент.
Ниже — короткий способ проверить, готово ли ваше решение к запуску.
Чек‑лист проверки перед принятием решения
Перед запуском следующего важного решения ответьте на семь вопросов.
Правильно ли заданы границы разбора?
Проблема сформулирована как разрыв между текущим и целевым состоянием?
В формулировке проблемы нет готового решения?
Проанализированы ли все четыре слоя: факты, правила, стимулы и ограничения?
Найдена ли конкретная точка изменений, а не просто список мелких правок?
Зафиксированы ли три показателя: целевой, сохранности и ранний сигнал риска?
Готов ли эксперимент к запуску: есть владелец, стоп‑условие и дата ретроспективы?
Если на все вопросы ответ «да», решение готово к запуску. Если есть хотя бы одно «нет» — продолжайте разбор — именно здесь прячется следующая проблема.
