Знания нельзя втолкнуть туда, где они не нужны
Передача опыта редко работает по принципу "покажи, как у вас, и мы повторим". Даже самые сильные практики могут оказаться бесполезными, если они не связаны с конкретной проблемой получателя. Человек способен внимательно слушать, делать записи и соглашаться с каждым тезисом - но ничего не изменится, пока он не увидит, каким образом новые знания помогут решить его собственную задачу.
Однажды ко мне направили технического руководителя, которому поручили изучить подходы к управлению инцидентами. Он возглавлял инженерную команду в крупной розничной сети с большим количеством территориально распределённых магазинов. Его компания работала в другой отрасли и в иной юрисдикции, поэтому прямое копирование процессов из IT-среды изначально выглядело сомнительно.
От руководителя ему дали простую установку: приехать, посмотреть, как организована работа с инцидентами, и забрать лучшие практики. Я начал рассказывать о собственном опыте: как быстрее узнавать о проблемах клиентов, выстраивать связь между первой линией поддержки и инженерами, выбирать подходящие метрики, формировать KPI, вести документацию и проводить постмортемы.
Собеседник вежливо слушал, кивал и делал пометки. Однако было заметно, что разговор не вызывает у него настоящего интереса. Он не спорил и не задавал уточняющих вопросов, но и не пытался примерить услышанное к своей реальности. Я фактически предлагал ему готовые ответы, хотя он не задавал соответствующих вопросов.
В какой-то момент я остановил рассказ и спросил напрямую:
- Что у вас сейчас болит сильнее всего? Возможно, я смогу посмотреть на ваш случай с другой стороны и предложить решение именно для этой ситуации.
После этого беседа изменилась. Оказалось, что каждый магазин сети обязан передавать данные о продажах внешнему оператору в строго установленный срок. Проблема заключалась в том, что оператор регулярно становился недоступен. Инженерной команде приходилось компенсировать сбои на уровне отдельных торговых точек: устанавливать мониторинг, запускать повторные отправки, придумывать временные схемы хранения и дозагрузки данных.
Подходы в магазинах повторялись, но из-за огромного количества точек работали нестабильно. При этом смена оператора не решала вопрос: у альтернативного поставщика возникали те же перебои. Получался парадокс - общая инфраструктурная проблема устранялась множеством локальных решений.
Мы набросали схему: большое количество магазинов, несколько внешних операторов и одинаковая зависимость от их доступности. На рисунке сразу проявилось слабое место архитектуры. Каждая торговая точка самостоятельно решала задачу, которая по сути была централизованной.
В качестве варианта я предложил промежуточный сервис на стороне компании. Магазины передают данные ему, а он отвечает за дальнейшую доставку оператору. Если внешний контрагент временно недоступен, сервис сохраняет информацию и автоматически повторяет отправку. В результате десятки разрозненных "костылей" заменяются одним компонентом, который находится под контролем самой организации.
Такой слой давал и дополнительные преимущества. Переключиться на другого оператора можно было бы в одном месте, без изменения программного обеспечения каждого магазина. Позже компания даже получила бы возможность самостоятельно предоставлять подобную услугу, превратив внутренний компонент в полноценный операторский шлюз.
Мы оба завершили встречу с ощущением пользы. Я не участвовал в дальнейшем внедрении и не знаю, был ли проект реализован, однако сам разговор показал главное: опыт начал работать только тогда, когда оказался привязан к конкретной боли.
Почему универсальные рецепты часто не приживаются
Исследования организационного поведения подтверждают этот вывод. В 1996 году Габриэль Шулански изучил 122 случая переноса лучших практик внутри восьми компаний. Его работа показала, что главным препятствием оказывается не отсутствие желания учиться, а способность получателя усвоить и применить новое знание.
Практика может быть доказанно успешной в одном подразделении, но не переноситься в другое. Причина - в различиях контекста: архитектуре систем, полномочиях команд, ограничениях бюджета, регламентах, уровне зрелости процессов и даже в используемой терминологии.
Особенно сложно заимствовать опыт извне. Внутри одной компании хотя бы существуют общие цели, культура и инфраструктурные предпосылки. Между разными организациями эти условия могут полностью отсутствовать. Поэтому фраза "у них это работает" сама по себе ничего не доказывает.
Знание усваивается быстрее, если помогает решить уже осознанную проблему. Вторым сильным стимулом становится цель, к которой человек стремится. Например, команда ещё не столкнулась с масштабированием, но уже понимает, что через полгода текущая архитектура не выдержит нагрузки. В таком случае информация о масштабировании будет востребована заранее.
А вот знания, не связанные ни с болью, ни с ближайшей целью, обычно превращаются в заметки. Их сохраняют "на будущее", но это будущее редко наступает в нужный момент. Когда потребность наконец появляется, записанный материал может потеряться, устареть или оказаться слишком общим для практического применения.
Как правильно передавать опыт
Разговор о чужой практике лучше начинать не с презентации и не с экскурсии по процессам. Первый вопрос должен звучать примерно так: "Какая проблема сейчас мешает вам двигаться дальше?" Ответ позволяет отфильтровать весь массив опыта и выбрать только те элементы, которые имеют отношение к ситуации.
Полезно также уточнить масштаб проблемы. Важно понять, единичный ли это сбой, повторяющийся процесс или системный дефект архитектуры. В описанном случае проблема проявлялась в каждом магазине, но источник находился за пределами торговых точек. Именно визуализация помогла увидеть, что локальные исправления скрывают общую причину.
Хороший способ проверить применимость практики - разобрать её предпосылки. Нужно спросить: какие ресурсы были доступны в исходной компании, кто отвечал за реализацию, какие ограничения существовали, сколько времени заняло внедрение и какие компромиссы пришлось принять. Без этого "лучший опыт" легко принять за универсальный рецепт.
Не менее важен язык объяснения. Если собеседник мыслит категориями надёжности поставок, сроков передачи данных и операционных рисков, разговор о привычных IT-метриках может оказаться бесполезным. Идею следует переводить на язык его задач, а не заставлять человека сначала осваивать чужую систему координат.
Эффективнее всего передавать не готовую конструкцию, а принцип принятия решения. В данном примере ценность заключалась не только в предложении промежуточного сервиса. Гораздо важнее было показать закономерность: если одинаковая логика надёжности многократно реализована на периферии, возможно, её стоит централизовать.
После обсуждения полезно сформулировать небольшой следующий шаг. Это может быть схема взаимодействия, прототип, измерение частоты сбоев или эксперимент на нескольких точках. Маленькая проверка быстрее показывает, подходит ли решение, чем масштабная программа внедрения, начатая на основании общего впечатления.
Что делать с внутренними базами знаний
Та же логика работает с документацией. Большая база регламентов не гарантирует, что команда будет ею пользоваться. Документ должен отвечать на конкретный вопрос, быть доступным в момент возникновения проблемы и содержать понятный алгоритм действий.
Материалы стоит организовывать не только по темам, но и по сценариям: "оператор недоступен", "данные не доставлены", "система превысила лимит", "нужно переключить поставщика". Тогда сотрудник ищет не абстрактную статью о надёжности, а инструкцию для возникшей ситуации.
После применения знания необходимо получать обратную связь. Если инструкция не помогла, это не всегда означает, что сотрудник плохо обучен. Возможно, сам материал слишком общий, противоречит реальной архитектуре или описывает процесс, которого больше не существует.
Передача опыта становится результативной, когда превращается в совместное исследование проблемы. Один участник приносит метод, другой - контекст и ограничения. Только на пересечении этих двух компонентов возникает решение, которое можно внедрить.
Поэтому лучшие практики не следует "продавать" как готовые истины. Их нужно рассматривать как набор гипотез. Сначала определяется реальная потребность, затем подбирается подходящий принцип, после чего он адаптируется к конкретной среде и проверяется небольшим экспериментом.
Знания невозможно навязать силой презентации, командировки или обязательного обучения. Они закрепляются тогда, когда помогают человеку быстрее устранить препятствие, достичь цели или избежать будущих потерь. В остальных случаях даже самый ценный опыт остаётся просто набором хорошо оформленных, но невостребованных записей.
