Redmine я до сих пор вижу в живых проектах, и это не случайность.

Типовой кейс из практики: 10–20 человек, свой сервер, понятный регламент, задачи не прыгают между отделами, интеграции минимальные. В такой схеме Redmine рационален: бесплатно, предсказуемо, без сюрпризов после обновления. Его обычно не «любят» — его просто используют как рабочий инструмент.

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

Я бы смотрел на миграцию, если:
— процесс вырос и стал кросс-функциональным;
— нужно API и нормальная интеграция с Битрикс24/1C;
— поддержка плагинов держится на одном энтузиасте;
— отчётность важнее, чем просто список задач.

Главная ошибка при переезде — не в выборе новой системы, а в попытке перенести всё как есть. Особенно 25 кастомных статусов, которые никто уже не объясняет. Лучше сначала разложить процесс по схеме, а потом уже выбирать инструмент 🛠️

В проектах на 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: по слоям. Иначе однажды вы обнаружите, что ваш контент уже «прочитан», но по вашим правилам — нет.

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

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

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

Антиошибка недели: пытаться убрать вообще все неровности в коде и данных. В enterprise-системах это редко работает. Иногда быстрее и стабильнее не гладить систему, а правильно направить поток.

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

Схема обычно такая:
1) фиксируем, какие компетенции реально нужны продукту;
2) смотрим внутренний пул — аналитики, QA, разработчики, support, кто уже понимает контекст;
3) даем короткий маршрут роста: задачи под наставника, ревью, контрольные точки;
4) заранее считаем, что дешевле: найм с рынка или доращивание внутри.

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

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