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

Антон написал в 23:14. Не вопрос — утверждение: «Мы внедряем OKR, Jobs-to-be-Done и кастдев. Всё правильно делаем, но что-то не так». Я попросил уточнить, что именно «не так». Ответ пришёл через два дня: «Команда работает, метрики растут, а я всё равно чувствую, что едем не туда».

Это был хороший симптом. Плохой диагноз.

Антон строил онлайн-ретейл больше шести лет. Оборот — под полмиллиарда. Несколько десятков человек в команде, выстроенная логистика, работающая юнит-экономика. По меркам российского e-commerce — крепкий средний бизнес, не стартап и не корпорация.

Западными методологиями он увлёкся года за три до нашего знакомства. Сначала — OKR, после того как прочитал Дорра и посмотрел несколько конференций. Потом — Jobs-to-be-Done, когда начал думать о расширении ассортимента. Потом — кастдев в интерпретации нескольких русскоязычных курсов, которые, в свою очередь, пересказывали Бланка и Риса.

Всё это было внедрено. Не на бумаге — реально. Квартальные OKR с командой, регулярные интервью с покупателями, попытки формулировать гипотезы через JTBD-линзу. Антон не был человеком, который читает книги и ничего не делает. Он делал.

И всё равно чувствовал, что едет не туда.

Когда он пришёл ко мне, запрос звучал конкретно: «Помоги настроить OKR правильно. Наверное, мы что-то делаем не так технически». Я выслушал. Кивнул. И предложил начать не с OKR.

Потому что проблема была не в том, как они настраивали инструменты.

Первые две встречи я потратил на то, чтобы понять, как три методологии существуют внутри компании. Не в теории — в реальной жизни команды.

Картина была узнаваемой. OKR превратились в ритуал: квартальные встречи, красивые таблицы, цифры, которые все видят, но никто не использует для принятия решений. JTBD применялся как язык для описания продуктовых гипотез — но без системы проверки: гипотезы формулировались, иногда тестировались, чаще — откладывались. Кастдев шёл нерегулярно, потому что «нет времени», и его результаты существовали в виде заметок в Notion, к которым никто не возвращался.

Три методологии. Ни одна не работала как система. Каждая существовала как отдельный остров.

Здесь важно остановиться и сказать кое-что неудобное про западные фреймворки в российском e-commerce. Они разрабатывались в контексте, где у компании есть: стабильный горизонт планирования, команда с культурой обратной связи, ресурс на эксперименты, инвесторы, которые терпят итерации. В российском среднем бизнесе — особенно в e-commerce — горизонт планирования сжался до квартала, а иногда до месяца. Команда часто не имеет культуры честного разговора о провалах. Ресурса на эксперименты нет — есть ресурс на выживание и рост одновременно.

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

Антон копировал. Добросовестно, старательно — но копировал.

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

Это меняло всё. Потому что «настроить OKR» и «понять, куда расти» — разные задачи, требующие разных инструментов.

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

OKR. Вердикт — убрать как систему целеполагания. Не потому что OKR плохой инструмент. Потому что в компании с горизонтом планирования три-четыре месяца квартальные OKR создают иллюзию стратегии там, где её нет. Антон ставил цели на квартал, но реальные решения принимал исходя из того, что происходит прямо сейчас: поставщик поднял цены, конкурент запустил акцию, маркетплейс изменил алгоритм. OKR не помогали — они создавали дополнительный слой отчётности, который никто не использовал.

Вместо OKR — три приоритета на квартал, сформулированных как вопросы, а не как метрики. «Что мы должны понять про нашего покупателя в этом квартале?» «Какой один процесс нас тормозит сильнее всего?» «Что мы точно не будем делать?» Это не OKR. Это проще. И это работало.

Jobs-to-be-Done. Вердикт — оставить, но в урезанном виде. JTBD как линза для понимания покупателя — полезен. JTBD как система для формулирования всех продуктовых решений — избыточен для команды в несколько десятков человек. Оставили одно применение: перед запуском новой категории или значимым изменением ассортимента — формулировать «работу», которую покупатель нанимает продукт выполнять. Всё остальное — убрали.

Кастдев. Вердикт — переписать под реальные ресурсы. Классический кастдев предполагает регулярные глубинные интервью, анализ, итерации. У Антона не было человека, который мог бы этим заниматься системно. Решение: шесть интервью в квартал, проводит сам Антон, фокус — один конкретный вопрос, ответ на который влияет на решение, которое уже нужно принять. Не «давайте поймём покупателя вообще» — а «нам нужно решить, запускать ли доставку в день заказа; вот что мы хотим понять».

Это звучит как упрощение. Это и есть упрощение. Но работающее упрощение лучше правильной методологии, которую никто не применяет.

Здесь Антон со мной не согласился.

Он хотел сохранить OKR — не как систему, а «хотя бы частично». Аргумент: команда уже привыкла, убирать сложно, будет сопротивление. Я объяснил, что частичный OKR — это как частичная диета: психологически комфортно, результата нет. Антон выслушал. Кивнул. И всё равно оставил квартальные встречи по OKR — просто переименовал их в «стратегические сессии» и убрал формальные метрики.

Это был его выбор. Я с ним не согласен до сих пор. Но это его бизнес.

Через три месяца картина была неоднозначной.

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

Кастдев в упрощённом формате тоже заработал — именно потому что стал конкретным. Антон перестал проводить интервью «про всё» и начал проводить их «про одно». Это изменило качество выводов.

Ощущение «едем не туда» — ушло. Не потому что появилась стратегия. Потому что Антон перестал тратить энергию на поддержание методологических ритуалов и начал тратить её на реальные вопросы.

Плохое: OKR в виде «стратегических сессий» остались. И они по-прежнему не влияют на решения — просто теперь это называется иначе. Команда собирается раз в квартал, обсуждает приоритеты, расходится. Я видел протоколы двух таких встреч. Хорошие разговоры. Никакого влияния на то, что происходит между встречами.

Это компромисс. Не победа.

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

Четвёртый раз за последний год вижу одну и ту же картину: фаундер приходит с методологическим вопросом, за которым стоит стратегический. Методологический вопрос решаем — это техника. Стратегический остаётся открытым — потому что на него страшнее отвечать.

Западные методологии — не проблема и не решение. Они инструменты. Проблема в том, как их применяют.

Есть три вопроса, которые стоит задать перед внедрением любого фреймворка — OKR, JTBD, кастдев, Mochary Method, что угодно ещё.

Первый: какое конкретное решение этот инструмент должен помочь принять? Не «улучшить процессы» — а какое именно решение, которое сейчас висит в воздухе. Если ответа нет — инструмент станет ритуалом.

Второй: у кого в команде есть ресурс применять это регулярно? Не «все должны» — а конкретный человек с конкретным временем. Если такого человека нет — упростить до минимально жизнеспособной версии или не внедрять вообще.

Третий: что мы перестанем делать, если начнём делать это? Методологии не добавляются к существующей нагрузке — они должны что-то вытеснять. Если вытеснять нечего, значит, либо команда недогружена (редкость), либо новый инструмент просто ляжет поверх старых.

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

Похожая история была у фаундера IT-сервиса — не e-commerce, но структурно идентично. Тоже три методологии, тоже ощущение «что-то не так», тоже запрос звучал как технический. Там мы дошли до стратегического вопроса быстрее — потому что фаундер был готов его задать. Результат оказался другим: не компромисс, а реальный сдвиг в позиционировании. Но это отдельная история — она разобрана здесь.

Антон в итоге написал снова. Не в 23:14 — утром, в рабочее время. С другим вопросом. Уже стратегическим.

Иногда компромисс — это просто более длинный путь к тому же месту.

Это единичный случай или типичная история для e-commerce?

Типичная. Онлайн-ретейл — одна из отраслей, где западные методологии копируются особенно активно: много англоязычного контента, активное сообщество, культура «лучших практик». При этом операционная реальность российского e-commerce — высокая волатильность, короткий горизонт, давление маркетплейсов — плохо совместима с фреймворками, разработанными для другого контекста. Это не значит «не использовать». Это значит «адаптировать осознанно».

А если команда уже привыкла к OKR — стоит ли ломать?

Зависит от того, влияют ли OKR на реальные решения. Если влияют — не трогать. Если это ритуал — честно признать это и либо упростить до работающей версии, либо убрать. «Команда привыкла» — слабый аргумент для сохранения инструмента, который не работает. Сопротивление при отказе от ритуала обычно меньше, чем кажется заранее.

Что делать, если я вижу у себя похожее — методологии есть, ощущение 'не туда' есть?

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

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

Работаю с фаундерами и собственниками бизнесов от 80 миллионов выручки. Беру до трёх заявок в неделю на стратегический разбор. Пиши на hi@vvetrov.com: кто ты, какой бизнес, в чём вопрос.

Если думаешь «у меня всё иначе, методологии работают» — хорошо. Значит, не ко мне. Если думаешь «похоже на моё» — приходи.

P.S. Антон написал снова через полгода. Уже с другим вопросом. Уже утром.

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