Двигаю задачи | Алексей: разработка, управление, процессы

Первый выход в офлайн: репрайсер на SIM 2026 — опыт участия в конференции «Селлеры и маркетплейсы»

Wed, 04 Mar 2026 09:19:46 +0300

Конференция «Селлеры и маркетплейсы 2026»: первый офлайн-опыт с репрайсером

Давно не писал. Последние пару недель выдались напряжёнными и продолжают такими быть. На прошлой неделе мы впервые вывели продут в офлайн и поехали на конференцию селлеры и маркетплейсы. Это был первый ивент для продукта, и первый для компании за долгое время.

Выставка проходила в Кластере Ломоносов. Само пространство классное — современное, аккуратное, технологичное. Но локация, мягко говоря, не самая удобная ощущение «у чёрта на куличиках». Возможно, это тоже повлияло на трафик. В целом прошло порядка 1000–1500 человек за два дня. Мы ожидали большего потока, но аудитория оказалась довольно узкой и профильной, что для нас скорее плюс.

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

Лучше всего нас понимали производители и дистрибьюторы. У них другой горизонт планирования и другой взгляд на управление ценой. Селлеры же, для которых в фокусе оборот и маржинальность здесь и сейчас, реагировали ожидаемо: «Как можно жертвовать СПП?» В этих диалогах мы выглядели почти сумасшедшими, но это нормально — просто разные модели мышления и разные цели бизнеса.

Почти в каждом разговоре поднимался вопросы: чем вы отличаетесь от конкурентов, они стояли через пару стендов от нас и в чем отличия форматов: SaaS или коробка. Если объёмы небольшие — логичен SaaS. Если большие, с требованиями к инфраструктуре и контролю — коробка. Мы сознательно развиваем оба направления, потому что всё зависит от потребностей клиента.

По цифрам: собрали порядка 30 контактов, из них около 10 — действительно суперцелевые. Плюс дополнительно пообщались по внедрению CRM и заказной разработке — неудивительно, проблемы у всех похожие. Сейчас разбираем контакты и назначаем ВКС, по итоговой конверсии говорить рано, но первый срез уже позволяет сделать вывод.

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

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

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

В результате приняли решение публично вести лог изменений на сайте, скоро он появится на сайте. Туда будем складывать все крупные и средние доработки по проекту.
Поедем ли ещё? Да. Несмотря на экономику в пользу контекста, минимум одну выставку летом и одну осенью планируем. Увидимся в офлайне.

Черные лебеди в SaaS: как один закон и один анонс могли похоронить наш продукт

Thu, 19 Feb 2026 12:26:40 +0300

Иногда ты просыпаешься утром и понимаешь, что твоего продукта может просто не стать.

Не потому что плохой код или ушли клиенты, а потому что где-то приняли решение, которое меняет правила игры. 2026 год для нас начался именно так — с двух анонсов, которые теоретически могли обнулить рынок репрайсеров.

Закон, который мог обнулить рынок

С 1 октября 2026 года в России вступает первый закон о платформенной экономике. Он регулирует маркетплейсы, сервисы доставки, такси и другие цифровые площадки-посредники. Государство фиксирует правила для огромного рынка, делая его более прозрачным и управляемым, но при этом не вмешивается напрямую в экономику платформ.

Маркетплейсы больше не смогут резко менять условия: о повышении комиссий, штрафов и изменении правил нужно уведомлять за 45 дней. Запрещены необоснованные блокировки, вводится обязательная система досудебных споров. Площадка не может снижать цену без согласия продавца — можно установить минимальную цену.

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

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

Репрайсер от Ozon

Вторым «чёрным лебедем» стал анонс собственного репрайсера от Ozon для WB и Ozon. Пока это пилот для ограниченного числа продавцов, но сам факт выхода платформы в эту зону — сигнал. Если маркетплейс делает собственный инструмент, логичный вопрос: зачем тогда сторонние сервисы?

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

История знает немало внутренних продуктов крупных компаний, которые так и не стали массовыми. Вспоминается целое кладбище инициатив того же Яндекса. Поэтому пилот — это ещё не приговор, но сигнал, который нельзя игнорировать.

Что это значит для нас

Самое важное в этой истории — не закон и не Ozon. А то, что SaaS, построенный вокруг платформ, зависит от чужих решений. Сегодня ты оптимизируешь их экономику, завтра они меняют правила или выходят со своим инструментом.

При этом реальность сложнее и не сводится к драме. У нас есть решение для Яндекс Маркета, и сейчас это сильная сторона. Рынок постепенно движется в сторону модели, похожей на США, где платформы усиливают контроль над экономикой, а выигрывают в первую очередь производители. Если этот тренд закрепится, инструменты управления ценой никуда не исчезнут — просто изменится их роль.

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

Математика против пороговых скидок

Fri, 13 Feb 2026 09:16:41 +0300

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

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

С аутричем вышла интересная история. Мы его протестировали и пока притормозили. На старте казалось, что выйти на нужных селлеров будет относительно просто, но реальность оказалась сложнее. Достучаться до правильного человека в e-commerce куда труднее, чем кажется изнутри продукта. Это не значит, что канал плохой, но усилий он требует больше, чем мы закладывали.

Зато отлично себя показывает контекстная реклама. Сейчас получаем квалифицированных лидов примерно по 1500 рублей, и для нашей экономики это рабочая модель. Плюс постепенно начинает давать результат SEO. Не быстрый инструмент, но устойчивый. Параллельно развивали сайт и в итоге перевезли его на Битрикс — редактировать контент становилось все сложнее, а продукт растет, информации становится больше. Нужно было навести порядок, иначе начинаются операционные косты там, где их можно было избежать.

Также добавили новые направления по работе с Lamoda, Лемана Про и М.Видео. Расширяем покрытие аккуратно, без резких движений, но последовательно.

Эксперимент с биллингом вместо тарифов

Отдельно расскажу про изменение модели оплаты. Раньше у нас были просто тарифы. Но по факту запросы клиентов оказались слишком разными. У кого-то десятки товаров, у кого-то тысячи. У кого-то агрессивная частота обновления, у кого-то спокойный режим. В рамках фиксированных тарифов это начинало ломать логику.

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

Нелинейные скидки — главная математика

Продолжаем бороться с нелинейными скидками и авторизацией. Если вы продаете на маркетплейсах, то наверняка замечали, что цены могут сильно отличаться для разных покупателей. Влияет регион, выбранный ПВЗ, логистика, персональные механики площадки. Это делает задачу репрайсинга куда сложнее, чем кажется со стороны.

Мы отказались от индивидуальной авторизации под каждого клиента и перешли к единой авторизации для Ozon и Яндекс Маркета, которая смотрит цены как покупатель в Москве. Пока мониторим стабильность решения. Если покажет себя хорошо, добавим еще 3–5 регионов для сравнения.

А теперь пример, чтобы было понятно, в чем сложность. Товар на Яндекс Маркете. Передаем цену 5124 ₽ — покупатель видит 3293 ₽. Передаем 5224 ₽ — покупатель видит уже 4112 ₽. Мы меняем входную цену всего на 100 рублей, а итоговая цена для покупателя скачет почти на 1000. Это эффект пороговой скидки, и он ломает линейную логику расчета.

Чтобы работать с такими сценариями, мы разработали новую стратегию расчета с использованием естественного и искусственного интеллекта. Формула стала сложнее и требует большего количества шагов, но зато позволяет точнее подбираться к целевому значению. Важно понимать, что при старте нового профиля нужно 3–4 запуска, чтобы система собрала статистику и вычислила рабочие цены. Это не баг, это этап калибровки.

Фичи к выставке и упрощение онбординга

К ближайшей выставке допиливаем две функции, которые давно просили клиенты. Первая — возможность принудительного ручного запуска всех товаров или конкретного товара из личного кабинета. Раньше такая опция была только у админов, и это, честно говоря, было недальновидным решением.

Вторая — упрощенная форма создания профиля. Сейчас интерфейс во многом выглядит как панель программистов для программистов, что не лучшим образом влияет на онбординг. Мы делаем сценарий проще: нажимаешь «Создать», выбираешь маркетплейс, вводишь токен, выбираешь товары, ставишь РРЦ, задаешь частоту обновления — и запускаешь. Минимум лишних шагов.

При этом даже в текущем, не самом простом интерфейсе, есть пользователи, которые самостоятельно создают и запускают профили без нашей помощи. Это хороший сигнал.

Движение без иллюзий

Есть и другие мелкие задачи, которые решаем по мере поступления. Продукт постепенно взрослеет. Где-то через эксперименты, где-то через пересборку модели оплаты, где-то через математику скидок, которая на бумаге выглядит красиво, а в реальности ведет себя совсем иначе.

Работаем дальше. Увидимся на выставке. Буду рад пообщаться лично и обсудить, как у вас устроена экономика на маркетплейсах.

Яндекс Кит для интернет-магазина: что это, как работает и стоит ли запускать сайт

Wed, 04 Feb 2026 10:26:41 +0300

Новое начало маленьких интернет-магазинов?

Кажется, ниша небольших интернет-магазинов на WP и Тильде либо умирает, либо уверенно движется в эту сторону. И нет, это не про вайб-кодинг — он только расправляет крылья, посмотрим, куда его занесёт. Сегодня хочется поговорить про другое. Про Яндекс Кит.

Мы недавно участвовали в вебинаре для партнеров, кого пригласили посмотреть продукт изнутри. И вот что он из себя представляет.

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

С этим у Кита как раз всё неплохо. Базовый набор — ровно то, что нужно: обмен с 1С, «МойСклад», Яндекс Маркет, интеграция с Ozon и WB, retailCRM, amoCRM, Bitrix24. Можно подключить свой домен, фирменный стиль по мелочи, всё как положено.
По оплатам — Яндекс Pay и CloudPayments.
По логистике — Яндекс, СДЭК, Ozon Логистика.

В итоге со старта получается очень приятный и взрослый набор, без ощущения «песочницы».

Отдельно стоит сказать про одну из ключевых фишек — бесшовную интеграцию с Yandex ID. Что это даёт на практике? Более высокую конверсию за счёт того, что данные пользователя уже заполнены. А если карта привязана — покупка превращается буквально в пару кликов. Для небольшого интернет-магазина это огромная разница.

Про дизайн. Его можно кастомить, но без фанатизма — и это, кажется, осознанный выбор. Изначально Кит отлично ложится на fashion-сегмент, под который он, по ощущениям, и делался. Если хочется «вау-уникальность» или каких то супер кастомных интеграций — это не сюда. Если хочется быстрее начать продавать — вполне.

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

Но реальность сейчас такая: если ты продал на маркетплейсах на 5 млн рублей, 2–2,5 млн из них ты спокойно отдал в виде комиссии, логистики и маркетинговых сборов. И тут возникает вполне логичный вопрос — а неужели на своём интернет-магазине нельзя привлечь клиентов хотя бы на эти же 2 млн? При этом данные пользователей остаются у тебя, их можно догревать, возвращать, продавать повторно. А это уже совсем другая экономика.

Так что рынок разработки интернет-магазинов умер? И да, и нет.

Этот вопрос поднимался ещё в тот момент, когда маркетплейсы начали активно захватывать рынок. Зачем свой магазин, если это затраты, куча проблем, ресурсы и неочевидная отдача? Ответ пришёл со временем. Свой интернет-магазин — это бренд и прямой доступ к клиенту. А значит, меньше зависимости от правил площадки и чуть более спокойный сон.

В итоге что получается. Рынок разработки интернет-магазинов не умрёт. Яндекс Кит просто займёт свою нишу, отжав у Тильды, WP и части типовых решений на Битриксе проекты небольших e-commerce. Если нужно что-то сложное, нетривиальное или B2B — вариантов по-прежнему немного, и кастом никуда не денется.

Со своей стороны мы планируем активно пробовать Яндекс Кит как ещё один инструмент быстрого запуска для небольших e-commerce-проектов, где городить что-то большое и сложное просто нецелесообразно.

Инструменты меняются. Смысл — нет.

Синхронное, асинхронное, конкурентное и параллельное выполнение — в чём разница простыми словами

Wed, 28 Jan 2026 12:26:45 +0300

В чём разница и почему это важно

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

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

Как ускорить выполнение

Если хочется, чтобы программа или сайт работали быстрее, вариантов на самом деле не так много.

Можно купить более мощное железо.
Можно делать меньше — сократить функциональность или упростить бизнес-логику.
Можно использовать более эффективные алгоритмы.
Можно выполнять задачи параллельно, задействуя несколько ядер процессора.
И можно сокращать время ожидания/отклика.

Последний пункт часто недооценивают, хотя именно он даёт наибольший эффект во многих системах.

Асинхронность и ожидание

Рассмотрим простой бытовой пример — стирку.

Сортировка вещей перед стиркой занимает 15 минут.
Сама стирка длится 40 минут.
Развесить и разложить чистое — ещё около 10 минут.

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

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

Именно так асинхронность сокращает общее время. Работа не становится быстрее сама по себе, но исчезают паузы, в которые ничего не происходит.

Если часть действий выполняется параллельно — например, вдвоем — реальное время сокращается ещё сильнее. При этом суммарное количество затраченных человеко-минут может даже увеличиться, но результат будет получен раньше.

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

Последовательное, конкурентное и параллельное выполнение

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

Представим задачу, сильно нагружающую процессор, например распаковку большого архива. Если бы система работала строго последовательно, на время распаковки она бы полностью «зависла»: нельзя было бы открыть браузер или даже передвинуть курсор.

На практике этого не происходит. Система периодически приостанавливает распаковку, чтобы дать процессорное время другим задачам — обработке ввода, интерфейсу, фоновым процессам. Затем возвращается к распаковке.

Задачи не выполняются одновременно, но они чередуются. Их выполнение перекрывается по времени, и система остаётся отзывчивой.

Такое выполнение обеспечивается конкурентными потоками. В повседневной речи термины «конкурентное» и «чередующееся» часто используют как синонимы.

Исходящие запросы: синхронно и асинхронно

Представим веб-краулер — программу, которая обходит сайт целиком. Она загружает страницу, извлекает контент и ссылки, затем повторяет этот процесс для каждой найденной ссылки.

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

Пока данные не получены, выполнение просто «стоит». Процессор при этом простаивает.

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

Входящие запросы: синхронно и асинхронно

Теперь посмотрим на ситуацию со стороны сервера.

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

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

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

Ключевое наблюдение в том, что сервер чаще всего не упирается в процессор. Он ждёт данные — от базы данных или других сервисов — и в это время ничего полезного не делает.

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

PIM-система для e-commerce: зачем нужна, когда внедрять и какие бывают решения

Tue, 20 Jan 2026 09:33:22 +0300

PIM: дорого, сложно. И почему без него иногда нельзя

Праздники закончились, пора вкатываться в рабочий ритм. На праздники был простой план: написать много контента. По факту контента написать не получилось, зато отлично прокачались новые когнитивные связи на падел-корте. Но сейчас не об этом.

Конец года оказался богатым на проекты, где так или иначе всплывала тема внедрения или серьёзной переработки системы хранения товарных данных. В простонародье это PIM. Product Information Management. Формально PIM почти всегда уже есть. Иногда эту роль выполняет CMS или 1С или какая то иная система. Где-то лежат описания, где-то характеристики, где-то изображения.

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

Когда всё начинает ломаться?

Проблемы редко появляются резко. Обычно они накапливаются. Контент начинают править в нескольких системах одновременно. Характеристики дублируются и расходятся. Картинки теряются, переименовываются вручную и живут без связи с товаром. SKU начинают вести себя как отдельные сущности, но управлять ими по-прежнему пытаются как попало.

В какой-то момент 1С перестаёт быть чисто учётной системой и превращается в неудобный редактор контента. CMS начинает хранить вообще всё подряд. Никто уже не может ответить, где находится «истина», а любое изменение превращается в риск что-то сломать.

И именно здесь появляется PIM. Не как ещё одна модная платформа, а как попытка навести порядок в данных.

Зачем вообще нужен?

Ключевая мысль, которую важно принять сразу. PIM не заменяет 1С и не конкурирует с CMS. У каждой системы своя роль.

1С остаётся учётной системой. Там создаются товары и SKU, живут GUID, цены и остатки. PIM становится единым источником товарного контента. Описания, характеристики, изображения, история изменений. Сайт и маркетплейсы в этой схеме выступают потребителями данных, а не местом их редактирования.

Как только это разделение ответственности зафиксировано, дальше архитектура начинает складываться сама собой.

Входные требования

За последние проекты у нас сформировалась довольно приземлённая памятка с требованиями которые мы выдвигаем при выборе. PIM должен разворачиваться на своём сервере. Желательно быть реализованным на понятном и не экзотическом стеке, чтобы при необходимости систему можно было развивать своими силами. Важно, чтобы модель данных нормально поддерживала работу с товарами и SKU как с разными сущностями. И конечно, чтобы интеграции с сайтом и маркетплейсами либо уже существовали, либо были реализуемы без сверхусилий.

Если на старте эти требования игнорировать, дальше почти всегда начинается дорогостоящий кастом.

Akeneo. Классический PIM без сюрпризов

Akeneo — это зрелая и понятная PIM-система. Очень хорошо подходит для каталогов с большим количеством атрибутов, сложной структурой и аккуратной моделью данных. У неё сильное сообщество, понятная логика работы и адекватная Community-версия.

Но важно понимать ограничения. Akeneo почти не решает задачи интеграции с маркетплейсами из коробки. Всё, что связано с Ozon, Wildberries и подобными площадками, придётся проектировать и реализовывать самостоятельно. DAM-возможности в бесплатной версии тоже достаточно базовые. В итоге это отличный фундамент, но с расчётом на последующую разработку.

Pimcore. Максимальная гибкость, максимальная ответственность

Pimcore — это уже не просто PIM, а целая платформа. Здесь можно собрать PIM, DAM, MDM и много чего ещё в одном контуре. Возможности почти безграничны, но за это приходится платить сложностью.

Для работы с маркетплейсами и выгрузками данных в Pimcore практически неизбежно понадобится Data Director. Это отдельный коммерческий модуль, который позволяет настраивать импорт, экспорт и трансформацию данных без глубокого кода. С ним жить сильно проще, но он не бесплатный и не решает всё автоматически.

Pimcore отлично подходит компаниям с сильной технической командой и пониманием, зачем им такая гибкость. Без этого внедрение легко превращается в бесконечный проект.

Ensi PIM. Прикладной подход для e-commerce

Ensi — это решение с явным фокусом на e-commerce и маркетплейсы. Модель данных проще, зато сразу ориентирована на практические сценарии. Интеграции с маркетплейсами доступны в коммерческой версии, и это сильно сокращает время выхода в прод.

Минус здесь тоже очевиден. Меньше универсальности и больше зависимости от вендора. Некоторые функции доступны только в PRO-версии, и при масштабировании важно заранее понимать, на каких условиях система будет развиваться дальше.

Как всегда важен контекст

Главная ошибка, которую мы видим снова и снова, это попытка сделать идеальный PIM сразу. На практике работает только итерационный подход. Сначала выносится контент из CMS. Потом аккуратно отсоединяется контентная часть от 1С. Затем расширяется модель атрибутов. И только после этого имеет смысл активно развивать интеграции с маркетплейсами.

PIM не нужен всем. Но если ассортимент растёт, маркетплейсы становятся важным каналом, а контент начинает жить своей жизнью, вопрос уже не в том, нужен ли PIM. Вопрос в том, сколько будет стоить отложенное решение.

2025 был непростой. Это вы ещё 2026 не видели

Wed, 24 Dec 2025 17:16:27 +0300

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

Но важно другое: плохо было не у всех. Я думаю, что как только выйдет отчётность, мы с удивлением увидим, что многие выросли, причём опережая рынок.

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

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

Что ещё показал этот год

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

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

Итак, 2026

Осуждать не надо. Заняться этим стоило ещё вчера. Или год назад.

Первое — медийность.
Мы решили, что топам направлений нужно в это осознанно вкладываться. Начали с собственных каналов и общения внутри профессиональной тусовки. Зачем — станет понятно чуть дальше.

Второе — выставки и мероприятия.
В этом году я много общался с коллегами, которые активно в них участвуют. По их рассказам — это работает. Даже если делить результат на два, всё равно выглядит разумно.
Участие в выставках с услугами мне всегда казалось сомнительным, но сейчас у нас появился продукт, который можно использовать как флаг и ездить с ним по рынку. Продукт становится формой входа в клиента и поводом для разговора. А так как он из e-commerce, то и контакты там ожидаются более качественные. Так что увидимся на выставках — список мероприятий сейчас как раз формируем.

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

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

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

Про контент от лица агентства

Контент агентства мы решили не сворачивать, но снизить на него фокус. Кейсы — король, они остаются.
А вот экспертные статьи — скорее всё. Каналов дистрибуции почти не осталось: vc кончился, Habr можно, но «такое себе». Поэтому блог компании решили сфокусировать на SEO и GEO-текстах.

Посмотрим, как это всё сработает и что из этого получится.
План есть. Иллюзий нет. 2026 обещает быть интересным.

Что такое LLMS.TXT: зачем нужен файл llms.txt и почему он не работает на практике

Tue, 16 Dec 2025 17:12:39 +0300

LLM-боты пришли, а управление пока не завезли

Ранее я уже писал, что трафик от LLM растёт пока в основном в англоязычном сегменте, но и в зоне .ru они давно и активно индексируют сайты. И, что заметно, в некоторых нишах от туда есть исходящий трафик.

Но есть и обратная сторона.
На ряде наших проектов мы столкнулись с крайне агрессивным поведением бота от Apple и других. По всем признакам это был их LLM или что-то очень близкое. Он настолько часто и плотно дёргал страницы, что нагрузка на сервер стала напоминать DDoS. В какой-то момент пришлось резать его по IP, иначе прод начинал просто ложиться.

Банить IP разных ботов руками плохая идея, хоть и реализуемая через WAG. На этом фоне идея «как-то управлять ИИ-ботами» выглядит абсолютно логичной. Так и наткнулись на llms.txt файл, который подают как аналог robots.txt, но не для поисковиков, а для ботов, обучающих нейросети. Мол, можно аккуратно подсказать, какие страницы важные и что именно стоит читать.
Звучит красиво. На практике не работает.

Если упростить, llms.txt это markdown-файл со списком ссылок и краткими описаниями контента. По ощущениям, это что-то вроде sitemap.xml «для ИИ», только с претензией на новый стандарт. Проблема в том, что:
— у нас уже есть sitemap.xml;
— есть robots.txt;
— и главное нейросети и так умеют читать HTML.

Показателен комментарий Джона Мюллера из Google. По смыслу он сравнил llms.txt с meta-тегом keywords: формально вы можете что-то там написать, но реальные системы этим просто не пользуются. Если нужно понять, о чём сайт, проще и надёжнее прочитать сам сайт, а не верить декларациям владельца.

Это подтверждается и практикой. В одном из обсуждений на Reddit ребята анализировали серверные логи порядка тысячи доменов и выяснили, что llms.txt почти никто не запрашивает. Его могут забирать какие-то нишевые аналитические боты, но крупные AI-платформы нет.
Ни OpenAI, ни Google, ни Anthropic, ни Яндекс публично не подтвердили поддержку этого стандарта.

Откуда вообще взялась эта идея?
Изначально из желания дать нейросетям «чистый» контент без HTML-мусора. Но проблема в том, что LLM уже давно этот мусор переваривают без особых сложностей. Контекстные окна растут, понимание структуры документов улучшается. Через год-два нейросети будут читать сайты почти как люди и необходимость в отдельном markdown-файле исчезнет сама собой.

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

Что имеем на практике

Итого: на текущий момент более оптимального решения, чем WAF, мы не нашли. В существующих реализациях это почти единственный рабочий способ уберечь прод-сервер от наплыва AI-ботов: контроль частоты запросов, фильтрация паттернов и защита на уровне инфраструктуры, а не вера в декларативные файлы.

Как продавать услуги B2B: почему РП продаёт лучше менеджера по продажам

Wed, 10 Dec 2025 11:36:57 +0300

Продай мне эту ручку

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

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

Эта мысль не новая — когда-то давно её вслух озвучивал Михаил Токовинин. Продажи — последнее, что получается нормально делегировать. Мы за десять лет перепробовали почти всё: звонки в полухолодную, рассылки, аутрич, контекст, таргет. Все инструменты рабочие, но у нас — по ряду причин — давали довольно скромный результат.

Со временем стало очевидно: продаёт только экспертиза. В кастоме человек не покупает “услугу” — он покупает уверенность, что его задачу реально решат. И эту уверенность может дать только тот, кто сам делал подобные проекты.

Есть ещё одно распространённое искажение: будто экспертизу можно «донести» кейсами и портфолио. И вроде бы да, кейсы помогают. Но клиент всегда задаёт один простой вопрос: “А кто всё это делал?” И вот тут начинается самое интересное — в компаниях всё меняется, команды обновляются, а вероятность того, что те самые герои кейса давно ушли, очень велика. Поэтому экспертиза, переданная через человека, работает в разы сильнее, чем любой PDF с красивыми скриншотами.

Поэтому сегодня наш процесс устроен иначе. Первичную коммуникацию ведёт аккаунт: собирает бриф, боли, контекст. А дальше мы сразу зовём на созвон менеджера проектов. Желательно того, кто уже сталкивался с похожими кейсами. На встрече мы уточняем вопросы, сверяем ожидания, раскладываем риски. Клиент слышит эксперта, а не человека “между ним и экспертом”. Производство сразу понимает, на что идём. РП может подключить коллег, если нужно. Всё честно и прозрачно.

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

Вывод простой: сложные сервисы и кастом продаются только через экспертизу. И показать её можно только через людей, которые эту работу делают. Поэтому у нас лучшая связка — аккаунт + менеджер проектов. Мягко, честно, без иллюзий про волшебных продажников, которые “продадут даже ручку”. В B2B всё куда проще: продаёт тот, кто понимает, что делает.

Факап с наймом родственника: реальная история и выводы для руководителей

Fri, 05 Dec 2025 08:58:03 +0300

Факап №N. Повесть о семейном подряде

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

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

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

Провели условный “тех-собес”, пожали руки — и взяли нового человека.

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

Сработал я не идеально: резковато, быстрее, чем стоило бы, без предупредительного в воздух. Ошибку свою признаю. Но стажёрам заранее говорилось, что такая ситуация возможна. Решение принято, действия сделаны.

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

Меня эта история тогда задела. Всё ведь было проговорено заранее, все стороны согласились. Но стоило этим правилам вступить в силу, как играть по ним никто больше не захотел.
Ну что ж, бывает. Это тоже часть опыта.

Что я понял после

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

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

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

UX/UI и AB-тестирование: почему редизайн с гарантией роста конверсии не работает

Mon, 01 Dec 2025 17:52:09 +0300

Не так давно общались с одним e-com. У ребят всё в целом нормально, но пришли они с задачей поднять конверсию с условных пяти до семи процентов за счёт редизайна.

Посмотрели метрики, текущий UX и все хотелки и быстро поняли: подписываться под такие вещи — это форма самообмана. Никто не может честно гарантировать, что набор изменений в интерфейсе точно даст рост в два процента. Можно верить, надеяться, но это не про управление продуктом.

Мы предложили идти через мелкие изменения и замеры конкретных метрик. Зацепили гипотезами, показали, что так безопаснее и прозрачнее. Но понимания не нашли. Клиент хотел увидеть в ТЗ формулировку «вырастить конверсию в N раз» и переложить риски на исполнителя. Как цель это звучит красиво, но чтобы под такое подписаться, нужно быть либо слишком самоуверенным, либо рассчитывать на удачу. Мы туда не пошли.

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

С технической стороны тоже всё не так романтично. В Битриксе есть встроенные AB-тесты, которые автоматически делят трафик. Работает, но выглядит архаично. Есть Яндекс Метрика и её же Varioqub в базовом виде. Можно развернуть Varioqub on-prem и крутить тесты в больших объёмах. Все эти решения рабочие, но вопрос никогда не в инструменте. Вопрос в том, что мы пытаемся померить и зачем.

И здесь встаёт немой вопрос. Готовы ли вы подписаться под разработку UX/UI с гарантированным результатом? Для меня это почти как обещание построить дом, который понравится всем соседям, будет вечным, красивым и вообще идеальным при любых вкусах. Так не работает.

Ну и последняя мысль, которая обязательно всплыла в процессе. Такие работы точно нельзя продавать по модели time & material. Если вам перекладывают риск на достижение результата, то TM размывается, превращается в лотерею и работает против исполнителя. Если уж подписываться под такую историю, выигрыш должен быть действительно значительным, иначе проще сразу сказать «нет».

Покупки в ChatGPT: почему новый «убийца e-commerce» не взлетит

Tue, 25 Nov 2025 17:29:18 +0300

Очередной убийца традиционного e-commerce

Сегодня прочитал новость, что в ChatGPT собираются встраивать прямые покупки (сама новость была 29 сентября). Примерно так: пишешь ему «найди красную рубашку», и если есть подходящий магазин с товарами тебя тут же ведут к оформлению заказа и списанию денег.

Первая мысль была проста: выглядит сомнительно. Магазин в чате?

Есть стойкое ощущение, что IT-рынок каждый год пытается продать идею «покупки там, где покупать неудобно». Telegram Apps еще, уже пробовали. Яндекс экспериментировал с покупками прямо в поиске тоже не взлетело. Наверное было еще очень больше количество эксперементов и на других платформах.

Теперь очередь ChatGPT? Но чат это не каталог. Нет плитка. Нет списков, фильтров, избранного и все что удобно. Человечество двадцать лет шлифовало UX интернет-магазинов, чтобы стало как-то удобно. А тут попытка заменить интерфейс диалогом.

В России в ближайшее время мы все равно это не получим. OpenAI работает через Stripe, Shopify, Etsy и прочий западный стек.

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

Технически реализовать покупку вообще не проблема. Гораздо сложнее другое: как туда загрузить товары так, чтобы алгоритм показал именно твою красную рубашку?

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

По сути OpenAI делает новый поисковик с кнопкой «купить», что логично при наличии аудитории. Но уже была статистка: даже когда ChatGPT даёт ссылку, почти никто не переходит наружу. Даже если функция покупки была доступна сейчас в РФ, стоит крепко подумать стоит ли отдавать трафик ради заказов из чата.

OpenAI логично пытается удержать человека внутри своей экосистемы и в этом смысле покупки прямо в чате идеально вписываются в стратегию.

Новый убийца традиционного e-commerce? Скорее ещё один эксперимент, который выглядит красиво в презентации, но в реальном поведении пользователей мало что меняет. По крайней мере, пока.

Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него

Wed, 19 Nov 2025 14:39:32 +0300

SaaS был ошибкой? Возможно. Часть 4

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

Месяц кастдевов

За это время провёл около двадцати интервью с бизнесом и людьми, которые так или иначе связаны с маркетплейсами: от продуктовых специалистов до руководителей направлений МП. Хотел понять простую вещь — кто и как управляет ценами, где автоматизация действительно работает, а где все по-старинке.

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

А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.

Сменить позиционирование

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

Так получается точнее и честнее отражать то, что мы реально делаем — и то, чего нет у конкурентов.

Что сделали по разработке

Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.

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

Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.

Интересные находоки

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

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

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

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

Что дальше

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

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

В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?

API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.

Далее по плану.

Запускаем SaaS.
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.

Будущее IT в 2026: что ждёт рынок труда и как на него влияет AI

Fri, 14 Nov 2025 10:59:24 +0300

Про маятник рынка IT и AI

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

Важно понимать — это временная история. Рынок либо сбалансируется, либо маятник снова уйдёт в сторону кандидата. Горизонт в 1–2 года пока туманен, но подобные перекосы никогда не бывают вечными.

При этом джунам и мидлам сейчас действительно тяжело. ИИ поджимает, конкуренция выросла, а до HR порой просто не пробиться. Да ещё и сами компании принимают решения о найме куда медленнее. Сильные ребята этого почти не замечают, наверное — дефицит на суперменов никуда не делся, но общий фон стал ощутимо менее комфортным.

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

Параллельно развивается и противоположный тренд. В Reddit, Medium и нескольких других источниках всё чаще всплывают истории о том, что масштабные ставки на AI-автоматизацию не оправдали ожиданий. Там, где компании сокращали людей под лозунгом «теперь всё сделает нейросеть», результаты оказались слабее, чем ожидали. Обычный человеческий интеллект и прямые руки во многих процессах справлялись лучше. И теперь часть тех специалистов, кого спешно оптимизировали, приходится возвращать обратно.

Понятно, что огромную долю позиций уже никто не вернёт — если автоматизация работает, она и будет работать. Но сам факт интересный: не всё, что громко называли “вот-вот заменит людей”, реально заменило.

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

Выводов как таковых не будет. Если говорить про отдельно взятого специалиста, то, пожалуй, единственная спокойная бухта — становиться сильнее в своей отрасли. Прокачиваться до уровня Senior и выше, учиться решать бизнес-задачи, а не просто писать код. В мире, где AI проникает во все сферы, это, кажется, единственная более-менее стабильная стратегия.

Бутик или завод: как масштабировать IT-агентство и почему бутиковая модель перестаёт работать

Tue, 11 Nov 2025 09:52:27 +0300

Бутик или завод

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

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

Масштаб как инструмент

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

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

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

Можно, конечно, сказать: «Мы будем платить человеку в простое, а потом отбивать, когда он в деле». Но, если честно, в реалиях 2025 года это почти утопия.

Аутсорс ≠ команда

Да, можно выносить часть функций на аутсорс или парт-тайм, но часто это не то. Это уже не core-команда, не часть ДНК компании. Это как двигатель и коробку передач держать “на подряде” — вроде работает, но ощущение надёжности и контроля теряется.

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

Бутик — это красиво. Завод — это надёжно. А в идеале — быть умным заводом, который делает бутиковые вещи, но системно.

Про декомпозицию

Thu, 06 Nov 2025 09:15:11 +0300

Если упростить до сути, управление проектами и людьми — это искусство декомпозиции.

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

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

Когда слышу “готово на 80%”, внутри уже загорается лампочка. Эти 80% — просто способ не сказать “не сделал”. Это не цифра, это способ не брать ответственность. Поэтому у любого адекватного менеджера рано или поздно появляется привычка резать задачи до тех пор, пока не останется только два состояния: сделано / не сделано.

Иногда доходишь до смешного. Даёшь человеку простое поручение — например, согласовать макет с клиентом. Через неделю он рассказывает, что дизайнер ещё думает, клиент не ответил, а в чате не было тегов. И вроде бы “все работали”, но конкретного результата нет. В этот момент становится ясно: проблема не в макете, а в том, что задачу нужно было разбить до уровня “отправить макет”, “дождаться комментария”, “внести правку”.

Менеджмент — это не про контроль и отчёты, а про честность. Про умение признать реальность без процентов и “почти готово”. Если задача не декомпозирована — она будет бесконечной. Если декомпозирована — у неё есть шанс быть завершённой.

Когда команда начинает мыслить в этих категориях, исчезают оправдания и споры “что имелось в виду”. Каждый видит границу: вот задача, вот результат. Всё остальное — разговоры для галочки.

Корпоративные IT-термины и англицизмы: язык заказчика в B2B

Sat, 01 Nov 2025 16:32:03 +0300

Ихние диалекты

Как у вас с английским? Уже выучили или какой-то другой начали учить?

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

Диалекты профессий

Многие профессиональные сферы — стройка, финтех, медицина, и IT не исключение — со временем обрастают сленгом, англицизмами и прочими артефактами.

Вот только верхушка айсберга: CAPEX, OPEX, MVP, MLP, скоринг, комплаенс, чекаут, PIN, юнит-тесты, легаси, BRD, PROD, витрина, домен, CI/CD, релиз.

Половину из этого можно спутать с названиями таблеток.

Но тут дело не в понтах. Просто внутри каждой профессии появляется свой язык — короткий, удобный, понятный тем, кто “в теме”. И если ты в этой среде, ты начинаешь говорить так же. Не потому что хочешь казаться умнее, а потому что это быстрее и точнее.

Почему без «своего» языка не договориться

B2B-бизнес — это про людей. Чтобы договориться, нужно уметь общаться. А чтобы общение было продуктивным — нужно говорить на одном языке. Мысль не новая, даже старая: «Говорите с заказчиком на его языке». Но по факту это единственный способ, чтобы вас поняли.

Если мы говорим про микробизнес — там всё просто и по делу: “надо, чтобы работало”. В малом и среднем бизнесе — уже веселее, но всё ещё понятно. А вот у крупных компаний начинается корпоративный диалект.

У CTO — свой. У продукта и проджекта — свой. У владельца домена — свой. У e-com-директора — тоже свой. А заказчик, как правило, не один. И нередко они между собой говорят на разных языках — а роль переводчика достается тебе.

И это не плохо. Кто-то скажет, что корпоративный язык вырождает речь. А по мне — наоборот: он заставляет язык жить. Он отражает реальность, как она есть: чем сложнее процессы, тем богаче язык.

Лучше переспросить, чем не понять

Если чувствуете, что не дотягиваете по “языку” — лучше подготовьтесь. А если не получилось — переспросите, если не понял. Лучше показаться глухим, чем потом неправильно всё сделать.

Со временем вы начинаете ловить ритм, подмечать термины и внутренние шутки. И вот уже сами спокойно говорите: “закроем спринт, выкатим на прод, метрики глянем на ретро”.

Так что изучайте корпоративные диалекты — особенно если работаете в IT или B2B. Вероятно, вам понадобятся разные диалекты — не только IT, но и отраслевые: e-commerce, финтех, стройка и так далее.

Говорите на «ихнем» — и жизнь станет сильно проще.
А какие диалекты знаете вы?

Сделай, чтобы было хорошо — почему плохие задачи убивают результат

Wed, 29 Oct 2025 10:38:01 +0300

Давече общался с бывшим коллегой-программистом. Сейчас он работает в продукте — строит там всякое сложное.

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

Разговор зашёл о постановке задач. У них всё по учебнику — проджект, продукт, тимлид. Но прилетают задачи с описанием уровня “сделай что-то там, чтобы было хорошо”. И минимум конкретики.

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

Мы с ним посидели, подумали, почему так происходит. Первый вариант — это форма обучения. Типа “пойди разберись, поизучай тему, потом расскажешь”. В целом логично, но если это обучение, то, наверное, стоит так и сказать.

Второй вариант — перекладывание ответственности. Лид от бизнеса получил задачу в стиле “надо сделать хорошо”, передал дальше — “ну ты там сам разберись”. Если всё сработает — класс, время сэкономили, нервы целы. Если нет — всегда найдётся виноватый: программист не уточнил, тимлид недоспросил, продакт не понял бизнес. И цепочка пошла выше.

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

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

И вот тут приходится принимать неприятный факт — иногда нужно брать ответственность за то, на что ты не можешь сильно повлиять. Да, риск есть, и да, бывает, что не оправдан. Но если уж столкнулся с такой задачей — лучше потратить время, разобраться, задать вопросы (пусть даже через GPT), чем потом переделывать.

В конце концов, качество постановки задачи — это форма уважения. И работает это в обе стороны — и когда ты ставишь, и когда тебе ставят. Потому что, как ни крути, все мы работаем с людьми. И хочется верить, что инвестиции, которые ты вкладываешь в проработку задачи, однажды окупятся.

Цепи Маркова в e-commerce: как предсказывать поведение клиентов и находить сбои в системах

Fri, 24 Oct 2025 16:12:33 +0300

Недавно на YouTube наткнулся на видео про цепи Маркова. Объяснение было бодрым, простым и в отличие от универа — даже понятным. В институте эту тему нам давали сухо: формулы, матрицы переходов, вероятности. Тогда я не мог до конца понять, зачем это всё.

Так что же это за зверь такой — цепи Маркова?

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

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

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

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

Рекомендации и ценообразование
Все эти блоки “с этим покупают” и “вам может понравиться” — чистая цепь Маркова.
Система не “угадывает”, она просто знает, что после чайника чаще всего открывают фильтры, потом кружки, а потом уже идут в корзину. Алгоритм подсовывает следующее звено, чтобы не дать цепи оборваться.

Поведение покупателей на скидках — тоже цепочка.
“Цена упала → CTR вырос → корзины заполнились → возврат вырос → скидку убрали → продажи просели”.
А теперь представьте, что система видит эту последовательность заранее и подстраивает стратегию — вот уже и “умное ценообразование” готово.

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

Например, алгоритм PageRank от Google можно рассматривать как модель цепи Маркова: каждую страницу можно считать состоянием, а переходы между страницами — вероятностями переходов в цепи.

Такие модели хорошо ложатся на предиктивную аналитику: прогнозирование нагрузки, отказов, пиков активности. На этом принципе построены многие инструменты мониторинга — они не просто ловят инциденты, а предсказывают, где “цепь может порваться”.

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

В итоге, цепи Маркова — это не про математику ради математики.
Это про понимание вероятностей, которые движут вашим процессами. Про то, как данные превращаются в действия. И про то, что даже “случайность” в поведении клиентов на самом деле довольно предсказуема — если у вас достаточно истории кликов, заказов и цен.

Как я превратил крутого разработчика в руководителя и потерял обоих — история управленческого факапа

Mon, 20 Oct 2025 15:35:35 +0300

2016–2018: когда нас было девять

Те годы помню до деталей: нас девять человек, горячие, голодные, без лишней бюрократии. И вот к нам приходит парень — назовём его Антон. В резюме — «веб-разработчик» без узкой специализации. Сказал честно: «Умею немного, но быстро учусь». Конкурентов в офлайне тогда не было вовсе. Взяли.

Антон рос как на дрожжах. Подхватывал горящие задачи, часто выручал. Мы подтягивали вознаграждение, прокачивали стек, перестраивали процессы. Постепенно стало ясно: доступные у нас задачи и вилка дохода перестали его держать. Он перерос рамки роли и по ожиданиям, и по уровню.

Поворот не туда: «давай в тимлиды»

Мы начали думать, чем его загрузить, чтобы и человеку интересно, и компании польза. Тогда ещё не было чётких контуров по ролям, «лидство» существовало больше по факту, чем по документам. Мы нарисовали мотивацию, собрали пул задач. Получилось скорее про организацию команды, чем про архитектуру и сложный код — то есть ближе к team lead, а не к tech lead.

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

Было больно. В Антоне концентрировалось много технологий и контекстов. По деньгам перебить оффер не могли: почти х3 к нашему потолку. Разошлись цивилизованно, договорились о передаче дел. Связь не потеряли — до сих пор общаемся, обмениваемся опытом.

Ирония судьбы

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

Что было не так на нашей стороне

Мы не объяснили человеку логику роли и не проверили, зачем она ему. Слушали рынок, KPI и наши потребности, но недостаточно слушали Антона. Ему нужен был фокус на сложном коде, архитектуре, R&D. Мы предложили организационную повестку и «немного кода». В итоге потеряли звёздочку — и это целиком наш косяк.

Справедливости ради, команда от той истории стала сильнее. Мы формализовали роли, разделили Team Lead и Tech Lead, перестроили грейды и мотивацию. А Антон стал ещё круче как специалист и теперь осознанно совмещает техническую глубину с лидерством.

Что бы я сделал сейчас

Во-первых, честный карьеркарт: две развилки — Tech Lead (глубина, архитектура, сложные задачи, минимум митингов) и Team Lead (люди, процессы, цели, много коммуникаций). Показал бы риски и рутину каждой траектории, а не только плюсы.

Во-вторых, прототип роли на 1–2 месяца. Не «назначили и поплыли», а проверили интерес и пригодность в коротком цикле с обратной связью.

В-третьих, личные мотивы важнее оргструктуры. Если человек горит кодом — дай ему «космос»: тяжёлые проекты, ответственность за архитектуру, время на исследования. Не пытайся «починить» мотивацию окладом и приставкой «лид» в должности.

Итог

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

Эта история чем-то рифмуется с другой — про Фёдора. Если не читали, загляните: https://t.me/alexeyitru/153