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

Жиза №942

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

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

Поясню на примере.

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

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

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

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

Так и тратим недели на то, что решается за пять минут. Просто потому что все боятся открыто сказать «нет» или «мне это не нравится».

Поэтому подумываю вернуться в стартап и не считаю это дауншифтингом.
______________
Поделиться своей историей — @zhizaIT_bot

Сегодня хочется поговорить про условное «нытьё».

Раньше это было нормально:
— вот эта программа отвратительная
— вот этот таск-трекер бесит
— вот если бы было по-другому, я бы работал лучше

Я и сам таким был.
Меня раздражали таск-менеджеры, способы организации работы, чужие интерфейсы, чужая логика. Казалось, что проблема где-то «там», а не у меня.

А потом появился вайб-кодинг.

И внезапно парадигма перевернулась.
Не нравится инструмент? Сделай свой.
Не ложится процесс? Собери под себя.
Бесит интерфейс? Перестань ныть — перепиши.

И это, честно, очень освобождает.

Вчера на аналитическом марафоне я показал, как за 15–30 минут можно собрать небольшой сервис, развернуть его и выкатить в прод. Простейший, но рабочий. Сервис, который собирает так называемый vibe-case — постановку задачи, которую дальше можно скормить ИИ для реализации. Что-то среднее между use case и user story, но адаптированное под работу с нейросетями. Ссылку оставляю — можно просто посмотреть, как это выглядит.

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

Поэтому вывод простой:
1️⃣ Переставайте только жаловаться — используйте нейросети и вайб-кодинг, чтобы делать удобные инструменты под себя.
2️⃣ Если есть страхи, блоки, ощущение «я не технарь» — это нормально. С этим можно и нужно работать.

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

В группе осталось всего два места.
Если хотите перестать ныть и начать делать — самое время вписаться.

Если интересно — пишите, переходите по ссылке и задавайте вопросы.

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

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

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

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

Разница между этими подходами хорошо видна в метриках.

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

Например, вместо абстрактного «Kafka работает» появляется вполне конкретная продуктовая метрика: Time to First Message — сколько времени проходит от запроса команды до первой записи в топик. Если это минуты — у вас продукт. Если дни или недели — у вас сервис с бюрократической обвязкой.

Если упростить, различие выглядит так:

Сервисная платформа
— метрика успеха: аптайм
— пользователь: источник риска
— главный артефакт: заявка

Продуктовая платформа
— метрика успеха: time-to-market
— пользователь: клиент
— главный артефакт: быстрый результат

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

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

Если хочется совсем приземлить эту мысль, вот простой вопрос для самопроверки, который можно задать платформенной команде уже завтра:

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

Ответ на этот вопрос очень быстро показывает, вы строите продукт или просто охраняете вход в кластер.

В общем, я запустил новый продукт для транскрипции — Transcribe It.

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

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

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

Что есть сейчас:

— Бесплатный режим: 30 минут в месяц, чтобы посмотреть на качество и понять, подходит ли вам сервис.
— Платный доступ: больше минут + возможность работать через API.
— API-режим — лично для меня самый ценный сценарий: закинул аудио или видео, получил транскрипцию асинхронно, дальше делай с ней что хочешь — хоть в пайплайн, хоть в ИИ-обработку.

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

Если у вас есть похожая потребность — заходите, пробуйте.
Любая обратная связь приветствуется: что удобно, что бесит, чего не хватает.

Как обычно, буду рад комментариям и идеям 🙌

А если хотите научиться делать так же - то вот еще осталось местечко на интенсиве по vibe аналитике и кодингу

“Сделайте селф-сервис, чтобы бизнес сам спрашивал метрики” — любимая фантазия 2026.
Тут вспомнил, что не выложил запись рассказа Ильи Богословского в рамках нашего подкаста Аналитик и ИИ. Исправляюсь!

Проблема в том, что LLM пока отлично пишет SQL… и так же бодро может придумать тебе “правду”, которой в данных никогда не было.

Мы записали эфир с живым демо: как AI реально применяется в аналитике данных — без презентаций и без “магических слов”.
Показали путь от простого Text-to-SQL до MCP и агентских систем, которые сами ходят в ClickHouse и строят визуализации. И, что важнее — обсудили, где всё ломается: точность, контроль, безопасность, “уплывающее качество” и вечный вопрос “MCP vs API”.

Что внутри (по делу):
• ✅ Text-to-SQL и генерация витрин/ETL: ускорение есть, но без розовых очков
• ✅ self-healing пайплайны: логика ретраев + диагностика/фиксы через LLM
• ✅ семантический слой: почему без него “выручка” превращается в галлюцинации
• ✅ визуализация как код: быстрые дашборды “под вопрос”
• ✅ MCP и LangGraph: агентный подход и почему продакшен — это боль

Лучше один раз посмотреть демо, чем слушать “AI-евангелистов” без конкретики.
Youtube
VK Video
Rutube

Вопрос к тебе: ты бы сегодня дал бизнесу чат “спроси у данных”? Или пока только инженерам/аналитикам, которые умеют отличать ответ от бреда? 👇

Архитектурный Vision, который живёт до следующего комитета

Кейс из большого Enterprise.

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

Vision прошёл согласования.
Командам было сказано: «С этим решением вы идёте в прод».

А потом управленческое решение меняется.
Появляется другая «стратегически приоритетная» платформа.

И всё.

Старый Vision мгновенно становится недействительным.
С ним больше не пускают в промышленную эксплуатацию.
Интеграции нужно переделывать.
Архитектуру — пересогласовывать.
Проекты — зависают между «было можно» и «теперь нельзя».

И здесь важно зафиксировать главное.

Это не ошибка архитекторов.
Это не «не повезло с технологией».
Это провал архитектурного управления.

В такой системе архитектура — не способ проектировать будущее.
Это политический артефакт с коротким сроком жизни.
Его задача — дожить до следующего комитета и формально закрыть текущую повестку.

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

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

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

Финальные вопросы, которые, кажется, стоит задать себе честно:

Архитектурный Vision в вашей компании — это стратегия
или просто временное прикрытие текущего управленческого решения?

И кто в реальности несёт ответственность за то,
что утверждённая архитектура может быть обнулена в любой момент?

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

Игнорирование границ в IT — это как забыть про тормоза в машине. Рано или поздно ты врежешься. Представьте: компания решила внедрить новую CRM-систему, но по пути потерялась в джунглях интеграции с существующими системами. Почему это произошло? Потому что игнорировали границы и домены. Интеграция шла наугад, а не по четкому плану. Результат? Хаос и проблемы, которых можно было бы избежать.

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

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

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

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

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

#IntegrationChallenges #SystemBoundaries #ITBestPractices

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

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

Но вот что показывает практика.

Если прийти к бизнесу и начать объяснять:
— про распределённые транзакции,
— про eventual consistency,
— про лимиты брокера,
— про сложность рефакторинга legacy-монолита,

в лучшем случае тебе кивнут.
В худшем — скажут: «Хватит отмазываться. Делайте как мы сказали».

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

Попробуй перевести ту же самую мысль иначе:

— Это увеличит time-to-market на три месяца.
— Мы получим риск потери X% выручки при пике нагрузки.
— Это решение добавляет 20% к операционным расходам в год.
— Этот архитектурный компромисс ограничит масштабирование в два раза.

И внезапно разговор меняется.

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

Да, есть исключения.
Но в среднем — это не «неадекватные люди, которые сами не знают, чего хотят».
Это люди, отвечающие за деньги и результат.

И тут важный момент.

Особенно в российском IT (хотя не только там) я регулярно сталкиваюсь с ощущением «высшей касты инженеров».
Мы делаем сложнейшие системы.
Мы строим архитектуры.
Мы понимаем глубину технологий.
А бизнес — только мешает.

Но реальность проще и жёстче:

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

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

И в этом смысле аналитик, техлид, архитектор — это не «защитник кода».
Это переводчик между риском, деньгами и технологиями.

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

А как только начинаем говорить на их языке —
магия исчезает.
Остаётся нормальный взрослый разговор.

И, честно, в таких разговорах я почти всегда вижу не врагов,
а партнёров.

А вы замечали, как меняется реакция бизнеса, когда разговор переводится в деньги и риски, а не в технологии?

Жиза №938

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

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

На неделе прилетел очередной такой срочняк. Кривая интеграция, которую надо впихнуть костылями прямо в ядро, потому что «горит».

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

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

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

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

Проектируете ли вы интеграцию — или вы проектируете процесс?

На словах кажется, что это одно и то же. На практике — это две совершенно разные плоскости мышления.

Простой пример.
Есть пользовательская система. В ней работает пользователь.
Есть агент, который помогает этому пользователю.

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

Дальше начинается инженерная логика.
Система №1 интегрируется с системой распознавания:
передаётся идентификатор, создаётся внутренний ID — всё аккуратно, всё работает.
Потом подключается агент.
Данные из OCR складываются в Kafka с внутренним идентификатором.
Агент читает сообщение и думает: отлично, у меня есть ID, значит я смогу положить результат обратно в исходную систему.

И вот здесь происходит сбой.
Идентификатор, который агент получает из Kafka, не совпадает с тем идентификатором, по которому можно обратиться к API процесса в исходной системе.
Формально все интеграции были спроектированы.
Каждая пара систем взаимодействует корректно.
Документация, конечно, средненькая, но технически всё «работает».
Только процесс не работает.
Потому что никто не проектировал процесс целиком.

Каждый проектировал свою интеграцию: — система ↔ OCR
— OCR ↔ Kafka
— Kafka ↔ агент
— агент ↔ API
Но никто не проектировал сквозной поток:
«Документ загружен → распознан → обработан → результат возвращён в конкретный бизнес-процесс».
В результате — дополнительные трудозатраты, доработки, синхронизации, выяснение «какой именно ID это был».
И тут возникает важный вопрос.
Кто вообще отвечает за проектирование сквозного процесса?
Интуитивно хочется сказать: solution-архитектор.
Но часто архитектор рисует высокоуровневый Vision, определяет системы и интеграционные точки — и считает задачу закрытой.
А согласование идентификаторов, контекстов, состояний, жизненного цикла сущностей — «это уже детали», которые почему-то должны сами собой сложиться.
Не складываются.
Потому что интеграция — это про соединение интерфейсов.
А процесс — это про синхронизацию смыслов.
Можно идеально соединить API и при этом полностью сломать бизнес-поток.
Вот здесь и проходит водораздел.
Когда вы работаете в сложной системе, вы отвечаете за: — корректность технической интеграции
или
— за целостность процесса от начала до конца?
И это не риторический вопрос.
Потому что если никто не отвечает за процесс целиком,
то за него потом платят все.
А вы в таких историях что проектируете — интеграции или процесс?

Скажите, вы бы напряглись, если бы ваша компания проводила такой вебинар?)

У CodeFest открыт CFP — до 1 марта можно подать заявку на доклад 🎙

Я долго собирался и вот наконец то в этом году я тоже буду выступать и буду рад увидеть в программе знакомые имена — или открыть для себя новые.

Если вы, как и я, давно думаете: «Когда-нибудь выступлю» — возможно, это именно тот самый момент.

CodeFest — это не просто конференция с сильной аудиторией.
Это место, где:

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

Да, выступать немного волнительно.
Но это тот самый полезный стресс, после которого вырастаешь — и профессионально, и личностно.

И это не только про сцену.

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

Темы этого года можно посмотреть здесь:
https://16.codefest.ru/themes#program

Конференция пройдёт 30–31 мая 2026 в Новосибирске.

А если хотите просто прийти послушать — регистрация уже открыта:
https://16.codefest.ru/reg/

Увидимся на сцене или в зале 👋

Хочу сегодня поговорить про FOMO — Fear of Missing Out.
Вчера на занятии по web-аналитике рассказывал ребятам про инструменты, которые сам использую. Railway, Supabase, разные штуки для быстрого деплоя и сборки прототипов.
И кто-то из них впервые слышал про эти сервисы.
И в этот момент я снова поймал интересное ощущение.
С одной стороны — FOMO.
Каждый день появляются новые продукты, фреймворки, AI-инструменты, платформы.
Ты открываешь Twitter, LinkedIn, Product Hunt — и создаётся ощущение, что ты безнадёжно отстаёшь.
Что все уже разобрались, внедрили, автоматизировали, а ты всё ещё не там.
С другой стороны — реальность гораздо спокойнее.
Есть огромное количество людей, которые не знают даже про базовые инструменты, способные упростить им жизнь в два раза.
И это нормально.
Знание — коварная штука.
Как только ты что-то узнал, тебе кажется, что «это уже must-have, все должны это знать».
Но мир асинхронен. Каждый в своей точке.
И вот здесь для меня интересный вопрос.
FOMO возникает не потому, что мы реально что-то упускаем.
А потому что мы сравниваем свой «закулисный процесс» с чужой «витриной результатов».
В контексте инструментов это особенно заметно.
Кто-то уже собрал 10 сервисов на Railway.
Кто-то вообще не слышал про Supabase.
Кто-то только открывает для себя GitHub.
И это не про «умнее/глупее».
Это про траекторию.
Поэтому хочу спросить вас.
Интересно ли вам, если я начну делиться: — какими инструментами пользуюсь для сборки приложений,
— как я их выбираю,
— где они реально экономят время,
— а где это просто хайп?
Возможно, таким образом: — я чуть-чуть снижу своё FOMO,
— вы узнаете что-то полезное,
— а вы, в свою очередь, поделитесь своими находками.
И тогда вместо FOMO получится обмен.
А у вас сейчас FOMO больше про технологии или уже скорее про фокус?

Как находят работу за бугром в IT

Наити работу на немецком рынке. И не через релокацию! Сам нашел и сам переехал!

Это история Бизнес аналитика, который работает в Deutsche Bank и язвительно пишет из солнечного Франкфурта-на-Майне.

Из ХЗ в ТЗ — блог про работу в финтехе и как там у них. Антон также исследует рынок РФ и продолжает ходить на собеседования.

Истории, которые уже вышли:
🟢 собеседование в банк Азии. Кринж😬
🟢 красные флаги в тестовом задании. И референс ответа.
🟢 как мы делали mit den Jungs в банке
🟢 стал бы я в 2026-ом накручивать опыт в резюме?

Переходите знакомиться: @anton_alekseev

Извините, не могу пройти мимо