Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.
Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.
С похожими ситуациями сталкиваются не только инженеры, которые пытаются продвигать изменения, но и в целом те, кто стремится расти внутри компании — брать на себя больше ответственности, влиять на решения и двигаться по карьерному треку.
Можно делать сильные предложения и запускать инициативы, но всё равно оставаться в одной точке, без реального прогресса.
Автор этого текста много раз оказывался в таких ситуациях — и как инициатор изменений, и как человек, который наблюдает за ними со стороны. Долгое время казалось, что проблема в качестве идей: если идея правильная, она должна взлететь. Если документ сильный — его должны реализовать.
Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.
Привет, Хабр! Меня зовут Никита Елагин, я CTO Островка.
Начну с одного эпизода, который в своё время многое для меня прояснил. Несколько лет назад я сильно нервничал перед one‑to‑one с вице‑президентом по технологиям в СберМаркете. Готовился к этому разговору неделями: прокручивал в голове разные сценарии, думал, как правильно зайти, что сказать, как сформулировать свои мысли, чтобы разговор привёл хоть к какому‑то результату.
В итоге задал собеседнику простой вопрос: «Дим, ты всё успеваешь делать из того, что хочешь?». Он задумался и после паузы ответил, что не всё.
Этот разговор ничего не изменил мгновенно. Я не получил новую роль, не случилось какого‑то резкого скачка. Но именно с этого момента начался другой диалог. Мы начали обсуждать, чего именно не хватает, какие задачи можно забрать, что вообще означает «помочь» в его роли. В какой‑то момент мы даже сформулировали это довольно конкретно: успех — это если появится «ещё 0.8 Димы», то есть человек, который сможет взять на себя значительную часть того, что он сейчас не успевает.
Для меня это был важный момент. Я не приходил с готовым решением, не защищал инициативу и не «продавал себя». Я задал вопрос, который поменял рамку разговора — и дальше из этого начала разворачиваться история: о том, как мой руководитель может успевать почти в два раза больше.
И уже сильно позже я начал замечать, что истории вообще работают на людей гораздо сильнее, чем набор аргументов или правильно оформленные документы.
Они помогают увидеть проблему, примерить изменение на себя и почувствовать, зачем вообще что‑то менять.
Я для себя начал называть это «кампанией историй». И в какой‑то момент понял, что почти все мои удачные и неудачные попытки что‑то изменить — или повлиять на карьерные решения — можно разложить на один и тот же набор шагов:
Понять, зачем мне это вообще нужно.
Разобраться, кого это изменение затрагивает.
Выбрать, кто в этой истории будет «героем».
Научиться рассказывать одну и ту же идею разным людям на понятном им языке.
Поскольку отрицательные примеры особенно наглядны, дальше я разберу несколько ситуаций, где я эти шаги игнорировал — и к чему это приводило (положительные кейсы тоже будут!).
1.Когда не понимаешь, зачем тебе самому это изменение
Одна из первых ситуаций, где я столкнулся с этой проблемой, была ещё в начале карьеры. Я работал с большим инфраструктурным продуктом. В какой‑то момент появилась задача: придумать, как его разделить, чтобы поддержать реорганизацию бизнеса.
Мы решили, что логично выделить инфраструктурный слой, продуктовую платформу и поверх неё строить бизнес‑вертикали. Звучало разумно, и мне эта задача очень зашла. Я с огромным энтузиазмом в неё погрузился. Работал по ночам, читал книги по теме, думал про архитектурные атрибуты системы. Прямо раскладывал в голове: как именно это распилить, почему именно так, где должны проходить границы, чем это поможет бизнесу.
В какой‑то момент у меня получился большой, детальный документ. Я реально верил, что это сильное решение. Документ посмотрели и похвалили. Сказали, что архитектура продумана, всё выглядит логично. И… на этом всё закончилось. Остался просто хороший документ, который ни во что не конвертировался.
Помню, что меня тогда это довольно сильно выбило. Было странное ощущение: вроде бы сделал всё правильно, вложился, разобрался — а в итоге как будто в пустоту. Через какое‑то время я начал разбирать эту ситуацию и понял вещь, которая тогда была для меня неочевидной. Я очень хорошо продумал, как сделать изменение. Но я вообще не думал о том, зачем оно нужно лично мне и что должно произойти дальше.
Для компании ответ у меня был: ускорить разработку, дать бизнес‑юнитам больше независимости, упростить структуру. А для себя — нет. Я не понимал, какого результата я хочу добиться, кто должен принять это решение, где вообще находится точка, в которой это изменение «произойдёт».
И из‑за этого не было ни давления на систему, ни движения. Документ просто остался документом. Сейчас я бы сформулировал это так: если у тебя нет ответа на вопрос «зачем мне это изменение», у твоей истории нет энергии.
И это первый шаг в той самой «кампании историй» — понять свою собственную мотивацию. Не в абстрактном смысле «это полезно для компании», а очень конкретно: что должно измениться, где, за счёт кого и какой следующий шаг ты хочешь увидеть после своей инициативы. Без этого даже очень сильная идея легко превращается в аккуратно написанный, но никому не нужный документ.
2. Когда не понимаешь, кого на самом деле затрагивает изменение
Через некоторое время я перешёл на позицию директора по продукту в одном из бизнес‑юнитов. Структура тогда только формировалась, всё было довольно сырое, и мне казалось, что главная проблема — в процессах. Точнее, в их отсутствии. Было непонятно, как между юнитами ходят задачи, как они трекаются, как принимаются в работу, как работает обратная связь.
Я пришёл к своему руководителю, рассказал, как это вижу. Он согласился: да, проблема есть, давай опишем, как должно работать. И дальше я сделал то, что уже умел: сел и написал большой документ. Очень детальный. Как должна работать Jira, какие статусы, как должны двигаться задачи, как устроен поток, где появляется обратная связь. По сути, попытался с нуля спроектировать систему процессов.
Я был довольно доволен результатом. Казалось, что это реально полезная штука, которая поможет всем. Я зарелизил документ — и получил огромное количество комментариев, в том числе довольно жёстких.
В какой‑то момент до меня дошло, что происходит. В компании уже был человек, который отвечал за продуктовую функцию. Это была его зона ответственности. А я просто взял и сделал его работу — не поговорив с ним заранее. Фактически я пришёл с большим документом и сказал: «Вот так теперь всё должно работать».
То есть я не поговорил ни с разработчиками, которые должны жить в этих процессах; ни с продактами, ни с бизнесом. Я просто подумал: сейчас принесу пользу.
И неважно, насколько хороший получился документ — он был написан без учёта людей, которых это изменение касалось. Сейчас я бы сформулировал это гораздо жёстче: он был написан без уважения к ним. Не потому, что я кого‑то хотел задеть. А потому что я не признал, что у этих людей уже есть своя зона ответственности, свой опыт и своё понимание, как всё должно работать. И, естественно, такая инициатива воспринимается не как помощь, а как вторжение.
В этот момент для меня начал складываться следующий кусок картины: любое изменение почти никогда не живёт в вакууме. У любого руководителя есть свой руководитель. У него есть цели, KPI, бонусы. Есть команда, коллеги, контекст, в котором он принимает решения. И очень часто человек, с которым ты обсуждаешь изменение, вообще не является тем, кто реально принимает решение.
Как в той ситуации: мой прямой руководитель был не единственным и не главным актором в этой истории. Если ты этого не понимаешь, ты можешь сделать сильное предложение — но просто не попасть туда, где принимаются решения. И это второй шаг «кампании историй»: разобраться, кого на самом деле затрагивает изменение.
Не формально — «вот есть команда», а по‑настоящему:
кто владеет областью,
кто влияет на решения,
кто может поддержать,
кто может заблокировать,
и чьи интересы ты затрагиваешь, даже если сам этого не планировал.
Пока у тебя нет этой карты, ты по сути стреляешь вслепую. И даже правильная идея может восприниматься как чужая и нежелательная.
Анти‑кейс: когда я учитывал экосистему
Вернусь немного назад, к временам СберМаркета, когда мы с руководителем уже обсуждали новую роль и то, как я могу в ней состояться. К этому времени я уже учитывал свои предыдущие ошибки. Понимал, что недостаточно просто придумать решение. Недостаточно договориться с руководителем. Недостаточно даже, чтобы он был полностью «за».
Есть команда вице‑президентов. Есть прямая команда, которая должна будет начать репортить другому человеку. У всех этих людей будут вопросы к этому изменению. И если они его не примут, то неважно, хочет этого руководитель или нет — я просто не смогу состояться в этой роли.
Поэтому мы заранее сели и подумали, как работать со всеми этими людьми. Не в момент назначения. А сильно заранее.
С прямой командой я начал работать через их реальные задачи. У каждого инженера и менеджера были свои сложности, и я старался не «продавать» им роль, а помогать решать их проблемы. Где‑то подключался к процессу, где‑то помогал с приоритизацией, где‑то просто разбирал конкретные ситуации.
Параллельно был ещё один важный контекст. В компании менялся CEO. Я понимал, что от нового человека будет зависеть очень многое, и пошёл к нему заранее — ещё до того, как он официально занял позицию. Мы поговорили про инженерные проблемы и про то, что его больше всего беспокоит. Он довольно прямо сказал: проекты выполняются не в нужном объёме, бизнес движется не так, как хотелось бы.
Вместе с продуктовым директором мы взялись за эту задачу. Где‑то за четыре месяца разобрали команды, пересобрали план, посмотрели, какие задачи делаем и почему. В итоге получилось на 20–30% улучшить экономические показатели.
И вот здесь впервые стало видно разницу. Я работал не только с руководителем. Я работал с разными группами людей. Понимал, что важно для каждого из них. И когда меня в итоге официально назначали на эту роль, это не выглядело как неожиданное решение. Не было вопроса «почему именно он». Люди уже понимали, какие задачи я решаю и какую ценность приношу.
3. Когда выбираешь неправильного героя истории
Однажды, анализируя бизнес‑план, я заметил проблему.
У компании была большая ставка на так называемые «новые категории» — электроника, бытовая техника, косметика, цветы и другие направления, помимо основной продуктовой части. Но при этом почти все ресурсы оставались в основном бизнесе. В результате проекты по новым категориям постоянно деприоритизировались. Это уже начинало напрямую угрожать выполнению общего бизнес‑плана.
Я собрал продуктовых директоров из доменов, которые сильнее всего влияли на эту ситуацию, и начал рассказывать, что происходит и что с этим можно сделать. И в какой‑то момент один из коллег говорит: «Ты сейчас выглядишь как принц на белом коне. Пришёл всех спасать».
Здесь до меня дошло, что именно происходит. В комнате сидел человек, который целиком отвечал за новые категории. А я, по сути, публично рассказывал, как надо «чинить» его зону. Я вроде бы говорил правильные вещи правильным людям. Но герой истории был выбран неправильно. Я поставил в центр себя — человека, который увидел проблему и пришёл её решать. А для человека, который отвечает за направление, это выглядит совсем иначе: приходит кто‑то извне и начинает показывать, как надо делать его работу.
В итоге вместо поддержки я получил конфронтацию. И потом пришлось довольно долго восстанавливать нормальные рабочие отношения.
Это был чёткий урок. Когда вы продвигаете изменение, важно не только что вы говорите и кому. Важно ещё и кто в этой истории выглядит главным действующим лицом. Очень часто лучшая версия истории — это не та, где вы «спаситель». А та, где вы помогаете другому человеку стать героем. Где инициатива выглядит не как ваше вторжение, а как его усиление.
И это следующий шаг в «кампании историй»: выбрать правильного героя и правильные роли для участников. Потому что одна и та же идея может восприниматься либо как помощь, либо как атака — в зависимости от того, как распределены роли в истории.
4. Когда ты рассказываешь одну и ту же историю всем
Уже в Островке, с позиции CTO, я смотрел на компанию и видел изменение, которое казалось мне довольно очевидным. На тот момент QA‑инженеры были выстроены в отдельную вертикаль и линейно подчинялись внутри функции вплоть до Head of QA. Мне хотелось сделать эту функцию слабой матрицей: распределить QA по продуктовым командам, чтобы они репортили тимлидам и становились частью общего процесса доставки.
Логика была простой. В такой модели QA начинают сильнее чувствовать продукт: видят, сколько времени задачи проводят в тестировании; понимают, где возникают узкие места; лучше видят качество на выходе; влияют на процесс, а не только проверяют результат. Мне казалось, что это естественный шаг, который должен ускорить организацию.
Я подготовил аргументы, собрал команду и рассказал про это изменение. И очень быстро стало понятно, что что‑то идёт не так. По реакции людей — по лицам, по вопросам, по общей атмосфере — было видно, что большая часть команды не принимает эту идею.
При этом формально я вроде бы всё сделал правильно:
понимал, зачем мне это изменение,
пришёл к людям, которых оно касается,
заранее продумал логику.
Но в итоге мне пришлось отступить и дальше уже обсуждать это изменение индивидуально, с каждым человеком отдельно. И вот в этих разговорах стало понятно, в чём была проблема. Для меня это было одно изменение. Для людей это выглядело по‑разному:
потеря функции,
размытие ответственности,
риск, что качество просто «размажется» по командам,
изменение карьерного трека.
А я пришёл и рассказал одну и ту же историю всем сразу, ожидая, что она одинаково сработает. В этот момент для меня чётко сформулировалась ошибка: каждый человек внутри изменения видит свою версию реальности. И если ты не учитываешь это, никакая «общая презентация» не сработает.
Отсюда следующий шаг в «кампании историй». Когда вы продумываете изменение, важно не просто понять, кого оно затрагивает (это предыдущий шаг), а разобраться глубже: кто уже поддерживает идею, кто к ней нейтрален, а кто в оппозиции. И главное — почему так.
Тех, кто в оппозиции, нужно хотя бы перевести в нейтральную позицию. Нейтральных — постепенно в поддерживающих. И это почти никогда не делается в одном общем разговоре. Это отдельная работа: поговорить, понять, что важно человеку, где у него риск, где страх, где он может выиграть. И только после этого уже имеет смысл собирать всех вместе. Потому что к этому моменту у вас уже не одна история на всех, а набор историй, которые складываются в одну.
У себя в голове я это постепенно собрал в довольно простую схему:
Так изменение начинает восприниматься не как «чужая идея сверху», а как история, в которой человек понимает свою роль.
Анти‑кейс: одна и та же идея, но разные истории
В СберМаркете мы внедряли KPI для инженерной организации. Само по себе звучит довольно тревожно. KPI и инженеры — сочетание, от которого у многих сразу включается защита: сейчас начнут мерить количество строк кода и привязывать к этому бонусы.
Я хорошо понимал, что это изменение потенциально конфликтное. Мы фактически затрагиваем мотивацию людей, а значит — их деньги, оценку работы и ощущение справедливости. В такой ситуации нельзя просто прийти и рассказать одну «правильную» версию.
Поэтому я заранее разделил аудиторию: executive‑команда; инженерные менеджеры; тимлиды. Третья — сама инженерная команда. И дальше началась работа, которая уже была похожа не на презентацию, а именно на кампанию историй.
С executive‑командой разговор был про бизнес:
почему именно эти метрики,
как они связаны с результатами компании,
почему это не инженерная «игрушка», а инструмент, который позволяет управлять скоростью и качеством разработки.
С менеджерами — совсем другая логика. Там важно было не столько «зачем это бизнесу», а:
насколько это справедливо,
как это поможет управлять командами,
не превратится ли это в случайный и токсичный инструмент.
И с ними история строилась вокруг управляемости и прозрачности.
С инженерами — третья версия. Здесь ключевой вопрос был вообще не про бизнес и не про управление. Здесь вопрос был личный:
меня будут оценивать честно?
это не превратится в бессмысленную бюрократию?
И здесь героем становилась уже сама инженерная функция, которая помогает бизнесу, а метрики — это просто способ увидеть и зафиксировать этот вклад.
Важно, что метрики при этом не менялись. Менялась только история.
Одна и та же инициатива может быть воспринята совершенно по‑разному — в зависимости от того, каким языком и в каком контексте ты её рассказываешь. И если ты пытаешься объяснить её всем одинаково, то почти гарантированно проиграешь. А если осознанно собираешь разные версии одной и той же идеи под разные аудитории — у неё появляется шанс «зайти».
Это и есть последний шаг в «кампании историй»: рассказывать одну и ту же идею разным людям на понятном им языке.
А как именно говорить?
По мотивам всех этих историй у меня начал складываться один практический вывод. Перед тем, как продвигать изменение, нужно сначала разобраться, на каком языке про это вообще стоит говорить. И здесь очень помогает подход, который по сути ничем не отличается от продуктового CustDev.
Когда вы делаете продукт, вы не начинаете с решения. Вы идёте к пользователям и пытаетесь понять их проблемы. С изменениями внутри компании работает ровно так же. Если у вас есть идея, не начинайте с того, чтобы её презентовать.
Поговорите с людьми про проблему:
видят ли они её вообще,
есть ли она у них,
насколько она для них важна,
хотят ли они её решать.
И очень часто на этом этапе вскрывается неприятная вещь: то, что для вас выглядит как очевидная проблема, для других людей может вообще не существовать. Или существовать, но быть где‑то внизу списка приоритетов.
Такие вещи обычно становятся видны только в разговорах: когда начинаешь обсуждать проблему с людьми, слушать их реакции и постепенно собирать контекст вокруг изменения.
Все такие разговоры лучше всего работают лицом к лицу. Если у вас есть возможность ходить в офис — используйте её, и если есть one‑to‑one — не превращайте их в формальность. Потому что именно в таких разговорах появляется реальное понимание людей: их настоящие вопросы, сомнения и ожидания.
Например, в той истории, где мы заранее работали со всеми участниками изменения, был ещё один важный эпизод. Я засиделся в офисе с Димой допоздна. В обычной ситуации мы бы просто разошлись, но в тот вечер разговор затянулся. И именно тогда я узнал о новом CEO компании. Там же мы обсудили, что это будет означать для компании и что нужно будет менять в ИТ‑функции. И именно этот разговор стал для меня триггером пойти к новому CEO заранее — ещё до того, как он занял позицию — и поговорить с ним про его ожидания и проблемы.
Если бы этого разговора не было, я бы с высокой вероятностью просто не получил бы этот контекст. А значит — не смог бы подготовиться к изменениям. И это, по сути, довольно универсальное правило.
Если посмотреть шире, все важные вещи до сих пор решаются в личных разговорах. Государства встречаются лицом к лицу. Сложные договорённости не делаются в переписке. И это напрямую связано с тем, о чём вся эта статья. Чтобы выбрать правильный язык и правильную историю, нужно сначала по‑настоящему понять людей. А это почти невозможно сделать на расстоянии.
***
Предлагаем вспомнить последнее изменение или инициативу, которые у вас не взлетели. Как считаете, проблема была в самом решении — или в том, какую историю про него услышали другие люди? Делитесь в комментах!
Материал подготовлен по мотивам доклада на Saint TeamLead Conf 2025 (видеозапись).
Узнавать о новых ИТ‑материалах и событиях Островка можно в тг‑канале Ostrovok Tech.
