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

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

Компании сокращают мидл-менеджмент. Не весь и не сразу, но роли, которые в основном передают информацию между людьми и командами, уже попали под пересмотр. В 2025 году Google сообщил: за год стало на 35% меньше менеджеров с командами меньше трёх человек. Многих не уволили. Они вернулись к работе отдельных специалистов. Логика простая: отдельный слой управления для двух-трёх человек может обходиться дороже, чем создаёт ценности. И тут я вспомнил доклад Димы Безуглого на ЛАФ-2019 «Чем будет заниматься аналитик через 5 лет». Его мысль была шире профессии: будущее аналитика нельзя обсуждать отдельно от устройства компании. AI необязательно заменяет профессию целиком. Сначала он снижает ценность посреднических функций: переслать, согласовать, собрать статус, переложить требования из одного документа в другой. Менеджер, который только собирает и передаёт статусы, добавляет отдельный уровень затрат. Аналитик, который только переносит требования, тоже. Компании продолжат платить тем, кто исследует, синтезирует знания, связывает решения с результатом, принимает риск и отвечает за то, что получилось. Вопрос «заменит ли AI аналитика» мало помогает в работе. Практический вопрос звучит так: какая часть моей работы уже не требует отдельной должности? Источники: https://www.cnbc.com/2025/08/27/google-executive-says-company-has-cut-a-third-of-its-managers.html https://lafest.ru/all_classes/P15.html https://hbr.org/2013/12/how-google-sold-its-engineers-on-management

«Папа, тебе надо печатать быстрее. Чем быстрее кликаешь по клавишам, тем больше денежков заработаешь». Сегодня получил от ребёнка, пожалуй, самую лаконичную консультацию по карьерному росту за последнее время 😁 И ведь самое смешное — лет пятнадцать назад в этом действительно было довольно много правды. Быстрее пишешь код, быстрее оформляешь требования, быстрее собираешь презентации — выше твоя производительность. Мы довольно долго измеряли собственную эффективность через количество того, что можем произвести руками. А сейчас эта связь начинает стремительно ломаться. Я могу печатать в два раза быстрее, но агент за это время напишет несколько тысяч строк кода. Могу очень быстро оформить постановку, но LLM соберёт черновик раньше, чем я закончу первый раздел. Даже скорость поиска информации перестаёт быть преимуществом, когда рядом есть инструмент, способный за минуту прочитать десяток документов. Получается забавная штука: стоимость наших рук падает, а стоимость решений растёт. Сегодня мне гораздо важнее не быстро написать спецификацию, а решить, что вообще стоит специфицировать. Не быстрее написать код, а понять, какой продукт нужно строить. Не обработать больше информации, а определить, каким источникам можно доверять и какое решение принять на их основе. И вот тут ребёнку пока придётся немного возразить. Чтобы больше зарабатывать, папе теперь надо не быстрее нажимать на клавиши, а дольше думать перед тем, как нажать Enter. 😁 Хотя если посмотреть на количество времени, которое я провожу за клавиатурой, возможно, его теория всё-таки ближе к реальности, чем моя.

​Самый полезный сбой в моих тестах локальных моделей выглядел как успех. Три маршрута получили по 10 принятых результатов из 10. Красивый итог, который легко прочитать как «всё работает». Потом я разложил путь к этому результату. Первому маршруту понадобилось три ремонта, второму два, третьему один. Одинаковый итог описывал разное устройство процесса. С историческими запусками обнаружилась ещё одна проблема. Из 21 сохранённой записи только четыре содержали полный результат, который можно было оценивать по качеству. Остальные 17 были незавершёнными или повреждёнными. В общей метрике они выглядели как плохие ответы модели, хотя часть сбоев произошла раньше: среда не завершила работу или контракт пропустил неполный результат. Я не считаю это доказательством плохого качества модели. Модель была только одной частью связки. Ошибка была в том, как я определил успех: смешал завершённость, автоматическую проверку и человеческую приёмку. Теперь хочу собрать похожие случаи из практики. Если агент выдал убедительный результат, а позже обнаружился пропуск, неверное допущение или незавершённый документ, пришлите пример в комментариях или личном сообщении. Достаточно описать задачу, ожидаемый результат и наблюдаемый сбой. Подходящий случай смогу разобрать обезличенно.

Немного про мемы. Сегодня в голову пришла внезапная мысль, что 3 сентября это же six seven для миллениалов. А вообще интересно, что люди, которые говорили "Превед медвед" и "Йа креведко" осуждают детишек за их 6-7))

​Часто первый шаг выглядит так: открыть новый чат и загрузить туда папку документов. Но десять файлов ещё не образуют контекст. В папке могут лежать старая страница из Confluence, новый API-контракт и переписка с решением, которого пока нет в документации. Если сразу попросить агента сделать вывод, он обычно собирает связный ответ. При этом более убедительный документ может получить больший вес, чем актуальный. А конфликт двух версий исчезнет внутри аккуратного пересказа. Поэтому я начинаю с карты источников. Для каждого материала фиксирую: • что это за источник; • кто отвечает за его содержание; • когда его обновляли; • какой у него статус; • какую часть задачи он покрывает; • с какими источниками он расходится. Первый результат такой работы — не пересказ папки, а Source Map. После неё уже можно очерчивать границы задачи и собирать компактный контекст для агента. Здесь лежат бесплатный шаблон Source Map и заполненный пример: https://analystcraft.ru/coworker/templates?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm01_scp&utm_content=20260901-context-starts-with-sources

​Я довольно долго считал «10 из 10» самым понятным результатом теста модели. Все сценарии приняты, значит, конфигурация работает. После разбора первичных записей эта цифра стала для меня гораздо менее удобной. В одном эксперименте все три маршрута получили 10 принятых результатов из 10. Но первому маршруту понадобилось три ремонта, второму два, третьему один. Итоговый pass rate одинаковый, а путь к нему разный. Поэтому 10/10 здесь описывает не модель отдельно, а всю связку: модель, контракт результата, проверку, ремонт и повторную проверку. Исторический набор показал другую проблему со знаменателем. В нём сохранилась 21 запись. Только четыре содержали полный результат, который можно было допустить к оценке качества. Остальные 17 были незавершёнными или повреждёнными. Раньше я складывал их в один ряд с полными, но плохими ответами модели. Теперь я развожу три вопроса: 1. Агент завершил работу и вернул целый результат? 2. Результат прошёл заранее заданные проверки? 3. Человек принял его для исходной задачи? «10 из 10» отвечает только внутри конкретного контура проверки. Без числа ремонтов, исходного знаменателя и границы человеческой приёмки эта цифра не доказывает качество модели. Мне понадобилось несколько десятков прогонов, чтобы перестать читать pass rate отдельно от процесса, который его произвёл.

Читатель Use Case: дайджест за день 5 лучших материалов: 1. Enterprise Requirements Management for Regulated Teams - Visure Solutions Коротко: О том, как управлять требованиями в регулируемых проектах с учетом трассируемости, изменений и соответствия нормам. Полезно практику, если нужно связать требования, риски, проверки и доказательства в одном процессе. https://visuresolutions.com/alm-guide/enterprise-requirements-management/ 2. Requirements Validation Checklist - Visure Solutions Коротко: Материал про проверку требований до начала разработки: как убедиться, что они полные, непротиворечивые и действительно отражают нужды бизнеса и стейкхолдеров. Помогает снизить переделки и ошибки на поздних этапах. https://visuresolutions.com/alm-guide/requirements-validation-checklist/ 3. GitLab compliance frameworks: Adhere to SOC 2 in minutes Коротко: Разбирается, как автоматизировать контроль соответствия стандартам вроде SOC 2 через шаблоны, политики и постоянные проверки в платформе. Полезно тем, кто хочет уйти от ручного сбора доказательств и видеть статус комплаенса постоянно. https://about.gitlab.com/blog/quick-compliance-with-compliance-framework-templates/ 4. What is Requirements Engineering: Process for Software and Systems - Visure Solutions Коротко: Обзор процесса инженерии требований: от сбора и анализа до документирования и сопровождения на всем жизненном цикле системы. Практику пригодится как базовая схема, чтобы выстроить работу с требованиями без хаоса. https://visuresolutions.com/fr/alm-guide/requirements-engineering/ 5. Requirement Mapping Matrices - Visure Solutions Коротко: О матрицах трассируемости требований: как связывать требования с целями, рисками, тестами и результатами проверок. Полезно для контроля покрытия, оценки влияния изменений и поиска пробелов в документации. https://visuresolutions.com/requirement-mapping-matrices/

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

🔥 Кажется, я дошёл до ручки. Пришлось строить PM-штаб для самого себя. В какой-то момент я открыл список всего, чем сейчас занимаюсь, и понял, что обычный таск-менеджмент больше не работает. Есть AnalystCraft с контентом, курсами, сайтом и Подмастерьем. Есть Seturon, внутри которого уже несколько самостоятельных направлений. Есть ещё несколько продуктов на разных стадиях проверки гипотез. Есть работа, поиск следующих карьерных возможностей, статьи, выступления и вся остальная жизнь, которая почему-то тоже требует времени. Причём проблема не в том, что я не знаю, что делать дальше. Наоборот. Практически у каждого проекта есть совершенно понятный следующий шаг. И именно поэтому всё начинает разваливаться: каждый следующий шаг выглядит достаточно разумным, чтобы заняться им прямо сейчас. В какой-то момент я понял, что мне нужен уже не ещё один backlog и не более красивый Notion. Мне нужен портфельный уровень управления — условный PM-штаб, который управляет не задачами, а конкуренцией проектов за моё время. Главное изменение оказалось довольно болезненным: я перестал считать все важные проекты активными. Теперь у проекта должен быть режим. Что-то находится в Active и действительно получает время каждую неделю. Что-то — в Validate, где нужно проверить одну конкретную гипотезу и решить, стоит ли продолжать. Что-то можно просто поддерживать, что-то инкубировать, а что-то честно положить на полку. И самое важное — ограничить WIP уже не на уровне задач, а на уровне проектов. Потому что можно прекрасно управлять десятью backlog'ами и всё равно ничего не закончить. Сейчас хочу довести эту систему до довольно простого цикла: раз в неделю PM-штаб смотрит на весь портфель, проверяет цели и результаты и решает, какие 2–3 проекта вообще имеют право конкурировать за моё время на следующей неделе. Остальные не исчезают и не становятся менее важными — они просто ждут своей очереди. Пока это выглядит немного смешно: я строю процессы управления для компании, состоящей в основном из меня и пачки AI-агентов 😁 Но, кажется, это вполне логичное продолжение вайбкодинга. Когда AI позволяет одному человеку запускать всё больше вещей, следующим ограничением становится уже не разработка. Ограничением становишься ты сам. Вот теперь и проверим, можно ли это бутылочное горлышко нормально спроектировать.

🔥 Про демо, факапы и ещё один пункт в моём pre-demo checklist Вчера был эфир с Антоном, где я собирался показать «Подмастерье» в довольно интересном режиме: полностью локальные модели, работа с требованиями, поиск противоречий между источниками и всё то, ради чего я последние месяцы его строю. К демо готовился как положено. Все выходные вылизывал сервис, несколько раз прогонял сценарий, в понедельник проверил ещё раз — всё работало. Не молниеносно, потому что модели локальные, но стабильно и вполне адекватно. И примерно за час до эфира началось. Сначала упал локальный gateway к моделям. Подняли. Потом модели начали отвечать странно и медленно, полезли какие-то ошибки. При этом ни код, ни конфигурацию я не менял — буквально тот же билд, на котором до этого гонял тесты. А потом перестала работать даже пересборка приложения. После некоторого количества инженерной археологии нашли виновника. Windows Update. На ноутбуке есть диск C. Windows скачала туда обновление, забила практически всё свободное место и дальше начала довольно эффективно уничтожать мой demo environment. Само «Подмастерье» лежит на D, но сборка локального exe всё равно использует C. В результате не работали модели, приложение и даже возможность нормально его пересобрать. Примерно полчаса мы с Антоном вместо демо обсуждали локальные модели, OpenSpec и вообще подходы к работе с AI. Получилось интересно, но тот самый сценарий я в итоге так и не показал. Зато факап оказался полезным. Во-первых, в pre-demo checklist появился новый пункт: проверить свободное место на системном диске и состояние обновлений Windows. Никогда не думал, что буду это писать, но вот мы здесь. Во-вторых, я окончательно решил переделать архитектуру «Подмастерья». Вместо монолитного локального exe будет три отдельных слоя: сервис работы с локальными моделями, backend и отдельно UI. Так проще тестировать, отлаживать и, что стало особенно важно после разговора с Антоном, поддерживать разные платформы. Потому что выяснилась ещё одна интересная вещь: Windows среди аналитиков уже далеко не настолько безальтернативна, как мне казалось. Кто-то работает на Mac, кто-то на обычном Linux, а у кого-то уже Astra Linux, Сбер Linux и прочая корпоративная экзотика. Поэтому теперь мне нужна помощь зала. На какой ОС вы работаете как аналитик? 👌 — macOS 👍 — Linux 😭 — Windows Если у вас какая-нибудь особенно прекрасная корпоративная сборка — рассказывайте в комментариях. Мне теперь это уже не просто любопытно, а вполне себе продуктовый research 😁

24 августа разбираем требования вместе с Антоном Зиминым Вечером 24 августа проведём совместный эфир с Антоном Зиминым, автором «Чулана системного аналитика». Возьмём кейс интеграции с платёжным провайдером. В нём устаревшая вики, документация вендора на другую версию и переписка с поддержкой дают разные ответы. По отдельности каждый источник выглядит убедительно. Противоречия становятся видны, только когда собираешь их вместе. Покажу весь путь: как найти расхождения, выровнять требования, передать постановку агенту и превратить сценарии и e2e-тесты в критерии приёмки. И да, все по максимумум на локальных моделях!!! Антона зову не поддакивать. Его задача — проверить подход на прочность: где карта источников создаёт лишнюю бюрократию, что мы упускаем при выравнивании и может ли тест, написанный до кода, подтвердить, что агент сделал именно то, что требовалось. Планируем час: короткая вводная, разбор источников и постановки, затем спор про сценарии, тесты и вопросы. 24 августа, 8 вечера МСК, регистрация тут

Все же помнят, что сегодня мы с Антоном будем ковырять требования и ИИ, причем буду показывать как это работает на маленьких локальных моделях

Верный SQL, но неверный ответ Данные не врут, но и не отвечают на все, что о них спрашивают. Валидный SQL возвращает ровно то, что попросили, а не то, что стояло за просьбой. Отсюда классическая история: цифра правильная, но вывод неверный, потому что задача была понята не так. Работа продуктового аналитика в этом месте близка к работе с требованиями: разобрать, о чем именно спрашивают, проверить допущения, зафиксировать противоречия — и только после этого собирать ответ. 25 августа karpovꓸcourses проводят бесплатный вебинар про этот путь. На реальных примерах пройдут: — какие вопросы задать заказчику до запроса, чтобы выгрузка отвечала именно на его задачу; — как проверять данные после выгрузки; — типовые ловушки в расчетах, из-за которых верный запрос возвращает неверный ответ; — как превращать таблицу с цифрами в вывод и рекомендацию на языке бизнеса. Разбирает Дмитрий Бакаев — продуктовый аналитик в «Передовых Платежных Решениях» и выпускник курса «Аналитик данных» karpovꓸcourses. Вопросы принимает в эфире. За регистрацию сразу приходит карьерный гайд по профессиям в аналитике, после эфира — запись вебинара Регистрируйтесь по ссылке — https://clc.to/erid_2W5zFJreJrD    Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFJreJrD 

24 августа разбираем требования вместе с Антоном Зиминым Вечером 24 августа проведём совместный эфир с Антоном Зиминым, автором «Чулана системного аналитика». Возьмём кейс интеграции с платёжным провайдером. В нём устаревшая вики, документация вендора на другую версию и переписка с поддержкой дают разные ответы. По отдельности каждый источник выглядит убедительно. Противоречия становятся видны, только когда собираешь их вместе. Покажу весь путь: как найти расхождения, выровнять требования, передать постановку агенту и превратить сценарии и e2e-тесты в критерии приёмки. И да, все по максимумум на локальных моделях!!! Антона зову не поддакивать. Его задача — проверить подход на прочность: где карта источников создаёт лишнюю бюрократию, что мы упускаем при выравнивании и может ли тест, написанный до кода, подтвердить, что агент сделал именно то, что требовалось. Планируем час: короткая вводная, разбор источников и постановки, затем спор про сценарии, тесты и вопросы. 24 августа, 8 вечера МСК, регистрация тут

Собирая первую версию продукта, легко попытаться положить в неё весь замысел. Когда я задумывал сквозной кейс Acme Pay с TDPD, хотел показать весь путь: от пяти противоречащих друг другу источников до реализации агентом, e2e-тестов и приёмки. По ходу сборки выяснилось, что первая половина уже существует как связный кейс. Есть исходные документы, карта источников, противоречия, журнал решений и рабочая постановка. Вторая половина пока устроена иначе. У меня есть метод, отдельные рабочие эпизоды и опыт с TDPD, но нет одного воспроизводимого прохождения этого кейса через разные агентские среды. Более того, на интенсиве участники запустили TDPD в разных агентах, и результаты начали заметно отличаться. Вскрылись вопросы к установке и переносимости самого метода. Можно было всё равно собрать красивый сквозной рассказ. Но тогда материал выглядел бы законченнее, чем он есть сейчас. Поэтому в кейсе Acme Pay я оставил только то, что могу предъявить и проверить: источники, найденные разрывы, решения и переход к постановке. Рядом объяснил, где начинается TDPD, но не стал выдавать незавершённую часть за готовый универсальный процесс. Мне всё больше нравится такое определение первой версии: она заканчивается не там, где кончились силы, а там, где кончились подтверждённые обещания.

🔥 Будни вайб-фаундера, вайб-кодера и немножко продакт-овнера Договорились мы сегодня с моим AI-помощником по стратегическому планированию, что пора запускать очередной небольшой эксперимент: новый микропродукт, проверка спроса, лид-магнит, оплата — всё по канонам продуктового маркетинга. Казалось бы, чего сложного? Берём существующий сайт, делаем страницу, запускаемся. Прихожу на сайт — а он так не умеет. Ну ладно, я же теперь вайб-кодер. Допиливаем нужную механику, тестируем — работает. Отлично, можно запускать. Но стоп. Это же продукт, за него предполагается брать деньги. Значит, неплохо бы проверить оплату. Оплата не работает. Чиним оплату. Починили, идём дальше — после покупки должно приходить письмо. Письмо не приходит. Почему? Потому что кто-то очень умный не настроил почту в переменных окружения. Кто этот человек, история умалчивает, но мы с ним хорошо знакомы. Настроили. Теперь-то всё? Конечно нет. Если мы умеем принимать деньги, неплохо бы ещё проверить возврат. Нажимаю refund и... Возврат тоже не работает. Ещё немного отладки, немного нервов, немного мата — и внезапно вся цепочка действительно начинает работать: страница → оплата → письмо → возврат. И вот что мне особенно нравится в современном вайбкодинге. AI действительно позволяет одному человеку очень быстро собрать продукт, на который раньше понадобилась бы маленькая команда. Но он совершенно не отменяет старую добрую инженерную реальность: между «фича написана» и «продукт работает» находится довольно много неприятных мелочей. И именно поэтому я всё меньше верю в разработку по принципу «агент сказал done — значит done». Done наступает не тогда, когда код написан, а когда пройден пользовательский сценарий целиком. Зато теперь могу представить ещё один маленький микропродукт, который, надеюсь, нанесёт вам непоправимую пользу 😁

Я снова на хабре! Запилил статью про TDPD и то как параллельно со мной это разрабатывают в OpenAI (посмотрим кто кого, хех). P.S. Статья в песочнице, но если кто то кинет мне инвайт - буду очень благодарен)

Наблюдаемость не доказывает, что агент прав 200 OK означает, что запрос завершился. Для AI-агента это почти ничего не говорит о результате. В разборе Gallopher про наблюдаемость агентных систем разведены три уровня: инфраструктура сработала, агент принял решение, пользовательский процесс пришёл к нужному исходу. Обычный мониторинг лучше всего видит первый. Пользовательский исход часто остаётся за кадром. Но я бы добавил одну ловушку. Можно подробно записать каждый шаг агента и всё равно проверять не то. Если критерии оценки появились после реализации или их породил тот же агентный контур, неверная посылка может пройти через решение, результат и проверку. Трасса будет полной. Тесты будут зелёными. Пользователь получит не то, что ему было нужно. Поэтому я забираю из статьи в TDPD не новый гейт, а отдельный контракт доказательства запуска. Для каждого значимого прогона должны быть видны: - версии модели, инструкций, инструментов и доступа; - источники контекста и путь принятого решения; - вызовы инструментов, разрешения и побочные эффекты; - проверки результата и связь с UAT. Если обязательной части трассы нет, это не PASS, а INCOMPLETE. Для рискованного действия — остановка. При этом сама трасса не становится судьёй: мы фиксируем критерии приёмки до реализации, а UAT оставляем отдельной человеческой проверкой исходного замысла. Исходный материал: Designing Observable AI Systems.

👀Что проще - зарабатывать 1 млн руб. в найме или в собственном проекте? Или все-таки сочетать? Автор этой схемы на своем опыте рассказывает, как сделать миллион в найме, где сейчас стоит учиться, с какой компании начать работу, надо ли «прыгать по компаниям» и как раскачивать личный бренд. 🔥Вот ТОП посты, которые точно пригодятся - Каких продактов выделяет рынок труда - Какие продакты сейчас самые востребованные на рынке - МОК-собес на product manager Ну и вот что нам особо интересно: 🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к 🔴Какой продакт лид получил 12 млн по году 🔴Оффер на Product lead в Яндекс Много полезненького )) 💬@proProject1