Ты купил книгу. Или посмотрел выступление на YouTube. Или кто-то из знакомых сказал: «Слушай, вот эта штука реально работает — у них там целая система».
И ты попробовал.
Взял фреймворк — красивый, логичный, с матрицами и последовательными шагами. Начал внедрять. Провёл сессию с командой. Нарисовал схему на флипчарте. Назначил ответственных.
Через три месяца стало непонятно: то ли метод не работает, то ли ты что-то делаешь не так, то ли команда не та.
Это письмо — про то, что именно происходит в этот момент. И почему это происходит почти всегда.
Это письмо не про тебя, если ты только начинаешь и ещё не столкнулся с первым провалом внедрения. Оно про тебя, если ты уже пробовал — и что-то пошло не так. Или если ты сейчас стоишь перед выбором: брать чужую систему или нет.
Есть одна закономерность, которую я наблюдаю уже лет десять.
Чем умнее фаундер — тем быстрее он внедряет чужую систему.
Это не ирония. Это наблюдение. Умные люди умеют читать. Умеют видеть логику. Умеют быстро схватывать структуру. И именно поэтому они берут готовый фреймворк и начинают применять его раньше, чем успевают задать главный вопрос: а для какого контекста это было создано?
Западные методологии управления — OKR, Agile, Mochary Method, EOS, Scaling Up — создавались в конкретных условиях. Венчурный капитал. Горизонтальные структуры. Культура прямой обратной связи. Сотрудники, которые читали те же книги, что и CEO.
Российский МСБ с выручкой от 80 до 500 миллионов — это другой мир.
Не хуже. Просто другой.
Здесь директор по продажам может быть другом детства собственника. Здесь финансовый директор иногда узнаёт о стратегических решениях из разговора в коридоре. Здесь «культура обратной связи» — это когда сотрудник после совещания подходит и говорит тихо: «Виталий Петрович, я вот что думаю…»
Ко мне пришёл Андрей — производство, около 200 миллионов выручки, восемь лет в бизнесе. Пришёл с распечатанной презентацией. Сказал: «Я внедрил OKR. Три квартала. Не работает. Объясни, что я делаю не так».
Я посмотрел на его OKR. Они были правильными. Технически — почти идеальными. Цели измеримые, ключевые результаты конкретные, дедлайны проставлены.
Я спросил: «Кто их писал?»
Он ответил: «Я».
Вот и всё.
Фреймворк — это не инструкция. Это язык.
Когда ты берёшь западную методологию и переносишь её в российский МСБ, ты пытаешься говорить на языке, который твоя команда не учила. И ты сам учил его по книге, а не в живой среде.
Есть три точки, где перенос ломается почти всегда.
Первая — контекст принятия решений.
В большинстве западных фреймворков предполагается, что решения принимаются коллегиально, прозрачно, с документацией. В российском МСБ решения часто принимаются собственником — быстро, интуитивно, иногда в машине по дороге на встречу. Это не плохо. Это просто другая скорость и другая логика. Фреймворк, который требует трёхнедельного цикла согласования целей, в этой среде не приживается — не потому что люди ленивые, а потому что ритм не совпадает.
Вторая — люди.
Методологии создавались для людей, которые выросли в культуре горизонтальных коммуникаций. Где нормально сказать руководителю: «Я не согласен, вот моя аргументация». Где «я не знаю» — это не слабость, а честность. В российском МСБ эта культура есть — но она другая. Она строится на личном доверии, на неформальных разговорах, на том, что называется «понимать с полуслова». Фреймворк, который игнорирует это — не работает. Не потому что люди плохие. А потому что инструмент не под руку.
Третья — скорость адаптации.
Любой фреймворк требует времени на освоение. В стартапе с венчурным финансированием это время есть — инвесторы понимают, что первые полгода уйдут на настройку процессов. В МСБ с живым оборотом и реальными обязательствами перед поставщиками и сотрудниками — этого времени нет. Собственник не может позволить себе три квартала «внедрения», после которых непонятно, работает ли это.
Андрей внедрял OKR в одиночку. Его команда смотрела на таблицы с целями и не понимала, зачем это нужно. Не потому что они глупые. А потому что никто не объяснил им на их языке — что изменится в их работе и почему это важно именно сейчас.
Фреймворк не виноват. Перенос без адаптации — вот что убивает.
И вот здесь — самое важное. То, о чём обычно не пишут в книгах про методологии.
Прежде чем брать любой фреймворк — западный, отечественный, придуманный самостоятельно — есть три вопроса. Я задаю их себе. Я задаю их клиентам. Они простые. Но ответить на них честно — сложно.
Вопрос первый: для чего именно мне это нужно?
Не «чтобы было как у нормальных компаний». Не «потому что я прочитал и понял, что это правильно». А конкретно: какую проблему я пытаюсь решить? Что сейчас не работает — и почему я думаю, что этот инструмент поможет именно с этим?
Большинство фаундеров, которые приходят ко мне с «не работающим фреймворком», не могут ответить на этот вопрос. Они внедряли систему потому что она казалась правильной. Не потому что у них была конкретная боль, под которую эта система создавалась.
Вопрос второй: кто в моей команде это понесёт?
Не «кто будет отвечать за внедрение» в смысле административной ответственности. А кто реально понимает, зачем это нужно, и может объяснить это другим на их языке. Если такого человека нет — фреймворк не приживётся. Собственник не может быть единственным носителем смысла.
Вопрос третий: что я готов изменить в себе?
Это самый неудобный вопрос. Большинство методологий требуют изменений не только в процессах, но и в поведении первого лица. OKR не работает, если собственник продолжает принимать решения в обход целей. Agile не работает, если руководитель требует детального планирования на год вперёд. Любой фреймворк — это в том числе про тебя.
Я сам через это прошёл.
Несколько лет назад я пытался внедрить в работу своей команды систему еженедельных структурированных встреч по одной из популярных методологий. Красивая система. Логичная. Я был уверен, что это изменит качество нашей работы.
Через два месяца я понял, что встречи превратились в ритуал. Люди приходили, заполняли таблицы, говорили правильные слова. И ничего не менялось.
Я остановился и спросил себя: а что я сам делаю по-другому после этих встреч?
Ответ был неудобным.
Ничего.
Я требовал от команды изменений, которые сам не был готов производить. Система работала как зеркало — и отражала не команду, а меня.
Есть разница между адаптацией и копированием.
Адаптация — это когда ты берёшь принцип, понимаешь, зачем он работает, и находишь форму, которая подходит твоей среде. Копирование — это когда ты берёшь форму и надеешься, что принцип подтянется сам.
В российском МСБ копирование почти никогда не работает. Адаптация — работает. Но требует времени, честности и готовности выбросить половину того, что казалось важным в оригинале.
Я не против методологий. Я против слепого применения.
Хорошая методология — это карта. Карта не территория. Если карта говорит, что здесь дорога, а ты видишь болото — верь болоту.
Посмотри также: Что взять из западных методологий для IT-компании: разбор — там я разбираю конкретные инструменты, которые приживаются, и те, которые нет.
Андрей в итоге не выбросил OKR.
Мы провели три часа — разобрали, что именно не работало. Оказалось, что проблема была не в методологии, а в том, что цели писал он один, без команды. И команда не чувствовала их своими.
Мы переделали процесс. Не по книге — под его компанию, под его людей, под его ритм. Через квартал он написал: «Работает. Не идеально, но работает».
«Не идеально, но работает» — это, честно говоря, лучший результат, на который можно рассчитывать в первый год.
Идеально — это иллюзия. Работает — это реальность.
Если это письмо попало в точку — значит, ты уже задаёшь правильные вопросы. Это само по себе немало.
Если захочется поговорить — пиши на hi@vvetrov.com. Без запроса, без темы. Просто напиши, что происходит. Иногда именно так получается самый точный разговор.
Или посмотри разбор кейса по этой же теме — там конкретнее, с цифрами и деталями.
P.S. Я не продаю методологии. Я помогаю разобраться, нужны ли они тебе — и если да, то в какой форме. Иногда ответ: не нужны. Это тоже результат.
Короткие наблюдения из практики — в Telegram: @vvetrovcom. Там я пишу короче и честнее, чем здесь. Иногда — одним абзацем. Иногда — одним вопросом.
Апрель 2026. Автор — Виталий Ветров, стратегический советник.