Что взять из западных методологий для IT-компании: из опыта советника

Антон пришёл с распечаткой. Семьдесят страниц — Scaling Up Хорнольда, подчёркнутые маркером, с пометками на полях. «Я хочу внедрить это у себя», — сказал он. Я спросил: «Всё?» Он кивнул.

Мы потратили три месяца, чтобы понять, что именно «всё» — это не вопрос желания, а вопрос диагностики. Часть методологии прижилась. Часть — нет. Это кейс о том, что именно и почему.

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

Он был из тех фаундеров, которые читают много и системно. Не для галочки — для применения. Полки в кабинете: Коллинз, Хорнольд, Лалу, Дорр. Всё с закладками. Это само по себе не плохо — это признак человека, который ищет язык для того, что чувствует интуитивно.

Запрос звучал так: «Я понимаю, что нам нужна система управления. Я нашёл её — вот она. Помоги внедрить». Scaling Up — методология масштабирования бизнеса, разработанная Верном Хорнольдом на основе работ Рокфеллера. Четыре блока: люди, стратегия, исполнение, деньги. Внутри — конкретные инструменты: ритм встреч, приоритеты, функциональная ответственность, BHAG.

Для IT-компании на стадии Антона это выглядело логично. Методология известная, проверенная, с кейсами из американских tech-компаний. Я понимал привлекательность.

Я попросил его отложить распечатку. Сначала — диагностика.

Поверхностный запрос — «внедрить методологию» — я слышу часто. За ним почти всегда стоит что-то другое. Задача советника на входе — понять, что именно.

В случае Антона поверхность выглядела так: компания растёт, но управление не успевает за ростом. Фаундер перегружен, команда работает по инерции, приоритеты меняются каждую неделю. Классическая картина для IT-сервиса на восьмом году жизни.

Под поверхностью обнаружилось три слоя.

Первый слой — отсутствие ритма. Не было регулярных управленческих встреч с чёткой повесткой. Были хаотичные созвоны, которые решали оперативные вопросы, но не двигали стратегию. Команда не знала, что важно на этой неделе, — каждый додумывал сам.

Второй слой — размытая ответственность. Сорок с лишним человек, но функциональные роли не были чётко закреплены. Несколько человек отвечали за одно и то же — и никто не отвечал по-настоящему. Это типичная история для компаний, которые выросли органически, без намеренного проектирования структуры.

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

Реальная проблема оказалась не там, где Антон думал.

Здесь начинается самое интересное — и самое практически полезное для тех, кто думает о западных методологиях для своей IT-компании.

Мы прошлись по Scaling Up инструмент за инструментом. Не с позиции «работает / не работает в России» — это слишком грубое деление. А с позиции: что соответствует текущей зрелости процессов в компании Антона, а что требует фундамента, которого ещё нет.

Что взяли и что прижилось.

Ритм встреч — ежедневные стендапы для команды, еженедельные управленческие встречи с фиксированной повесткой, ежеквартальные сессии по приоритетам. Это сработало почти сразу. Не потому что это Scaling Up — а потому что любая регулярность лучше хаоса. Методология дала язык и структуру, которую команда приняла легче, чем если бы Антон придумал её сам.

Приоритеты в формате «топ-5 на квартал» — упрощённый аналог OKR, без жёсткой метрической привязки. Для компании, где раньше приоритеты менялись еженедельно, это был шаг вперёд. Не идеальный инструмент, но работающий.

Функциональная ответственность — закрепление конкретных функций за конкретными людьми через инструмент «функциональная подотчётность» (в Scaling Up это называется Function Accountability Chart, FACe). Это вскрыло несколько болезненных разговоров о том, кто реально тянет свою функцию. Антон их не избежал — и это было правильно.

Что отложили.

BHAG — Big Hairy Audacious Goal, большая дерзкая цель на 10–25 лет. Инструмент хорош для компаний с устойчивой культурой и командой, которая разделяет долгосрочное видение. У Антона команда была в середине перестройки — часть людей уходила, часть приходила. Формулировать BHAG в этот момент — значит строить на зыбком фундаменте. Отложили на год.

Quarterly themes — тематические лозунги квартала, которые должны объединять команду вокруг общего фокуса. В американских tech-компаниях это работает как культурный клей. В российском IT-сервисе среднего размера это воспринималось как корпоративная игра. Команда не верила в лозунги — и правильно делала. Выбросили без сожаления.

Часть HR-практик — в частности, детализированные профили должностей и системы оценки по компетенциям из методологии. Не потому что плохие инструменты. Потому что для их внедрения нужен HR-директор или хотя бы сильный HR-менеджер. У Антона этой функции не было — был один человек, который занимался кадровым делопроизводством. Внедрять сложные HR-инструменты без носителя функции — значит создать документы, которые никто не использует.

Здесь возникло главное возражение, которое я слышу каждый раз: «Это же западная методология, у нас она не работает». Это неточная формулировка. Работает или не работает не методология — работает или не работает конкретный инструмент в конкретном контексте. Ритм встреч работает везде. BHAG требует зрелости. Quarterly themes — культурного контекста. Это не вопрос географии, это вопрос диагностики.

Мы выбросили треть. И это было правильное решение.

Через год картина была компромиссной. Не провал — но и не та трансформация, которую Антон рисовал в голове, когда приходил с распечаткой.

Что реально изменилось: управленческий ритм появился и держится. Команда знает, что происходит на этой неделе и на этом квартале. Функциональная ответственность закреплена — хотя несколько человек в процессе оказались не на своих местах и ушли. Это было болезненно, но неизбежно.

Что осталось на бумаге: полноценная стратегическая сессия по Scaling Up так и не состоялась в том формате, который предполагает методология. Антон несколько раз переносил её — сначала из-за операционных пожаров, потом из-за кадровых изменений. Я настаивал. Он соглашался и переносил снова. Это его выбор — я его уважаю, но фиксирую.

Где я ошибся в оценке: я недооценил сопротивление одного из топ-менеджеров — человека, который формально поддерживал изменения, но фактически саботировал внедрение ритма встреч. Я видел сигналы, но решил, что Антон справится с этим сам. Не справился — потребовалось ещё три месяца и отдельный разговор, чтобы ситуация разрешилась.

Через год Антон сказал мне кое-что, чего я не ожидал.

«Я думал, что методология даст мне систему. Она дала мне язык. Это оказалось важнее». Это точная формулировка. Scaling Up не стал операционной системой компании — он стал общим словарём, через который Антон и его команда начали говорить об управлении. Это компромиссный результат. Но это результат.

Четвёртый раз за последние два года вижу одну и ту же картину: фаундер IT-компании приходит с западной методологией и желанием внедрить её целиком. Scaling Up, Mochary Method, EOS, иногда что-то экзотичнее. Запрос звучит как «помоги внедрить». Реальный запрос — «помоги разобраться, что у меня происходит».

Методологии — это не продукты. Это языки описания управленческой реальности. У каждого языка есть словарь, грамматика и контекст, в котором он возник. Американский tech-контекст — это венчурные деньги, быстрый найм, культура OKR, горизонтальные структуры. Российский IT-сервис среднего размера — это другой контекст. Не хуже и не лучше. Другой.

Это не значит, что западные методологии бесполезны. Это значит, что их нужно читать как источник инструментов, а не как инструкцию по применению.

Три вопроса, которые я задаю перед любым внедрением:

Первый: есть ли носитель функции? Любой инструмент требует человека, который будет его поддерживать. Нет HR-директора — не внедряй сложные HR-инструменты. Нет операционного директора — не строй сложную систему KPI. Инструмент без носителя — это документ в папке.

Второй: какова зрелость базовых процессов? Scaling Up предполагает, что у компании уже есть работающие базовые процессы — найм, финансовый учёт, операционный ритм. Если их нет — методология будет надстройкой над хаосом. Сначала база, потом надстройка.

Третий: что фаундер избегает через методологию? Это самый важный вопрос. Иногда методология — это способ не говорить о конкретных людях, о партнёрских конфликтах, о собственной роли в проблеме. Методология не решает эти вопросы. Она их маскирует.

Параллельный случай: другой фаундер, другая IT-компания, другая методология — EOS (Entrepreneurial Operating System). Пришёл с похожим запросом. Мы прошли ту же диагностику. Обнаружили, что реальная проблема — не в отсутствии системы управления, а в нерешённом партнёрском конфликте. EOS здесь не помог бы ничем. Сначала — партнёрский вопрос, потом — операционная система. Он это принял. Результат оказался лучше, чем у Антона, — потому что мы не тратили время на инструменты, пока не разобрались с фундаментом. Подробнее об этом — в кейсе «Как партнёры уничтожили бизнес за полгода».

Инсайт, который я выношу из таких кейсов: IT-компании особенно склонны к методологическому фетишизму. Это профессиональная деформация — люди, которые строят системы, хотят управлять через системы. Это понятно. Но управление бизнесом — это не только архитектура. Это ещё и люди, которые в этой архитектуре живут. И они не всегда ведут себя как предполагает методология.

Если хочешь разобраться, как применять западные методологии в российском контексте — посмотри также разбор Mochary Method в российских реалиях и практику применения фреймворков в российском МСБ. Там другие углы той же темы.

Это единичный случай или это типично для IT-компаний? Типично. За последние два года я видел похожую картину несколько раз — разные методологии, разные компании, одна структура запроса. Фаундер находит язык, который описывает его проблему, и хочет применить его целиком. Диагностика почти всегда показывает, что реальная проблема сложнее, чем кажется на входе.

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

Что делать, если я вижу у себя похожую картину? Начать с диагностики, а не с выбора методологии. Три вопроса из последнего раздела — хорошая точка входа. Если после честных ответов на них методология всё ещё выглядит как правильный следующий шаг — значит, вы готовы к разговору о том, какую именно и в каком объёме.

Та распечатка до сих пор лежит у меня в папке. Антон забыл её забрать.

Если этот кейс читается как твоя история — не обязательно про методологии, достаточно сходства по структуре: есть инструмент, есть желание, нет ясности что именно и как — приходи на разбор.

Если ты читаешь это и думаешь «у меня другое, я уже разобрался» — возможно, так и есть. Но если ты узнаёшь в Антоне что-то своё — стоит поговорить.

Работаю с фаундерами и CEO IT-компаний с выручкой от 80 миллионов. Беру не больше двух новых advisory-клиентов в квартал. Напиши на hi@vvetrov.com — кто ты, что за компания, с каким вопросом пришёл.

P.S. Методология — это язык. Но разговор всё равно придётся вести тебе.

Апрель 2026. Автор — Виталий Ветров, стратегический советник и управляющий партнёр юридической фирмы.