Недавно сходил в Softorium — к нашим партнёрам и друзьям, поговорил с Евгением Сомовым — он отвечает за продажи в компании.

И это была очень полезная встреча.

Обсуждали не какие-то абстрактные “продажи ради продаж”, а вполне практичные вещи:

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

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

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

Евгений, спасибо за разговор и за конкретику. Было очень полезно.

И отдельно хочу порекомендовать подписаться на его канал)

С Днём Победы!
С 9 Мая!

Никто не забыт, ничто не забыто.

Знаете, для меня этот праздник святой, я живу благодаря подвигу советских людей, и я это понимаю и мысленно благодарю их каждый день!

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

Победа дала нам жизнь. Возможность быть, работать, любить свободно и на своей земле!

Спасибо, родные!

P.S. И под звуки «Журавлей» Марка Бернеса ещё раз почтим память великих предков → https://music.yandex.ru/album/9547506/track/61281160

Слил одного лида — взамен получил полезное наблюдение

К нам приходила клиника на SEO-сопровождение. Ответили, обсудили, посчитали. А потом клиент тихо ушёл — видимо, выбрали кого-то другого.

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

Цифры:
- Средний медицинский сайт конвертит трафик в заявку на 2–5% (Tebra, First Page Sage).
- Сокращение лид-формы с 7 полей до 3 поднимает конверсию формы с ~11% до ~23% - в 2 раза (исследование форм 2026, digitalapplied.com, агрегат 100+ источников).

То есть на одном и том же трафике из SEO и контекста потенциал роста заявок чаще лежит внутри сайта, а не в выдаче.

Если Roistat показывает "дорогой лид по органике" - проблема обычно не в источнике, а в посадочной - длина формы, видимость врача рядом с кнопкой, скорость загрузки на мобильном.

Парадокс: клиент пришёл за SEO, но даже идеальная SEO-стратегия упрётся в форму на 8 полей и фото из стока вместо живого врача.

Иногда SEO - это не первое, что нужно лечить.

Как же прекрасно работать с CRM!
Ты все выгружаешь из головы, ведешь клиента по воронке.
Я еще активно использую клод со скиллом пресейл-консультанта.
Очень сильно мне помогает в работе и иногда подсказывает мне такие вещи, что я сам никогда бы не увидел, наверное.

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

Проектные деньги vs MRR: почему агентство задыхается без поддержки

В разработке есть два очень разных типа денег.

Первые — проектные.

Клиент пришёл, заказал сайт, приложение, личный кабинет, интеграцию, MVP, AR, автоматизацию. Да что угодно.
Команда оценила, продала, сделала, сдала.

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

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

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

Потому что проектные деньги — это не стабильность.
Это волны.

Сегодня густо.
Через месяц пусто.
Потом снова густо (или пусто).
Потом снова кассовый разрыв (или что-нибудь еще).

Вторая модель — MRR, monthly recurring revenue, регулярная месячная выручка.

В нашем случае это поддержка, сопровождение, техническая абонентка.

Клиент платит не за «одну задачу», а за постоянное наличие технической команды рядом:

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

Для агентства это тоже принципиально другая экономика.

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

Проекты дают рост.
Абонентка даёт кислород.

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

Когда её нет — агентство часто живёт от сделки до сделки.
И даже при хороших проектах может задыхаться. А если проектов нет — умирать.

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

Это фундаментальная часть бизнес-модели. Особенно в надвигающемся ИИ.

Особенно если ты хочешь строить не просто набор случайных проектов, а устойчивую компанию.

Микроменеджмент — где грань между заботой и контролем

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

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

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

И вот тут начинается конфликт.

Пример первый.

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

Это не микроменеджмент.
Это нормальное сопровождение.

Пример второй.

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

Вот это уже контроль ради контроля.

Пример третий.

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

Тут дополнительный контроль может быть не прихотью руководителя, а последствием потери доверия.

Пример четвёртый.

Руководитель сам не сформулировал задачу, не дал критерии результата, не объяснил приоритеты, а потом каждые два часа спрашивает: «Ну что там?»

Это плохое управление, замаскированное под заботу.

Для меня граница примерно такая:
1) Забота — это когда человеку помогают понять цель, риски, сроки и критерии результата.
2) Контроль — это когда человеку не оставляют пространства для самостоятельной работы.

Хороший менеджмент — не в том, чтобы вообще не контролировать.
И не в том, чтобы контролировать каждый шаг.

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

Тогда контроль перестаёт быть нервным дёрганьем и становится нормальной системой работы.

Обратите внимание на конец списка

Не реклама, рекомендация! Очень молодой основатель, надо поддержать!

ИИ убьёт заказную разработку?

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

И невольно возникает тревожный вопрос, а что будет с заказной разработкой?

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

Потому что код действительно дешевеет.

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

Но бизнесу на самом деле нужен не просто код.

Бизнесу нужно, чтобы:

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

ИИ может сгенерировать кусок кода.
Но он не несёт ответственность перед клиентом.

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

Поэтому, мне кажется, ценность будет смещаться.

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

Отдельная большая ниша, на мой взгляд, — это "спасение" проектов, собранных через ИИ.

Сейчас многие предприниматели будут делать MVP через нейросети и no-code-инструменты. У них будет "почти готовый продукт", который вроде работает, но внутри:

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

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

Поэтому я бы сказал так:

ИИ не убивает IT-бизнес.
ИИ убивает посредственную разработку, хаос и продажу "просто часов".

А востребованными будут те, кто умеет брать ответственность за digital-инфраструктуру бизнеса.

И, честно говоря, это даже немного отрезвляет.
Потому что вопрос уже не в том, "заменит ли ИИ программистов".

Вопрос в другом:
сможем ли мы перестать продавать просто разработку — и начать продавать ответственность, стабильность и результат для бизнеса?

Вот туда и надо двигаться.

MCP в Битриксе: почему это важнее, чем кажется

На собеседовании с разработчиком всплыла фраза, мимо которой я бы три года назад прошёл, а сейчас зацепился: «к Битриксу же MCP уже подключается». Сказано было между делом.

И вот именно эта будничность — самое интересное.

Что такое MCP, если коротко

MCP (Model Context Protocol) — это стандарт от Anthropic (того самого, что делает Claude), описывающий, как ИИ-ассистент получает доступ не только к своей «памяти», а к живому контексту проекта: репозиторию, документации, базе данных, дизайну в Figma, задачам в Jira, браузеру, CRM. Грубо говоря, раньше ИИ писал код «по памяти и догадкам», а с MCP — по реальной документации и API конкретного проекта. Меньше галлюцинаций, больше попаданий в существующий стек.

Почему MCP под Битрикс — это не «вау», а сигнал

В обсуждениях ИИ-разработки обычно мелькает модное: React, Python, AI-first стартапы, новые фреймворки. Битрикс там проходит мимо — слишком корпоративная, слишком «не хипстерская» платформа.

И именно поэтому факт, что для 1С-Битрикс уже работают MCP-серверы (как минимум delight.mcp в официальном маркетплейсе и независимый camouf.ru, плюс несколько решений под Bitrix24 REST на GitHub), для меня важнее любых новостей про очередной AI-IDE.

Битрикс — это огромный рынок поддержки и доработки в РФ и СНГ. Тысячи корпоративных сайтов, личных кабинетов, интернет-магазинов, легаси-кода и интеграций, на которых каждый день работают живые компании. Если ИИ-инструментарий доходит сюда — значит, он действительно стал инфраструктурой.

Как мы в JDPlex с этим работаем

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

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

Если у вас есть сайт на Битрикс, особенно живущий 3+ года в продакшене, и его периодически надо «допиливать» — вот конкретные эффекты:

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

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

— Аудит и оценка работ перестают быть «прикинули по опыту». Они становятся проверяемыми: вот замеры, вот выгрузка, вот лог проверки.

Но у этого есть обратная сторона.

Почему MCP не отменяет разработчика, а поднимает планку

Самая опасная иллюзия 2026 года звучит так: «теперь любой джун с Cursor + MCP может поддерживать наш Битрикс, зачем платить подрядчику». Я слышу её всё чаще — и каждый раз вижу, чем это заканчивается.

С MCP мало просто «попросить нейросеть». Появляются задачи, которых раньше не было:

— решить, какие MCP подключать к проекту и какому ИИ давать доступ;
— настроить права: что ИИ читает, а к чему не приближается;
— научиться валидировать ответы;
— выстроить ревью, тесты, откат изменений;
— не создать дыру в безопасности.

Каждый пункт — отдельная инженерная задача.

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

Вывод

Для меня появление MCP под Битрикс — не новость про инструмент. Это про то, что в сегмент корпоративной разработки приходит новый производственный контур: репозиторий + документация + задачи + дизайн + браузер + CMS, соединённые в один AI-ассистированный конвейер.

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

Первый найм в сейлс — это не тот, кто приносит деньги.

Я всегда нанимаю customer success. Человека который думает не о выручке, а о том что клиент чувствует прямо сейчас. Нашли ли они свой use case, видят ли результат до и после.

Это единственное что имеет значение после подписания.

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

Было у вас такое — сделал продажу, отметил, выдохнул, а потом контракт тихо умер. Почему? Потому что в какой-то момент ты перестал продавать.

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

Я вижу эту ошибку почти у всех фаундеров с которыми работаю. Закрыли сделку и сразу переключились на следующую, а внутри клиента никто не ведёт работу.

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

Согласны?

Ещё одна киллер-фича ChatGPT — кидаете скрин своего дизайна и просите дать фидбек. Бот по полочкам разложит вашу работу, подсветит сильные стороны и предложит, что можно улучшить.

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

ChatGPT снова показал бомбу.

@bugnotfeature

Переписывать или чинить: 3 вопроса, которые закрывают спор

Каждый раз, когда я открываю чужой (или свой годовалой давности) проект, рука тянется сказать: «да тут проще переписать с нуля».

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

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

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

3. Готов ли бизнес 2–6 месяцев платить за то, что снаружи ничего не меняется?
Главный вопрос, и его всегда задают последним. Перепись — это пауза в новых фичах. Конкуренты не паузят. Клиенты не паузят. Если у бизнеса нет такого окна — придётся чинить, как бы ни хотелось переписать.

Алгоритм:
Болит конкретно + меняется ядро + бизнес даёт окно, то переписывать.
В остальных случаях — чинить и рефакторить.

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

Всех предпринимателей с праздником!
Сегодня день предпринимателя!
Классных бизнес-моделей, сотрудников и клиентов вам, ну и, конечно, чистой прибыли побольше! Ура!
https://www.rbc.ru/life/news/6a05c0709a79474ef216dcd8

Минутка бизнес-офигевания. 🤯

Как думаете, какая чистая прибыль у старого доброго «Доширака»? Казалось бы, просто быстрая лапша за копейки...

Пишите свои варианты в комментариях, только чур честно и без гугла!

P.S. Я когда реальные цифры увидел, у меня челюсть просто улетела куда-то в район коленей. Жду ваши ставки 👇