Research Is Not Engineering at a Slower Speed. https://voiceinthemachine.com/2026/06/10/research-is-not-engineering-at-a-slower-speed/ Я когда-то уже писал пост про то, чем занималась моя R&D команда, а тут вышел довольно интересный write up про различия между ресерчем, R&D и продуктовой разработкой от очень опытного чувака (сам Ян Лекун его рекомендует). Tldr такой, что в ресерче и продуктовой разработке все просто и понятно (с точки зрения ролей, системы оценивания и тд), а в R&D — наоборот. И что компании часто смешивают внутри R&D кучу всякой деятельности. У меня ровно так и было — команда одновременно делала: * и ресерч — копание в статьях, создание новых моделей и архитектур; была наша собственная амбиция догнать и перегнать дипмайнд по части рекомендашек * и довольно большой объем продуктовой разработки — копание в конкретных продуктовых доменах, активное участие в доведении моделей до прода, много внедрений каждое полугодие * и строила инфру — инструменты для работы с данными, обучения и внедрения моделей В статье также много места посвящено тому, где компании часто спотыкаются: 1. Оценивают ресерчеров по инженерным метрикам 2. Называют инженерную деятельность прорывным ресерчем 3. Теряют тот ресерч, который зародился сам по себе и не вписывается в рамки существующих процессов Со всеми пунктами тоже согласен, видел похожее на практике. Чтобы был сильный ресерч, нужны соответствующие люди, с нужными навыками и опытом. Все эти три пункта мешают найму/росту таких людей; скорее их отталкивают. До сих пор довольно много про это думаю в контексте рексистем — как правильно организовать такую команду, как её правильно оценивать, как найти/взрастить нужных людей, органично интегрироваться в структуру большой организации. Мыслей и идей за последний год накопилось много, надеюсь, доведется их как-нибудь реализовать.

Beach house experience Последние несколько дней мы всей командой бизнеса и продукта Salmon Moto Marketplace работали не из офиса, и не из дома, а из Beach House. Вилла на Бали с бассейном, множеством спален и несколькими классными пространствами для командной работы. Это гораздо полезнее, чем очередной стратегический воркшоп с презентациями. Когда каждый день заполнен созвонами, задачами и дедлайнами, легко потерять ощущение общей картины. А стоит сменить обстановку — и за несколько часов появляются разговоры, на которые в офисе никогда не находится времени. Мы обсуждали не только роадмап и метрики. Говорили о том, что нас тормозит, какие решения уже не работают, как каждый видит развитие продукта через год-два. И это не просто разговоры. Я давно заметил, что хорошие идеи имеют привычку появляться не за столом переговоров, а во время прогулок, ужина или вечернего караоке. Есть азиатская поговорка: прежде чем вести бизнес с человеком, сначала нужно вместе выпить. Я бы сформулировал шире: сначала нужно провести вместе время. Доверие между людьми появляется не в Jira и не в Zoom. А без доверия невозможно быстро принимать решения, спорить без конфликтов и строить действительно сильные продукты. Особенно сильно это ощущается в распределенных командах. Несколько дней вместе могут дать больше для эффективности, чем десятки дополнительных синков в календаре. Кажется, такие выезды — это не корпоративная привилегия. Это такая же инвестиция в продукт, как найм сильных людей или покупка хороших инструментов разработки. Ведь в конечном итоге продукты создают не процессы, а команды. Круто, что в Salmon это понимают! #salmon #teamwork

У Эрика Риса (того самого автора Lean Startup) вышла новая книга — Incorruptible. Читаю, оч нравится и сильно резонирует, впечатлениями поделюсь отдельно, а пока разберу, что про неё написал Марти Каган. Всю карьеру Каган повторял: сильный продукт — вот что делает компанию сильной. Теперь поправка: продукт необходимое условие, но не достаточное, а иногда именно он компанию и губит. Звучит вывернуто, но логика простая: как только ты доказал, что умеешь делать хорошие продукты, компания становится лакомой добычей для опуртунистов. Приходят люди с другим интересом: быстро снять кэш и выйти. Заходят в борд, меняют основателя, вычищают миссионеров, за пару лет выжигают культуру, и то, что собиралось годами, схлопывается. Каган бывало умолял советы директоров не выкидывать лидеров из-за одного слитого квартала: просадки бывают у всех, смотрите на длинный горизонт, вы и себе роете яму. По факту, редко работало, и Каган отмечает это, как свой слабый скил. Убедить инвестора, который в продукте не шарит, почти никогда не получалось. Как правило, это не болячка хрупких стартапов, так же перемалывает и зрелые компании. Годами он считал это просто платой за живую экосистему. Неизбежное зло, забей, занимайся тем, что в твоей власти. Книга Риса заставила его в этом усомниться. Если Lean Startup была про то, как построить сильный продукт, то Incorruptible — про то, как построить компанию, которую у тебя не отнимут. И защита тут не продуктовая и не культурная, а скучная — корпоративное управление. Структуры, которые Рис зовёт mission-locked: миссию юридически зашивают в устав так, что перехватить контроль и перекрутить бизнес на короткие деньги технически невозможно. Каган же governance всю жизнь держал за тему для юристов, сам туда не лез, спихивал на аутсорс, но книга его натолкнула на осознание ошибки. И книгу читает почти как приговор юристам, бизнес-школам и консультантам, которые должны были компании защищать, а в итоге просрали все полимеры. И почему это вообще про продакта, а не только про основателя. От того, как устроено владение компанией, тихо зависит, дадут тебе делать нормальный продукт или ты каждый спринт/квартал/ревью будешь отбиваться от секвестра. Неочевидно, если ты привык мерить компанию продуктом, а не тем, кто ей рулит и на каких условиях. https://www.svpg.com/great-products-bad-companies/

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

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

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

Он бы не прошел у меня собеседование. Дочитал книгу Steve Jobs in Exile. Вышла всего месяц назад и на русский ещё не переведена. Про период, когда Джобса выгнали из Apple, и как он основал NeXT. Написана по внутренним документам, протоколам совета директоров и рассказам сотрудников. Местами такой абсурд, что сложно поверить, что это документалка. 1985 год, Стив открывает NeXT. Бизнес-плана нет, продукта нет, есть только идея делать компьютер для студентов. У него много своих денег, и он получает еще $20 млн инвестиций. Для начала Стив заказывает логотип компании за $100к (около $300к на сегодняшние деньги; напомню, у компании еще нет ни продукта, ни выручки). Компания сжигает по $1 млн в месяц, а он закупает в офис кресла по $2к и диваны по $10к. Он строит собственный завод под компьютер, конструкцию которого ещё даже не утвердили. На полном серьёзе планирует, что клиенты будут прилетать за компьютерами прямо на завод, как ездят в Италию за Ferrari. Его нездоровый перфекционизм заставляет команду бесконечно переделывать прототип. Когда из-за его же правок срываются сроки, он увольняет за это начальника производства. Его предупреждают, что компьютер дороже $3к никто не купит. Он выпускает за $10к. За первый год продаётся 205 штук вместо запланированных 50 тысяч (0,004% от плана 🙂) Приходит крупный контракт от IBM и в день презентации команда забывает слайды. Стив разворачивается прямо в аэропорту и улетает домой. IBM разрывает договор. Дела идут так плохо, что когда он нанимает нового CFO, то отказывается показывать настоящую отчётность до его выхода на работу. Говорит, что ему нужен risk taker. CFO выходит, видит реальные цифры, понимает, что компания фактически банкрот — и увольняется. Я вот думаю, что тот Стива Джобс не прошёл у меня собеседование. Я бы не нанял его на работу. И как инвестор я бы не вложил в него ни доллара. И как ни горько это признавать, я бы упустил настоящий джекпот. Потому похоже что горькая правда жизни в том, что никогда нельзя списывать со счетов того, кто излишне самоуверен в себе.

Коллеги, я не смогу всегда модерить чат, так что пожалуйста на почве разницы ваших опытов не ругайтесь. Есть люди, которым удобнее бегать зимой, а есть те, кому удобнее летом. Также и в IT всегда будут люди, которым нравится не тот формат работы, что их соседу. Выше я не пытаюсь выставить один способ работы лучше, чем другой для всех. А скорее просто придумал дополнительный аргумент в спор с очередным гипотетическим работодателем по поводу моей личной позиции. Если у вас похожая ситуация — пользуйтесь. Если нет — просто примите к сведению, что такая точка зрения тоже есть. Это как фидбек на задачу. В один вы записываете этот фидбек. А уже в другой вы с ним действительно что-то делаете. Можете решить, что он весь был для вас бесполезен — это тоже результат.

Недавно меня искренне спросили почему я не рассматриваю работу оффлайн. Я честно ответил, что я начинал работу в геймдеве со смешанной командой и для меня никогда не существовало вопроса: "А может ли команда в офисе работать эффективнее?". Мы обязаны были работать также эффективно. Опыт показывает, что нет серебряной пули и человек работает эффективнее (о, сюрприз!) в условиях, которые ему нравятся больше. Поэтому кто-то лучше перформит оффлайн, а кто-то — онлайн. Мой вариант — онлайн. Это не мешает выстраивать процессы и строить отделы. Проводить высокоуровневые эстимации производства на несколько лет вперёд. Оставаться в курсе всех важных событий и прозрачно осведомлять о своей работе коллег. Просто для этого нужен строго определённый набор навыков и практического опыта. Больше скажу: лично у меня полное сосредоточение достигается в полной тишине. Поставить музыку фоном может работать, но только если у меня осталась механическая работа, не требующая интеллектуальной вовлечённости. Что-то, что я могу делать на автомате. Как вы понимаете, в офисе я был просто зверем на этой почве. А если меня оторвали от задачи, не договорившись о времени, так вообще — пиши пропало. Но потом я задумался: "А может есть способ как-то проще объяснить свою позицию на универсальном языке денег?" И, знаете, кажется есть. Возьмём за среднее время поездки до места работы — 1 час. В день получается 2 часа. В неделю — 10 часов. В месяц — от 40 часов, то есть полная рабочая неделя. В которую вы не приносите пользу ни себе, ни работодателю, да ещё и денег за это не получаете. Так что если кто-то не будет понимать моих изначальных аргументов, теперь просто буду раскладывать эту математику и спрашивать, готовы ли они оплачивать эту дополнительную неделю, в которую я никому не приношу пользу, болтаясь в транспорте. #SoftSkills

T-shaped снова в моде? Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных. В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов. Пару мыслей про это от меня и других ребят, с которыми мы кулуарно общались. Во-первых сама тенденция возврата к фулстек режиму, во многом определяется не тем что у нас появился ИИ, а тем что идет общий экономический спад и компании сжимаются. А в таких случаях обязанности перераспределяются среди оставшихся. И наоборот, когда все активно развивается, происходит дробление. Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей. Во-вторых, есть серьезные опасения, что сильных спецов в принципе всегда было мало, а тут мы как будто бы хотим лучших их лучших. Откуда их брать? И насколько людей действительно хватит? Мы не можем бесконечно масштабироваться, ИИ очень быстро уперся в ограничения кожанных. А комфотная работа для многих превратилась в изматывающий марафон на скорости стометровки. Telegram | YouTube | AI Клуб

Как запустить новый продукт — и не разругаться, когда стратегия начинает ломаться Кейс «Авито Премиум» Продолжаем разбирать, как продукту и бизнесу работать на равных, — уже на примере запуска нового продукта. В «Авито» была стратегическая задача: стать лидером премиум-ресейл-сегмента и привлечь новую аудиторию в фешен-категорию. Но бизнес и продукт изначально смотрели на реализацию по-разному: ➡️ Бизнес видел точку роста в профессиональных продавцах — бутиках и ресейл-магазинах люксовых брендов. Логика была понятной: у таких продавцов уже проверенный ассортимент, и не придется масштабно вкладываться в проверку подлинности товаров. ➡️ Продуктовая команда пошла исследовать поведение пользователей — и увидела, что основной запрос — возможность безопасно покупать оригинальные вещи массового премиум-сегмента: Adidas, Michael Kors и других брендов, где особенно много реплик. Из этого сформировалась гипотеза, что пользователям нужны: — проверка на подлинность; — отдельное пространство с проверенными товарами. А еще на старте казалось, что основу ассортимента составят профессиональные продавцы. Но в ходе запуска выяснилось, что пользователи намного активнее реагируют на предложения частных продавцов. И тогда исходная стратегия начала меняться. Потому что вместе с ростом частного ассортимента вырос и объем проверок. А модель, в которой проверка оплачивалась платформой, перестала сходиться по экономике. Командам пришлось быстро перестраивать подход: ➡️ пересматривать позиционирование; ➡️ менять финансовую модель; ➡️ аккуратно тестировать платную проверку; ➡️ искать баланс между экономикой, ассортиментом и пользовательским опытом. При этом продукт и бизнес не начали тянуть систему в разные стороны: — бизнес — в сторону прибыли, — продукт — в сторону пользовательского опыта. Команды заранее договорились об общей целевой метрике — GMV (общий объем продаж), но разделили зоны влияния: 🔵 Бизнес отвечал за ассортимент и средний чек. 🔵 Продукт — за конверсии внутри воронки проверки и организацию премиального пространства. Помогло и то, что работа была синхронизирована не только на уровне метрик — она включала: — регулярные встречи; — совместные продуктовые разборы; — общие ассортиментные стратегии; — единые годовые цели; — прозрачные каналы коммуникации. А еще — совместное погружение в контекст: команды вместе запускали премиальный пункт выдачи на Патриарших прудах, общались с продавцами, собирали обратную связь и сами проходили операционные сценарии пользователей. В итоге запуск показал, что налаженная совместная работа продукта и бизнеса позволяет вовремя отследить важные сигналы рынка и пересобрать стратегию под его запросы. Чек-лист Что помогает продукту и бизнесу не развалиться, когда стратегия меняется уже после запуска: 1️⃣ Договориться о единых терминах. Чтобы продуктовые процессы не звучали для бизнеса как «птичий язык». 2️⃣ Связать продуктовые метрики с бизнес-целями Чтобы команда могла объяснять влияние продукта на языке бизнеса. 3️⃣ Провести взаимный онбординг: — продукта в бизнес; — бизнеса в продукт. 4️⃣ Обсудить стратегию развития продукта заранее: — видение бизнеса; — драйверы и барьеры продукта; — допустимые компромиссы; — систему метрик. 5️⃣ Зафиксировать зоны ответственности: — кто принимает решения; — где границы бизнеса; — где границы продукта; — кто подключается в спорных ситуациях. 6️⃣ Планировать не только дорожную карту, но и критерии гибкости. Что команда будет делать, если рынок или экономика покажут другую картину? 7️⃣ Регулярно погружаться в контекст друг друга: — совместные интервью; — просмотр пользовательских сценариев; — участие в операционных процессах; — тестирование продукта своими руками. Потому что в реальности почти ни один запуск не идет ровно по первоначальному плану. По мотивам доклада «Продукт и бизнес на равных: как договариваться и влиять на деньги, приоритеты и общие цели» Алены Медведевой на конференции ProductSense’25. 💙 VK 🖤 YouTube @productsense

От подписчика: Отчет Faros.ai про реальные цифры продуктивности разработки с ИИ. Ну... Не все так однозначно... Это реальные метрики кода от требований до доставки. Выборка – 4000 команд за 2 года, сравнение внутри одних и тех же компаний между кварталом минимального и максимального использования AI. Главные цифры: – Продуктивность отдельного разработчика выросла, но скромно, судя по merge requests. Примерно +16 процентов, а не 10x – При этом скорость доставки релизов упала на 11 процентов. Это системная метрика, она про доставку ценности клиенту – Поток замедлился на каждом шаге. Фича проходит каждый этап на 80–480 процентов дольше – Качество просело резко: дефекты вверх, переоткрытые тикеты вверх, code churn (доля переписанного кода) – аномальные 861 процент Узкое место сместилось в ревью. Стадии Ready for Review и In Review раздулись, а ревью стали пропускать на 31 процент чаще – классическое поведение людей на бутылочном горлышке. Сам Faros пишет прямо: организации генерируют больше кода, чем система способна отревьюить и смержить. Автор гоняет данные через закон Литтла (L = λW). Если лид-тайм и WIP растут быстрее, чем заявленная продуктивность – значит скорость потока на самом деле падает. По его расчётам реальная пропускная способность просела на 8–70 процентов в зависимости от допущений. То есть «продуктивность индивидуального разработчика» и «поток готовых фич» поехали в разные стороны, а платят клиенты именно за второе. Тойота в своё время победила американский автопром фанатичным фокусом на качестве и принципе «не передавай дефект на следующую станцию». Чем позже находишь баг, тем дороже он стоит системе. LLM делают ровно наоборот: впрыскивают больше дефектов на входе и переносят их отлов в ревью, где ловить дороже и хуже. Любопытная деталь: гипотеза «AI усиливает сильных» не подтвердилась. High-performing команды деградируют так же, как все остальные. Тут есть с чем спорить по методологии – это наблюдательное исследование, не причинно-следственное, и автор сам это признаёт. Но направление мне кажется честным и совпадает с тем, что многие из нас чувствуют на практике: индивидуальная скорость растёт, а на уровне организации профита не видно. Главная мысль, productivity не равно value. Локальный разгон одного этапа не двигает систему, если узкое место в другом месте. Если внедряешь AI в команду и не перестраиваешь ревью и QA под возросший объём генерации – ты просто переносишь бутылочное горлышко вниз по потоку и копишь work in progress. И отдельно зацепил тезис про «сначала черновик от LLM, потом доработаю». Автор считает, что это задом наперёд: первый черновик – это и есть твой интеллектуальный вклад, момент, когда ты реально продумываешь структуру. LLM сильна как редактор и спарринг после, а не вместо мышления. С этим скорее согласен - чем больше вложений на первых этапах, тем лучше результат. Короче, уделяйте МАКСИМАЛЬНОЕ внимание требованиям, а не пытайтесь зафигачить 100 фич и отдать все тестировщикам. Источник: https://unessays.substack.com/p/talk-is-cheap

Услышьте гениального интроверта ❤ Защита инициативы в компании часто происходит ярко, с презентацией и красноречивым спикером. Но что, если за всеми красками скрывается посредственная идея? Точно ли вы сможете это увидеть? Мы в Авито опасаемся таких ситуаций и поэтому на защите вместо спича и презентаций принимаем только 6-пейджер. Это шестистраничный текстовый документ, в котором по строгим правилам описана инициатива. Да, это скучно, зато работает гениально: структурирует логику, нивелирует харизму и позволяет сравнивать идеи объективно. 📌 Георгий Степанов из продуктового офиса Авито недушно рассказал о процессе в статье: читайте и берите в работу.

Ломка Раньше, когда я хотел запустить проект, в голове щёлкал один и тот же паттерн: кого нанять. Нужен проектный менеджер. Нужен человек на операционку. Нужен ещё кто-то под это. Любая новая задача начиналась с вопроса «какие люди мне нужны». Сейчас паттерн другой. Я думаю не «кого нанять», а «какие инструменты ИИ применить, чтобы это запустить или решить задачу». И специально не нанимаю, запретил себе это делать. Либо решу с ИИ, либо не буду решать вообще. «Закодировался» от найма, чтобы перестроить своё мышление. Ломка жуткая, но выхода другого нет. Звучит как мелочь возможно. Но это смена точки входа в процесс. Старый рефлекс добавлял к каждой идее людей, зарплаты, согласования, управление и отсутствие гибкости и скорости. Новый — добавляет связку инструментов, которую один человек собирает за вечер. И если не получилось — быстро выкинул, а при успешном старте быстро масштабировал. И знаете, что меняется в голове? Идеи перестают казаться дорогими и долгими. Раньше «а давай запустим вот это» автоматически означало «а давай наберём под это команду и найдём деньги». Теперь — «а давай я соберу это за вечер и завтра потестируем». ИИ сам по себе не делает предпринимателя богаче. Он просто позволяет одному сильному человеку создавать намного больше и ещё намного быстрее. Весь вопрос в том, какой рефлекс срабатывает у тебя первым. И хочешь ли ты перестроиться на новый.

Понедельник обычно небогат на новости, так что давненько я не брал в руки исследований. Вот одно очень флеймообразующее. В крупном турецком BPO-подразделении (клиентская поддержка телеком-оператора крупным аутсорсером) 248 полностью удалённых сотрудников случайным образом разделили на две группы: одни остались дома, другие выходили в офис один фиксированный день в месяц. Больше ничего не меняли — ни оплату, ни нагрузку, ни часы, ни технологию. Такая схема продолжалась девять месяцев плюс за командами наблюдали еще пять месяцев после окончания вмешательства. Что получилось: ▪️ Производительность +7,8% (звонков в час) в постэкспериментальный период. Прирост — за счёт сокращения длительности звонка на ~17 секунд, без потери качества обслуживания. ▪️ Текучесть упала на треть: 21% → 13,7%. ▪️ Коммуникация выросла: +36 минут общения с коллегами за неделю после офисного дня; случайные «соседи по столу» потом на 11 п.п. чаще продолжали общаться. ▪️ Отношение выгод к издержкам ≈ 5:1 (с учётом транспорта и питания за счёт компании). Интересная динами эффект не вспыхивает сразу, а накапливается со временем и сохраняется после того, как обязательные визиты прекратили. Это аргумент против объяснения через эффект Хоторна или временный подъём морали — личный контакт восстанавливает наставничество в реальном времени и обучение у коллег, и накопленный организационный капитал работает дальше. Жду комментариев "Так это саппорт, а настоящим программистам даже подходить к офису противопоказано" или "А я много лет работаю удаленно и ничего". https://www.nber.org/papers/w35331

#мнение Место менеджмента AI-native оргструктуре Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает: 1. Экономика AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения 2. Таланты и новые роли AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности 3. Структура команд Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца 4. Операционная модель Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже 5. Управление и контекст Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными 6. Проджект-функция Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь

Вы тоже заметили рост вакансий с AI? Например: - AI Native Marketing Head, Финансист - AI Product Manager, ВЛАДИС - РМ по внедрению AI-инструментов, МТС - Специалист по внедрению ИИ, АТЛАС - AI Product Manager, Моё дело и т.п. Ищут джунов, Моё дело спрашивает "что такое HITL" в тесте... Сбер ищет опыт с LangGraph.. Авито - опыт с RAG. Требования минимальны, экспертиза нанимающих менеджеров слабая. Т.е. меняются изнутри, локально внутри домена. Не сверху вниз. Поэтому сильные либо: а) идут работать в корпы (Гигачат / Алиса) б) работают на зарубежные компании в) тру строят Ai-native стартапы с фокусом на глобал (пример) Большинство знакомых из Яндекса, Авито и др. переориентировались на Tier-1 рынки. Что делать компаниям? Увы, нет другого способа привлечь на борт группу «ИИ сталкеров», которые могли бы инициировать ИИ-трансформацию, кроме как позволить им разбогатеть. Действуй как инвестор, оценивающий потенциал будущей капитализации, а не как менеджер, который изучает PnL. p.s. Еще один важный момент: позволь своим энтузиастам разрабатывать продукт каннибализирующий текущую прибыль. Иначе либо они уйдут и создадут аналог с Claude Code, либо конкурент.