Ко мне однажды направили технаря перенимать опыт инцидент-менеджмента. Он возглавлял инженерную команду в розничной сети с большим количеством распределённых точек продаж (отрасль, отличная от IT, и другая юрисдикция). Сверху ему спустили установку: съезди, посмотри, как у людей налажен инцидент-менеджмент, и перейми лучшие практики.

Я стал делиться своим опытом. Рассказывал, как выстраивается работа с инцидентами: как узнавать о проблемах клиентов как можно раньше, как наладить взаимодействие клиентских служб и инженерных команд, какие метрики и KPI можно использовать, как вести документацию и постмортемы. Он вежливо слушал, кивал и что-то записывал.

И при этом я видел, что ничего не происходит. Знаете это ощущение, когда объясняешь человеку, а он не загорается? Слушает, но не вовлекается. Эти знания не приближали решение его проблемы. У него болело другое.

Тогда я остановился и спросил в лоб: «А что у тебя болит прямо сейчас? Я, может, буду отвечать в другом разрезе — в контексте твоей боли».

И разговор пошёл.

Боль и решение за один подход к доске

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

Мы порисовали, как у них всё устроено: много магазинов, пара операторов. Смена оператора не помогала, так как у другого были те же проблемы с доступностью. На схеме стало видно, что проблема общая, а решается она в каждом магазине по отдельности.

Я предложил завести промежуточный сервис на их стороне: магазины шлют данные в него, он доставляет их оператору, а при неудаче сам досылает недостающее. Сложность схлопывается из всех этих костыльных схем в одну точку, которую они контролируют самостоятельно. В качестве бонуса они получают возможность переключения между операторами настройкой в одном месте, не трогая ни один магазин. А со временем можно и самим стать таким оператором. В итоге со встречи мы оба вышли довольными. Внедрением я уже не занимался, и дошло ли дело до реализации — честно не знаю.

Почему лучшие практики не сработали

Знания не передаются, если не бьют в чью-то боль или цель. Нельзя втолкнуть знание туда, где в нём нет необходимости. Это не только моё наблюдение: Габриэль Шулански ещё в 1996 году изучил 122 переноса лучших практик внутри восьми компаний («Exploring Internal Stickiness», Strategic Management Journal) и показал, что главные барьеры переноса знаний — это не мотивация, как принято думать, а прежде всего способность получателя впитать знание, то есть насколько оно ложится на его контекст и задачу. Лучшие практики плохо переносятся даже между отделами одной компании. Что уж говорить про перенос извне. Пока я рассказывал про подходы к инцидент-менеджменту, он слушал чужие ответы на чужие вопросы. Как только разговор пошёл от его боли, появился и интерес с его стороны.

Боль — не единственный стимул. Знания также цепляются за цель или задачу, которую человек ещё не решает, но уже видит перед собой. А вот знание без потребности не цепляется ни за что, его записывают в блокнот, который никто не откроет.

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