PRO продукты и системы | Иннокентий Бодров

Траты, которые окупили себя в IT-жизни

Вашему вниманию — честная, местами поучительная история Алексея, который:

▪️перешел на новую работу системным аналитиком с 30% ростом по зарплате;
▪️начинал смотреть курс с фразой «ну эта фингя и так в интернете есть»;
▪️а сейчас кайфует от работы, зарплаты и чувствует уверенность в своих hard-знаниях.
⠀
Что было между этими точками?

API. Курс про архитектуру и интеграции. Смирение. Мотивация и два часа времени в выходной.
⠀
Смотри запись огненного и мотивирующего интервью с Алексеем, рекомендую.
⠀
А, если охота менять карьеру к лучшему, — лови возможности.
Бесплатные уроки по архитектуре и интеграциям в чат-боте курса. Доступ не забирают.

@studyit_help_bot👈

🚀 Скидка на полный курс
от канала — 1 500₽ на Stepik по промокоду spheri до конца февраля.

🤔Как не потеряться в потоке новостей об IT и AI?

Технологии меняются ежедневно: выходят новые модели (как GPT 4o, Claude 3.5, Gemini 1.5), обновляются инструменты и фреймворки. Чтобы вы всегда были в курсе самого важного и получали информацию только от практиков, мы сделали это за вас!

📌Мы собрали эксклюзивную папку Telegram-каналов - экспертов в сфере IT и AI.

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

📎Подписывайтесь и становитесь частью технологического будущего уже сегодня!
https://t.me/addlist/rhToOl718R8yYTNi

Жиза №938

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#IntegrationChallenges #SystemBoundaries #ITBestPractices

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

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

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

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

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

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

И всё.

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

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

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

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

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

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

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

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

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

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

“Сделайте селф-сервис, чтобы бизнес сам спрашивал метрики” — любимая фантазия 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жиза №942

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

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

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

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

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

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

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

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

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

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

Вижу, что после последних постов ко мне начало прилетать довольно много историй от подписчиков.
Иногда в личку, иногда — с пометкой «можно анонимно».

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

Поэтому идея такая.

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

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

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

Если формат заходит — поддержите.
Если идея откликается — дайте знак.

А дальше посмотрим, что из этого получится 👀

Kafka-команда как сервис умывания рук

(кейс из менторской практики)

История от менти.
Крупный Enterprise. Нужно подключить сервис к Kafka.

На входе — нормальная бизнес-задача.
На выходе — аналитик, который внезапно должен:
• посчитать объёмы сообщений,
• определить количество топиков,
• выбрать число партиций,
• решить, сколько реплик и на каких брокерах,
• и аккуратно раскрасить заявку по цветам в Excel-шаблоне.
Да, буквально. Не метафора.

И вот здесь возникает простой вопрос:
а чем тогда занимается Kafka-команда?

⸻

Платформа сбрасывает ответственность — аналитик её ловит

Формально всё выглядит прилично.
Платформенная команда говорит:
«Мы не можем просто так дать доступ. Вы же можете положить кластер».

И дальше происходит ключевой трюк.

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

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

Это не про Kafka.
Это про страх ответственности, замаскированный под процесс.

⸻

Аналитик как высокооплачиваемая секретарша с навыками Excel-дизайнера

В этой модели аналитик перестаёт быть аналитиком.

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

А теперь ключевая метафора.

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

Это как если бы официант решал, при какой температуре повару жарить стейк, чтобы ресторан не сгорел.

Не потому что он эксперт.
А потому что иначе заказ не примут.

⸻

Архитектура на костылях из аналитиков

Почему эта модель токсична:
• решения принимают те, кто за них не отвечает,
• ответственность размазана,
• платформа превращается в охранника входа,
• аналитик — в универсальную прокладку между процессами.

И внезапно в компании начинают считать, что знание параметров Kafka важнее понимания бизнес-процесса.

Хотя должно быть ровно наоборот.

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

Не из-за сложности систем.
А из-за размытого ownership.

⸻

Финальный вопрос (не академический)

А вы кто в своей компании?
• архитектор смыслов,
• человек, который понимает бизнес-потоки,
• и проектирует решения

или

бесплатное приложение к Jira-шаблону платформенной команды,
которое ещё и аккуратно раскрашивает ячейки, чтобы заявка прошла дальше?

Вот здесь, кажется, и проходит настоящая граница роли аналитика.

💻IT движется так быстро, что пока ты гуглишь ошибку, нейросеть уже успела написать ответ, ошибиться, извиниться и переписать всё на Rust.

📌В 2025-2026 году быть «просто программистом» - это как пользоваться дисковым телефоном: винтажно, но не очень эффективно. Сейчас нужно либо дружить с ИИ, либо надеяться, что твоя микроволновка не научится кодить быстрее тебя.

Чтобы не стать «цифровым динозавром» и не тратить часы на поиск годных инструментов, мы собрали для тебя ультимативную папку каналов про IT, в которой ты найдешь:
➖Практические фишки для разработчиков.
➖Гайды по внедрению ИИ в рабочие процессы.
➖Главные апдейты нейросетей и многое другое

📎Читай только лучшее. Добавить папку
https://t.me/addlist/ZZf7KeUOKZA2NTli

Вчера у меня был частичный «день Х» — запуск курса по транскрайберу.
Не всё взлетело идеально: сейчас допиливаю вопросы с DNS и подпиской. Такое бывает. Стартап-реальность без глянца 🙂

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

Я запускаю второй Telegram-канал.
Он называется «Аналитик, который думал».

Это не просто ещё один канал с постами.
Фактически, это полноценный AI-assisted проект, собранный по тому самому подходу AI Workspace, о котором я рассказываю на интенсиве по вайб-аналитике.

Как это устроено:
• темы задаю я
• канву, логику и направление задаю я
• весь контент проходит мою проверку
• канал отражает мой реальный опыт и мышление

Но:
тексты, иллюстрации и подготовку материалов делает группа AI-агентов, под моим строгим контролем.

Важно разделить контексты.

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

👉 «Аналитик, который думал» —
это канал-библиотека для системных и бизнес-аналитиков.

Формат там будет другой:
• одна неделя — одна тема
• глубокий разбор темы с точки зрения аналитика
• техники, подходы, мышление, примеры
• не «новости», а структурированное знание

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

Посты будут выходить 2 раза в день — утром и вечером.
А ещё аудитория сможет влиять на выбор темы следующей недели.

Для меня это эксперимент:
и как продукт,
и как формат,
и как пример того, как аналитик может использовать ИИ не для «генерации воды», а для создания системного знания.

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

— подписывайтесь

Продолжение следует.

Стартуем с ИИ через 5 минут!

Сегодня в 20:00 по Москве стартует мой курс по Vibe-аналитике.
И сегодня же — первое открытое занятие, на которое можно прийти бесплатно.

Это курс про то, как аналитику:
— работать с ИИ не как с игрушкой, а как с инструментом,
— быстрее доходить от идеи до работающего решения,
— и не застревать в «писании ТЗ ради ТЗ».

Важно:
группа камерная — всего 12 человек.
На текущий поток осталось 2 места.

👉 Только до конца сегодняшнего дня по Москве эти места можно занять по старой цене — 8 900 ₽.
С завтрашнего дня цена немного вырастет.

Если будет высокий интерес (а он уже есть), через 2–3 недели я запущу вторую группу, уже с учётом всех выводов первого потока.

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

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

Буду рад видеть вас 🙌