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

Когда фаундер говорит «нам нужен западный фреймворк» — он обычно имеет в виду что-то конкретное.

Чаще всего — OKR. Иногда Agile. Иногда Jobs to Be Done, если недавно читал правильную книгу. Иногда Mochary Method — если читал не книгу, а статью о том, как Mochary работает с CEO из Кремниевой долины.

Проблема не в том, что эти методологии плохие.

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

Не «что взять». А «зачем вообще брать».

Шестой раз за последние два года слышу одну и ту же историю. Детали разные — e-commerce, производство, IT-сервис. Суть одна.

Фаундер читает книгу или статью. Загорается. Внедряет. Через полгода — тихо хоронит. Через год — снова читает. Другую книгу. Другой фреймворк.

Это не про методологии. Это про тревогу.

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

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

Один клиент — e-commerce в сегменте товаров для дома, выручка около 200 миллионов — внедрял OKR три раза. Первый раз сам, по книге Дорра. Второй раз с консультантом. Третий раз «по-настоящему, с обучением команды». После третьего раза он пришёл ко мне не с вопросом «как внедрить OKR правильно». Он пришёл с вопросом: «Почему это вообще не работает у нас».

Это уже правильный вопрос.

Три методологии, которые дают что-то реальное в e-commerce. Без восторга — просто наблюдение из практики.

Jobs to Be Done.

Это не про продукт. Это про то, зачем человек его покупает. Не «что он покупает», а «какую работу он нанимает этот продукт выполнить».

В e-commerce это работает потому, что большинство фаундеров думают категориями товаров и категорий. JTBD заставляет думать категориями ситуаций и мотивов. Это меняет и ассортиментную логику, и коммуникацию, и то, как строится карточка товара.

Главное — JTBD не требует консультанта. Требует честных разговоров с покупателями. Пяти глубоких интервью достаточно, чтобы увидеть то, чего не видит никакая аналитика.

Что не брать из JTBD: академическую надстройку. Есть версии методологии, которые превращаются в многостраничные фреймворки с матрицами. Это уже не инструмент — это ритуал.

Lean.

Из Lean в e-commerce работает одна вещь: устранение потерь в операционке. Не как философия, не как производственная система — а как конкретный вопрос: «где мы тратим время и деньги на то, что не создаёт ценность».

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

Что не брать: Lean как культуру. «Бережливое производство» как идеологию. В российском МСБ это не приживается — не потому что люди плохие, а потому что для культурных изменений нужна другая глубина и другой горизонт.

Mochary Method.

Это не методология для компании. Это инструмент для CEO.

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

В e-commerce это работает для фаундера, который вырос из операционки — или пытается вырасти. Mochary даёт язык для разговора с собой о том, что происходит. Это ценно.

Что не брать: Mochary как систему управления компанией. Он написан для стартапов с венчурным финансированием и командами, которые привыкли к письменной культуре. В российском e-commerce с командой 30–80 человек это работает частично — и только если фаундер сам в это верит.

OKR.

Честно: в российском e-commerce с выручкой до 500 миллионов OKR почти никогда не работает так, как описано в книгах.

Не потому что «мы другие» или «у нас особый менталитет». Это ленивое объяснение.

Потому что OKR требует определённой зрелости планирования. Требует, чтобы компания умела формулировать цели — не задачи, не KPI, а именно цели с измеримыми результатами. Требует культуры прозрачности, где команда видит, что происходит на уровне выше.

В большинстве e-commerce компаний этого нет. Не потому что плохо — просто не выстроено. И внедрение OKR поверх этого — это как строить второй этаж без фундамента.

Результат предсказуем: красивые таблицы, которые никто не читает. Квартальные ритуалы, которые все ненавидят. И ощущение, что «мы попробовали — не пошло».

Agile в операционке.

Agile — это про разработку продукта в условиях неопределённости. Про итерации, про быстрые циклы обратной связи, про то, что требования меняются.

В операционке e-commerce требования не меняются так быстро. Там другая проблема — не неопределённость, а исполнение. Не «что делать», а «как сделать стабильно и предсказуемо».

Agile в операционке обычно даёт одно: ощущение динамики без реального движения. Много встреч, много стикеров, много «спринтов» — и примерно те же результаты, что были до.

Это не значит, что Agile плохой. Это значит, что он не для этого.

Прежде чем брать любую методологию — западную или отечественную — есть один вопрос.

Что именно не работает.

Не «нам нужна система». Не «нам нужна структура». А конкретно: где именно ломается. Где теряются деньги. Где команда не договаривается. Где решения принимаются медленно или неправильно.

Это диагностика. Она скучная. Она требует честности — особенно с собой. Она не даёт ощущения движения вперёд, которое даёт чтение новой книги о фреймворках.

Но именно она определяет, нужна ли вам вообще какая-то методология — или нужно что-то другое.

Иногда проблема не в отсутствии системы. Иногда проблема в том, что фаундер не может делегировать — и никакой фреймворк это не исправит. Иногда проблема в том, что команда не доверяет друг другу — и OKR это не починит. Иногда проблема в том, что сам фаундер не понимает, куда идёт компания — и Lean тут ни при чём.

Методология — это язык. Хороший язык помогает команде говорить об одном и том же.

Но сначала нужно понять, о чём вы вообще молчите.

Это не для тех, кто ищет список методологий с оценками и звёздочками. Это для тех, кто уже пробовал — и чувствует, что что-то не так.

Смежные материалы: Разбор: как работает Mochary Method в российских реалиях · Что взять из западных методологий для IT-компании · Фреймворк X: применение в практике российского МСБ

Раз в две недели присылаю материалы, которые сюда не попадают. Форма — в футере.

P.S. Если после этого хочется поговорить конкретно — пишите на hi@vvetrov.com.

Июль 2026. Автор — Виталий Ветров.