В проектах на 1C-Bitrix я всё чаще вижу одну и ту же картину: продукт технически собран, SLA прописан, но клиент всё равно недоволен. Причина обычно не в коде и не в железе, а в том, как организован сервис.

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

Типовой кейс из проекта: интеграция CRM и каталога работает, но при аварии у клиента нет понятного маршрута — кто подтверждает инцидент, кто оценивает влияние на продажи, кто принимает решение о временном обходе. В итоге техническая проблема превращается в управленческий хаос. Хороший сервис-менеджмент этот хаос режет на процессы.

Я для себя давно сформулировал так: поддержка чинит, сервис-менеджмент удерживает доверие. А в enterprise-проектах это уже не «дополнительная роль», а часть архитектуры отношений с клиентом. ⚙️

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

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

Типовой кейс из проекта: клиент покупает «готовое решение», а потом удивляется, что оно плохо стыкуется с 1C, ломает кеш и требует отдельной логики для менеджеров. Формально работает. Архитектурно — нет.

Я для себя давно вывел правило: если система пришла извне, её надо оценивать не по красивому демо, а по тому, как она встраивается в существующий стек. Иначе получаем не продукт, а набор компромиссов ⚙️

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

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

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

Если перевести это на язык проектов, схема выглядит так:
CEO/CFO → сокращение затрат
CTO → перестройка процессов
команда → меньше ручной работы, выше планка по навыкам

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

Вывод сухой: сокращают не ИИ, а слабую организацию. ИИ просто делает это быстрее.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

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

Из практики я вижу простую схему:

- robots.txt — для классических краулеров и базового запрета на обход
- llms.txt — попытка явно показать, что можно читать, а что лучше не трогать
- server-side контроль — когда важны не декларации, а реальные правила доступа, лимиты и логика по User-Agent

Проблема в том, что у LLM-агента нет одной универсальной «этичной» модели поведения. Один сервис уважает ограничения, другой частично игнорирует, третий вообще приходит через промежуточные запросы. Поэтому на уровне проекта я бы не рассчитывал на один файл в корне сайта как на защиту.

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