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

Опыт в найме экономит годы Я часто слышу, что предпринимателю нужно как можно быстрее уходить из найма и начинать делать своё. Но у работы внутри чужой компании есть одна очень недооценённая ценность - ты можешь увидеть готовую систему до того, как тебе придётся строить её самому. Когда я запускал первый магазин, мне было проще, потому что я уже несколько лет работал продавцом и понимал, как магазин должен функционировать изнутри: как общаться с клиентом, как должны выглядеть процессы, где обычно возникают проблемы. Мне не нужно было придумывать всё с нуля, потому что часть этой системы я уже видел в работе. А дальше хорошо видно обратную сторону. Когда у нас появился офис, несколько магазинов и более сложные процессы, начались задачи, с которыми я раньше просто не сталкивался. Например, я никогда не работал в компании, где нужно было управлять товародвижением между пятью магазинами. Поэтому сейчас часть таких процессов мы вынуждены выстраивать и перестраивать уже на собственных ошибках. Если вы заранее видели, как работает сильная система, вы хотя бы понимаете, к чему стремиться. Как должен быть устроен отдел, как взаимодействуют люди, какие процессы нужно заложить ещё до того, как компания вырастет. Если этого опыта нет, многое приходится проходить самостоятельно - и обычно это стоит больше времени и денег. Я бы не воспринимал работу в найме только как промежуточный этап перед бизнесом. Иногда это возможность за чужой счёт увидеть ошибки и решения, за которые потом в своей компании пришлось бы платить самому. Главное - не просто отработать несколько лет, а действительно смотреть, как устроена компания: почему процессы сделаны именно так, что работает хорошо, что не работает и что вы бы забрали с собой в собственный бизнес.

Когнитивная нагрузка Утро вечера мудренее! Когнитивная нагрузка — это объем информации, который человек должен обработать в момент времени или в течении дня.  Как мы уже говорили, неокортекс не может работать безгранично долго — ему необходимо отдыхать. Возможности людей по работе с информацией не бесконечны. Если когнитивная нагрузка будет превышать возможности людей — то вероятность правильных решений резко снижается. Не зря же говорят, что «утро вечера мудренее».  Как-то в одной из компаний я столкнулся с заявкой в ИТ от финансовой службы. Надо сделать так, чтобы инициатор, при заведении договора указал один 70 типов договора и один из 326 видов дохода.  К сожалению, мне не удалось проследить, что стало с этой заявкой дальше. Но такое количество вариантов — прямой путь к ошибкам. Чтобы правильно выбрать 1 договор из 70 и 1 вид дохода из 326 надо реально постараться. Либо сам процесс заполнения будет идти очень долго (а у операторов есть КПЭ), либо пойдут ошибки. #ЧФ #правила #когнитивная_нагрузка

Про бизнес без ключевых людей или как избавиться от зависимости Продолжаю читать книгу Майкла Гербера, «Малый бизнес: от иллюзий к успеху», в которой он по сути, предлагает строить бизнес так, как будто это прототип франшизы. Главная мысль - нужно работать не на бизнес, а над бизнесом. Те необходимо, чтобы каждый работающий процесс в бизнесе (по сути наши бестпрактики) был(и) описан(ы) так, чтобы его мог выполнить обычный сотрудник по инструкции. Таким образом нам не нужно будет все время искать выдающихся, чтобы демонстрировать выдающиеся результаты, достаточно просто хороших. Где-то это отражает идею о том, что команда вовсе не обязана состоять из звёзд, чтобы показывать крутые результаты. Ей достаточно опытного сильного тренера и хорошо слаженной динамики. Если есть описанные в любом формате - видео, аудио или на бумаге - бестпрактики, то и процесс адаптации и просева для нахождения правильного человека сокращаются до минимум, потому как, если не может сделать, как просим - то точно не наш. Возможно, именно это и есть ответ на вопрос, как сократить зависимость от тех самых двух-трёх ключевых людей. Правда, здесь вопрос скорее про менеджмент, чем про специалистов, которые работают руками. По специалистам идеи немного другие.

Как я работаю с агентами Каждый мажорный релиз модели (в данном случае Astra и Opus 5.5) меняет возможности моделей, но главный эффект - это меняет КАК и КАКАЯ работа может быть сделана с помощью ИИ. Помните, на заре этого рынка была такая профессия как промт-инженер. Сегодня, очевидно, это не просто бесполезная, а вредная история (есть пейперы которые доказывают что скилы и длинные промты делают результат ощутимо хуже). Потом были всякие контекст инженеры, RAG-монтажеры и n8n-ниндзя. Не сказать, что это прям активно вредно, но для 99% задач никакой пользы это не дает. Выясняется, что модель из коробки решает эти задачи лучше чем накостыленный софт. Сегодня эра мультиагентов, динных сессий, но все еще без continual learning (апдейта весов модели/лоры в процессе работы), нативной коммуникации агентов (градиентами и весами), и это все придет в ближайшие год-два. Прямо сейчас почти любая сессия, которую я запускаю - это: - оркестратор оркестраторов, то есть есть менеджер с которым я общаюсь, у него есть субагенты на отдельные куски проекта (например, разные сделки, разные типы работы, разные части продукта или исследования). на скрине - одна сессия, которая создает субсессии, которые сами создают субсессии и все между собой общаются. я в чужие чатики не лезу, у меня есть ответственный менеджер. - я не читаю чат агентов, только чат с оркестратором. у типичной задачи 20-40 субагентов, они работают от пары до 40-50 часов на задачу, читать весь этот слоп так же бесполезно как читать код для меня - мне важен результат - моя работа это выставить правильные гейты Вкуса, то есть договориться с агентом на каком этапе он мне показывает результат, собирает с меня фидбек и направления дальнейшей работы. без этого сессия на 60 часов уйдет в неправильное направление после первого шага и вы потратите недельный лимит на слоп - половина работы агентов - автоматизации. каждый день это полтора десятка автоматически запускаемых задач: ревью всех новых сделок и заявок, ответы в почте и тг, анализ трафика и кампаний, подготовка целей на день и неделю, трекинг проектов, читалка важных новостей по рынкам и т.д. Мораль: то, чем является работа и как меняются бизнес-процессы зависит от текущего состояния моделей. Именно в этом и есть ИИ-нейтивизация, а не в том чтобы натянуть РАГ на Слак.

Крупные партнёры не подстраиваются под ваш темп. Они, как правило, диктуют условия, и вы либо вписываетесь, либо нет. У меня в карьере есть кейс, когда мы за месяц масштабировали ивенты с 40 в нескольких городах до 450+ по всей России. Это был детский фотопроект: ребёнку собирают образ от стилиста, визажиста и парикмахера и красиво фотографируют. Чтобы масштабироваться кратно, нам нужен был ритейл-партнёр со своими площадками. Договорились с Gloria Jeans. И ахерели, мягко говоря 🔺 Где основная сложность. Партнёр согласился работать при условии, что через месяц съёмки начнутся во всех 600 магазинах бренда в РФ. А у нас микрокоманда и немного подрядчиков в городах на местах. 🔺 Что делали. Стали думать про процесс, который нужно повторить 600 раз: люди, стандарты, регламент, контроль. Из продукта и коммерческих процессов выкинули всё, что нельзя стандартизировать.

Выручка проекта выросла в 20 раз за полгода, вместе с сопоставимым ростом прибыли

Рост дало не партнёрство само по себе, а перестройка всего под федеральный масштаб за четыре недели. Под капотом привлечение и обработка лидов, поиск визажистов, стилистов и фотографов, контроль качества, и это только самые очевидные 10%. Вспоминаю и не верю, как мы это сделали: в мае 1 600 клиентов, в середине июля 20 000🫣

С тех пор я сильно верю, что вписаться в амбициозную авантюру уже половина успеха. Дальше как ни крути разберётесь.

Большой масштаб это не столько про продукт, сколько про людей, процессы и системы которые нужно наладить вокруг

Задумывались, почему одни компании ПОЛЕЗНО внедрили ИИ-агентов, а другие накупили сотрудникам подписок, запустили кучу пилотов и... всё? В чём разница? ИМХО, это ключевой вопрос, чтобы ИИ-трансформация вообще запустилась (без ответа на него всё остальное будет вхолостую стрелять). И у меня есть подсказка: причина ровно та же, по которой ИИ так хорошо делает код. Именно код, а не презентации, отчёты или посты на Дизраптор (их он вообще не пишет - говорит "не могу осилить, не мой уровень"). Меткая мысль на эту тему попалась в колонке Дмитрия Ушанова, директора ИИ-центра Т-банка. Если кратко, то агенты быстрее заходят туда, где результат можно ТОЧНО проверить относительно малой кровью, а цена ошибки при этом, ну, приемлемая. Эта мысль кажется базой-основой, но если её развернуть, то есть важный нюанс, смотрите: Обычно успех эйай в разработке объясняют так: "Код = сплошь текст, а LLM в тексте хороши". Но договор - это тоже текст. Как и коммерческое предложение. И много что ещё. Однако, агентов-юристов в проде почти не видно. Но зато агентов-разрабов пруд-пруди. Прикол в том, что у кода есть бесплатный "проверяющий": компиляторы, тесты, флаги "запустилось / упало" и т.д. Агент написал фигню → среда сразу дала ему по щам → агент переписал. Нужно всего три итерации, а человек в этой цепочке в общем-то не прям нужен (на практике пока скорее нужен, но всё идёт к тому, что ключевое слово "пока"). А вот с ошибкой в договоре так не получится - она всплывёт через полгода в суде, ошибка в закупке - при отгрузке через квартал. И проблемы будут совсем другого уровня. Получается, главное узкое горлышко в реальном внедрении - не интеллект модели (с ним всё уже более-менее гуд, при чём у всех LLM), а цена верификации. Проще говоря, насколько дёшево и сердито можно проверить, что агент не накосячил. И тут бизнес делает логичный манёвр: "раз проверять некому - поставим человека". Это называется human-in-the-loop (HILT), "человек в контуре". Агент делает - кожаный перепроверяет и жмёт "ок". Но прикол в том, что это только кажется разумным компромиссом, а по факту самый дорогой режим из возможных: вы платите и за токены, и за человека, а человек ещё и тупеет, потому что 95% времени просто кликает "ок" (примерно как чувак, который сидит за рулём беспилотного такси на тестовых прогонах). Ушанов так и пишет: если модель плюс контроль стоят дороже процесса без ИИ, то оно вообще зачем? Это напоминает "зловещую долину" у роботов: полностью ручной процесс - окей, полностью автономный - тоже окей, а посередине какая-то стрёмная фигня. Отсюда и ответ на вопрос из заголовка: Компании, которые добротно внедрили агентов, сначала перепилили процесс так, чтобы у него появился свой "компилятор": формальные критерии, проверяемый результат, и нативный (то бишь, по дефолту предполагаемый) контроль на стыках между шагами. Разработчики получили это бесплатно от природы, а всем остальным придётся "поработать напильником". Так что, если ваш агент второй год живёт в статусе пилота - скорее всего, вашему процессу просто нечем проверить, что агент всё делает правильно, не врёт и не краснеет косячит. Дизраптор

Внедрение через насилие В маленьких системах (агентствах, компаниях, командах) внедрение в работу новых инструментов - это вопрос воли фаундера или просто ответственного. Выглядит примерно так: нас тут в команде пятеро, у нас хватает свободного времени, решили, что нам нужна аи-кластеризация, накидали пайплайн, используем, все довольны. Чем старше я становлюсь и чем больше людей у нас работает, тем отчетливее я понимаю, что даже на такой сравнительно небольшой системе как у нас (около 100 человек), политическая воля меня как основателя работает чем дальше, тем хуже. Поясню на простом примере. Уровень давления 0: 2-3 года назад степень развития ИИ становится достаточным, чтобы внедрять его в сеошную рутину: кластеризация, очистка ключей и так далее. Мы это обсуждаем в команде, но все ответственные внутри, кому целесообразно этим заниматься, завалены работой по уши. Такой работой, за которую уже заплачены клиентские деньги. Брать человека под это со стороны вроде бы неэффективно. Поэтому ничего не происходит, я время от времени ною в командном чате, но мне говорят: ты что, хочешь чтобы мы просрали сроки вот тут или вот тут ради этого ресерча? Уровень давления 1: года с полтора назад мы просрали крупный тендер, потому что у нас не было готовых ИИ инструментов для обработки больших массивов семанта. Это уже был сильный звоночек, это были серьезные деньги и мы начали что то делать. Что-то по итогу было сырое и не очень готовое, но все уже поняли, что просранный тендер сегодня - это без работы завтра. Уровень давления 2: спустя еще некоторое время, мы, хоть и с сырыми инструментами, выиграли другой крупный тендер на обработку семантики, и вопрос встал ребром: либо мы обосремся на подписанном договоре, либо разработка и семантика в сжатые сроки доделают процесс до идеала. При этом, когда мы в тендер заходили, я понимал что инструмент у нас еще сыроватый, но я также понимал и то, что выиграть тендер - это единственный способ быстро доделать инструментарий; необходимо создать сильное внешнее давление на ответственных, помимо моих увещеваний. По итогу, конечно, доделали вовремя, сейчас работает хорошо, будем улучшать еще, клиент, как минимум, доволен. Другой пример на сильно большем масштабе: кто то ответственный наверху понимает, что пора бы уже заранее ставить сетки поверх бочек с нефтью. Но от ответственного до конкретного собственника конкретной бочки - огромное расстояние, прямого воздействия нет. И пока часть бочек не сгорят, сетки никто ставить не начнет. В чем тут мораль по итогу? Если какие то ваши инициативы и внедрения протухают по дороге, подумайте не о том, чтобы топать ногами на подчиненных, а о том, чтобы создать внешний стимул, угрожающий той модели жизни/работы, в которой подчиненные привыкли работать.

Когда команде разработки готовят некую новую задачу, функцию продукта, это надо сначала понять и описать. Есть такой подход для командной работы - Event Storming. Это шумное сборище интенсивный воркшоп для исследования сложных бизнес-доменов. Помогает создать единое понимание бизнеса у разработчиков, аналитиков и заказчиков. По классике это происходит на большой стене с помощью стикеров. Команда выстраивает цепочки бизнес-процессов во времени (слева направо). Стикеры могут быть такие: 🟧 События (Domain Events) — факты, которые уже произошли (глагол в прошедшем времени). 🟦 Команды (Commands) — действия, запускающие события. 🟪 Агрегаты/Системы — то, что выполняет команду. 🟨 Акторы — люди или внешние системы, инициирующие действия. Пример из жизни: заказ такси. Процесс поулчается такой: 🟨 Пассажир нажимает кнопку в приложении. 🟦 Команда: «Создать заказ». 🟪 Сервис заказов принимает её. 🟧 Событие: «Заказ создан». 🟦 Команда: «Назначить водителя». 🟧 Событие: «Водитель назначен». 🟧 Событие: «Поездка завершена». Зачем это нужно? 🔹 Единый язык: cтирает границы между бизнесом и IT. Все говорят на языке домена. 🔹 Поиск дыр: cразу видны пробелы в логике, дублирование функционала и узкие места. 🔹 Фундамент для DDD: легче начать проектирование микросервисов и Domain-Driven Design. Подробненько всё расписано тут и тут. #process

AI для корпораций OpenAI выпустил инструкцию руководителям – как внедрять агентов. Написано на очень “корпоративном”, я старался облегчить как мог, но всё же не добалвлял отсебятины. ------ – Выбрать одну и только одну задачу. Критерии – процесс, в котором сходятся стратегический приоритет, системы, передачи работы между людьми, контроль и измеримый результат. Он должен повторяться достаточно часто, чтобы на нём было чему учиться, и быть достаточно важным, чтобы его стоило перекраивать. – Сформулировать результат и способ его измерения до старта. Назначить ответственного владельца, KPI, базовый уровень и ограничители. Отдельно мерить глубину – сколько задач доведено до конца, сколько подключено контекста и инструментов, сколько вылезает исключений, какая нагрузка на ревью, – и отдельно ценность: время цикла, качество, стоимость, выручку, риск. Объём выдачи говорит лишь, что у AI стали больше просить, а есть ли в этом толк, показывают результаты процесса. – Написать агенту должностную инструкцию. Что запускает работу, каким должен быть результат, какой нужен контекст, какие инструменты и права доступа, насколько настойчиво добиваться завершения. Какие доказательства своей работы агент обязан предъявить, и в какой точке обязан остановиться и позвать человека. – Построить вокруг агента человеческую систему. В контур проектирования посадить тех, кто ближе всего к процессу, и явно назначить, кто отвечает за бизнес-результат, кто за доменную логику, кто за доступы и контроль, кто за внедрение и повседневное использование. – Сделать эксперименты видимыми и переиспользуемыми. Через полгода после внедрения сотрудники в начале карьеры пишут AI на 13 сообщений в неделю больше, чем руководители – пробуют в основном снизу. Значит, надо дать людям место пробовать, а удачное забирать наверх: фиксировать процесс и доказательства того, что сработало, и упаковывать в скиллы, плагины, общие рабочие пространства. Режимы разные под разные задачи: Chat – вопросы и быстрое обсуждение, Work – многошаговая работа с готовым результатом на выходе, Codex – техническое исполнение. – Переносить схему дальше. Сохранять не сам результат, а обвязку вокруг него – контекст, права доступа, оценки, точки проверки, владельцев, метрики, обучение людей, – и прикладывать к следующему процессу. Каждый следующий эксперимент должен начинаться с лучшей стартовой точки, чем предыдущий. -------- 5 из 6 пунктов, кажется, универсальны и относятся к любым изменениям, не только внедрению AI. Что, впрочем, совершенно логично. https://openai.com/index/ai-native-company-workflows/

База про автоматизацию 😀 У меня как-то в доковидные времена была неделя, когда я просидела 2 ночи, чтобы разнести звонки по карточкам сделок. Я это помню настолько четко, особенно потому что сейчас это кажется страшным сном)) С того дня я периодически возвращалась к вопросу автоматизации, посредством всяких дурацких костылей. Но то, на какой уровень автоматизация вышла сейчас, поражает В связи с этим решила написать про то, что важно учитывать, вписываясь в автоматизацию Вот к чему я пришла: ✖️Автоматизировать нужно рутину, а не решения То есть, на мой взгляд, лучше не передавать принятие решений ИИ-шке, потому что люди забывают, как думать)) Скорее автоматизировать стоит ручной труд типа постмитов, статусов и отчетов ✖️Без порядка в данных автоматика удобряет бардак У нас были задвоенные карточки одного контакта и сценарий умудрился отправить с них два разных предложения по цене. Клиент, конечно, заметил и просто спросил, с кем из нас ему теперь разговаривать. Короче, сначала - порядок, потом - все остальное)) ✖️Там, где есть риск, должен остаться человек Все что находится в зоне потенциальной вероятности потери клиента нужно оставлять на ответственности человека Это важно, потому что, какая бы крутая автоматизация ни была, она долгое время требует трепетного контроля В общем, всем желаю, чтоб все шло как по маслу в автоматизации!

Главный организационный вопрос внедрения AI Уже не первый год мы все спорим про влияние AI на бизнес-процессы, делимся кейсами, меримся автоматизациями, количествами созданных агентов и сожжённых токенов. Но все эти вопросы мне кажутся вторичными по отношению к более глубокому, который почему-то задают реже: а какая работа и какие люди нам вообще теперь нужны в организации? Это не обязательно вопрос про увольнения - вопрос скорее про перераспределение задач, ролей и ответственности внутри организации. Если руководитель команды может за пару часов навайбкодить сервис и автоматизировать большой блок работы, какая часть работы действительно требует разработчика? Если маркетолог может провести аналитику данных самостоятельно, когда и зачем теперь звать аналитика? Если продакт может сам собрать прототип, провести несколько пользовательских тестов и разобрать результаты, в какой момент ему всё ещё нужен дизайнер или UX-исследователь? Мне кажется, работать с прежней оргструктурой и игнорировать все эти вопросы долго не получится: AI всё сильнее меняет не только отдельные процессы, а само разделение труда между ролями и функциями. А, значит, настоящая AI-трансформация начнётся, когда люди начнут открыто договариваться о своих зонах ответственности (а не проводить очередной цикл обучений): почему эта работа вообще существует, кто должен её выполнять, какие компетенции для неё теперь нужны и где должна проходить граница ответственности в организации. А это всё потенциально конфликтно, сложно и больно. Потому что обсуждать новые навайбкоженные инструменты гораздо проще, чем поднимать сложные вопросы, которые никакая языковая модель за организацию не решит.

Про процессы Раз в пару месяцев я обедаю с другом во Временах года Кто не знает, это такой молл на Кутузовском с дорогими брендами Так вот за последние несколько лет ни одного раза я не видела их туалеты в состоянии порядка Иногда это мелочи – сегодня был сломанный крючок для сумки, мусорная корзина со сломанным доводчиком и рассохшаяся рама у зеркала :) Иногда там грязно Для меня это большой показатель порядка в компании вообще Причем забавно, что количество посетителей здесь крайне небольшое. И все равно не получается следить? Так же в свое время я удивлялась планировке номеров в отеле Астория (люблю его всей душой, но) Захожу я с чемоданом, в верхней одежде. Деть ее некуда - нет крючков, вешалок. Мне надо пересечь всю прихожую и подойти к шкафу, открывая который я вижу халаты. В моем понимании, верхняя одежда не может перемешиваться с уличной На полу в прихожей нет ковра – осенний Санкт-Петербург бывает довольно грязным… Все это не сложно заметить, если управляющий отелем попробует зайти в номер не в офисной одежде, а как обычный постоялец Чем бы вы ни занимались, никогда не гнушайтесь пройти по своей компании «снизу вверх» Там обычно ворох идей лежит :) 🔗 Кружок кройки бытия

😁 Первые недели маркетолог нихрена не делает - это хороший маркетолог? Первые 2 недели в новой компании я вообще не маркетолог, я - врач изучающий медкарту пациента. Я открываю всё, что есть: рекламные кабинеты, воронки, отчеты, CRM, продажи, прошлые гипотезы, подрядчиков, цифры за последние месяцы. Мне нужно понять, что здесь вообще происходит: • Не «какой у нас CPL», а почему он такой. • Не «какая конверсия в продажу», а что происходит с человеком между заявкой и оплатой. • Не «этот канал работает», а за счет чего он работает и можно ли это повторить. Смотрю, что компания уже пробовала. Что давало результат. Что перестали делать, хотя оно работало. Куда уходит бюджет. Где воронка начинает сыпаться. Какие цифры вообще считают - и (мое любимое) можно ли им вообще доверять. И отдельно сверяю показатели с рынком. Иногда оказывается, что с маркетингом все в порядке, а деньги теряются на продажах или дырявой СRM. Иногда, что компания льет огромный бюджет в канал, который никогда не окупится. А иногда, что у компании давно уже все есть для успешного роста, просто оно существует кусками, а не складывается в единую систему. Поэтому я не люблю начинать с вопроса: «что делать?». Сначала ценнее другой: «что происходит с бизнесом прямо сейчас?». Вопрос к вам - через сколько дней после найма маркетолога ждете результат?)

Технология, продукт и компания это разные вещи, хотя я не сразу это поняла. У нас долго был некрасивый фронтенд, и меня это совершенно не беспокоило, потому что за ним была вся сложная часть: CRM, инструменты аутрича, AI-сервисы и куча процессов, которые сначала нужно было просто заставить работать. Я была одержима именно этим, и на интерфейс сил почти не оставалось. Технология работала, продуктом это стало уже позже. Сейчас мы упёрлись в следующий уровень, и он оказался тяжелее обоих предыдущих, потому что здесь уже почти не про код и не про интерфейс. Клиент должен получать обещанное сегодня, а не «в среднем за квартал». Клиентов становится не три, а двадцать пять, и старые способы держать всё под контролем просто перестают работать. Качество не должно зависеть от одного конкретного человека, значит нужны процессы. А ещё нужны плейбуки под конкретных людей и ситуации, потому что одному клиенту важна одна формулировка в письме, а другому совершенно другая. И это не решается тем, что вы наняли ещё разработчиков, мне кажется, именно здесь и видно, кто по-настоящему построил компанию, а кто просто хорошо сделал продукт. В новую категорию зайдут десятки компаний, а лидерами станут единицы, и разница между ними и остальными почти никогда не в технологии, потому что на старте она у всех примерно одинаковая. Не знаю, окажемся ли мы среди лидеров, но точно понимаю, где сейчас основная работа: год назад мы учились делать технологию, потом учились превращать её в продукт, а сейчас учимся строить компанию. И кажется, что третий уровень по-настоящему никогда не заканчивается. А вы на каком уровне? Напишите в комментарии👇🏼

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense

Как AI-агенты трансформируют компанию? Недавно на воркшопе обсуждали следующий этап работы с AI в компаниях: переход от отдельных чат-ботов к агентам, встроенным в бизнес-процессы компании. Ключевой поинт - Corporate Brain. AI получает доступ к Slack, Jira, созвонам, документам, продуктовой аналитике и репозиториям и связывает разрозненный контекст в единую картину: обсуждение → решение → задача → изменение в продукте → влияние на метрики. На практике такой агент может за несколько минут разобрать backlog и найти связанные задачи и прошлые решения, собрать индивидуальный onboarding-план, сопоставить Jira с ClickHouse, GA, Amplitude и пользовательскими логами, проанализировать PR и коммиты, найти потенциальные проблемы в UX и подготовить гипотезы для команды. Но важный вывод воркшопа: ускорение отдельного сотрудника еще не означает ускорение компании. В одном из примеров AI значительно повысил скорость разработки, но очередь QA выросла с 15 до 55 задач, количество багов увеличилось в 4 раза, а rework - в 6. Поэтому измерять нужно не объем сгенерированного кода или количество AI-запросов, а конечный бизнес-результат. При этом агент нужен не везде. Если задачу надежнее решает обычная автоматизация, API или workflow, усложнять систему агентом нет смысла. Агент особенно полезен там, где нужно работать с большим контекстом, принимать неоднозначные решения, выбирать инструменты и корректировать следующие действия. Главная сложность тоже не в самой LLM. В production быстро появляются вопросы качества данных, доступов, legacy-интеграций, безопасности, стоимости, логирования и контроля действий. Поэтому рабочая схема выглядит примерно так: Goal → Context → Tools → Actions → Verification → Guardrails → Human escalation. И внедрять это лучше постепенно: найти первые реальные кейсы и мотивированных early adopters, измерить эффект и только потом масштабировать. Главная метрика здесь - не токены и не количество пользователей AI, а Cost per Successful Outcome: сколько компании стоит один действительно полезный результат. AI-трансформация - это не "заставить всех дрочить ChatGPT". Это перестроить конкретные бизнес-процессы вокруг новой возможности AI понимать корпоративный контекст, работать с инструментами и выполнять часть работы самостоятельно, но под контролем человека. https://youtu.be/vR_enpahg8M

Оценка мелких задач убивает ваше время Типовая ситуация: клиент постоянно присылает небольшие задачи и переживает, сколько времени займёт каждая. Команда начинает оценивать каждую задачу отдельно, согласовывать, потом объяснять, почему не попали в оценку. По факту оценка иногда занимает больше времени, чем сама работа. С маленькими задачами точность вообще плохо работает. Чтобы нормально оценить некоторые из них, задачу надо почти сделать. А если оценивать «на глаз», погрешность по каждой отдельной задаче будет большой. В итоге коммуникация с клиентом превращается не в работу, а в бесконечный цикл согласования бюджета и времени для мелких задач. Что с этим делать: отказаться от точной оценки мелких задач. Учитываем мелкие задачи постфактум. Сделали задачу, зафиксировали, сколько реально ушло. Чтобы клиент на это согласился, нужно немного изменить процесс: 1) Оценка остаётся, но она становится очень примерной: маленькая, средняя, большая задача. Менеджер проекта это может сделать без похода к разработчику. Клиент и Агентство соглашаются, что это грубая оценка. 2) Договориться о месячном лимите. Обычно поток таких задач укладывается в 10-20 часов в месяц. 3) При явном выходе задачи за лимиты или не попадании в оценку - заранее говорим об этом с клиентом. Большие, сложные и непонятные задачи нужно выносить отдельно и нормально оценивать. А поток маленьких задач лучше продавать почти оптом: грубо обозначать размер, следить за лимитом, заранее предупреждать о выходе за ожидания и оплачивать по фактически потраченным ресурсам. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Ваши бизнес-процессы всегда будут ломаться, и с этим ничего нельзя сделать 🔵Процессы — это то, как вы делаете повторяющиеся вещи: как передаёте клиента из продаж в производство, как исполняете обязательства, как держите свои стандарты. И вся эта конструкция нахер разваливается каждый раз, когда команда утраивается. Работало на 10 - отвалилось на 30. Работало на 30 - сломалось на 90. Это прям управленческое правило, и с ним, к сожалению, НИЧЕГО не сделать. Просто принимаем, плачем и переделываем процессы заново. В позитивном сценарии у вас к этому моменту уже есть наёмные руководители. Тогда всей этой свистопляской управляют они, а вы смотрите со стороны, как они всё разгребают)) Без руководителей это всё прилетит вам. А так вообще регламенты, чек-листы, оргструктуры и куча других скучных штук, которые душные дяди рисуют в учебниках по менеджменту, это реалии предпринимательства. Первые регламенты появляются ещё людях на десяти, дальше их становится больше и пишут их уже руководители. Но сама привычка и культура создавать процессы должна в компании завестись, и отвечают за неё тоже руководители. Как понять, что бизнес-процессы налажены: 🔵Заходите в чат, а там больше нет сообщений ''мы же это уже обсуждали'' 🔵Вас не дёргают одними и теми же тупыми вопросами 🔵Одна и та же услуга для всех клиентов делается одинаково (как в макдаке: куда ни приедешь, чизбургер везде примерно один и тот же) 🔵Новичок погружается за 2-3 недели вместо 3-4 месяцев: пришёл, прочитал обучалки, сделал по чек-листу, готов работать 🔵И главное, вы перестали тушить одни и те же пожары по кругу А если вы сейчас растёте, заложите время на переписывание процессов. Оно всё равно случится. Вопрос только, по плану или в аварийном режиме, когда всё уже горит...

AI убирает одну работу и тут же создаёт другую Сегодня обсуждали с коллегами любопытный парадокс. AI резко снизил порог входа во множество задач. Люди начали делать то, за что раньше даже не брались: разбирать финансы, копаться в своём здоровье, собирать мобильные приложения, автоматизировать процессы, работать с данными и документами. Раньше для этого надо было долго учиться, читать инструкции и набивать руку, а теперь можно быстро получить объяснение, пример, прототип и даже какое-то рабочее решение. Вот только доступность задачи ничего не говорит о глубине её решения. Современный AI часто напоминает университетского профессора, который прекрасно знает теорию, убедительно объясняет материал и щёлкает учебные примеры. Как только знания надо применить в реальной среде: с ограничениями, архитектурой, производительностью, исключениями и контекстом - начинаются проблемы. Модель легко напишет огромный объём текста, обработает массив данных самым неэффективным способом и предложит архитектуру, которая выглядит убедительно, но плохо живёт на практике. Скажем, большой набор данных разумнее один раз превратить в реляционную базу и дальше получать ответы короткими запросами на SQL или Python. Вместо этого ИИ раз за разом прогоняет через контекст тысячи строк, сжигая время и токены. Забавно, что длинные рассуждения и многократная обработка данных - ровно то, на чём зарабатывают поставщики LLM. Но интереснее другое следствие. AI породил огромный объём прототипов, полуготовых решений и новых инициатив, и люди начали встраивать их в бизнес-процессы, не всегда понимая архитектуру, программирование, безопасность и экономику продукта. Всё это теперь нужно проверять, исправлять, интегрировать, защищать и доводить до промышленного уровня. Дальше начинается цепная реакция. Юристы с помощью AI находят в договорах больше несоответствий, и другая сторона получает документ ещё сложнее, на проверку которого уходит ещё больше времени. Предприниматели быстрее собирают прототипы, но потом им нужны разработчики, архитекторы и консультанты, чтобы превратить это в надёжную систему. Компании видят новые возможности и тут же упираются в новые вопросы: где будет реальная экономия, как изменятся процессы, какие появятся риски и кто на самом деле получит прирост производительности. Пока что я вижу, что новой работы ИИ создаёт не меньше, чем убирает и её будет много. @maxvotek | linkedin | substack

Новое применение Claude Подождите! Не проматывайте на следующий канал. В этом посте не будет ни слова про вайб кодинг, который уже всем порядком надоел 😁 Я хочу вам рассказать про новый подход к разработке внутренних систем для оффлайн процессов. Кто когда-нибудь сталкивался с задачей создания системы, которой ежедневно будут пользоваться десятки людей с разными ролями, в разных локациях, с разным контекстом, тот знает насколько сложно продумать все сценарии и ограничить MVP теми функциям, без которых не обойтись. Именно такая задача стояла перед моей командой — система управления стоком мотоциклов для сети из десятков магазинов дилеров-партнеров, которая позволит оцифровать путь от добавления мотоцикла в продажу до его выдачи покупателю. Стадия развития продукта такая, что никакой автоматизации и синхронизации стоков с партнерами нет. У многих из них нет вообще никакой системы для управления своими стоками. Вместо того, чтобы проектировать сложную систему ролей и прав доступа, мы решили сделать 3 ключевых роли, переключиться на интерфейс которых может любой авторизованный пользователь системы. Грубо говоря это тот, кто управляет стоком всех магазинов, тот кто отвечает за актуальность стока определенного магазина или сети магазинов и тот, кто находится в магазине и отвечает за выдачу товара клиенту. В MVP заложили те действия, которые, как мы думаем, должен делать каждый из них. И главное. На каждое действие в системе добавили логи: какой пользователь, что сделал, с каким юнитом, когда и под какой ролью. И доступ админа, который может в удобном интерфейсе отфильтровать логи по всем параметрам и выгрузить их в CSV. Дальше начинается самое интересное, то что теперь доступно любому с подпиской на Claude Cowork. Нахожу в логах какую-то аномалию, например, продавец удалил юнит из системы вместо того, чтобы отметить его как выданный клиенту. Или менеджер стока удалил юнит и через минуту создал такой же с небольшими отличиями. Прошу Claude сделать анализ всех таких кейсов и получаю идеи для доработок — добавить обязательный выбор причины удаления и предупредить, что при продаже нужно использовать другую функцию. И добавить возможность редактировать определенные параметры у юнитов в доступном стоке для нужной роли. Наверное, к этим выводам мы бы пришли сами. После долгих разговоров с операционной командой, наблюдений за их работой и анализа метрик. Но с Claude это стало возможным после двух недель с момента внедрения системы, когда накопилось достаточно логов для анализа. Бонусом стало добавление интерфейса для анализа логов по юниту, который менеджеры операционной команды используют для «расследования» ошибок своих подчиненных и точеного проведения воспитательной работы 😁 Единственный минус — в этом месяце я дважды достиг лимита токенов, что стоило компании $400. Но, уверен, что польза от таких расходов инвестиций будет намного выше. Ведь каждое улучшение системы, сделанное по наводке AI, улучшает эффективность всего продукта и напрямую влияет на бизнес метрики! #lifehacks #aifuture #claude #salmon

Какая работа остаётся фаундеру, когда AI забирает всё больше задач В лекции о самоулучшающихся компаниях и как такую построить YC Partner Том Бломфилд отдельно рассказывает, какая роль остаётся человеку, когда AI становится всё умнее и может делать всё больше работы. Вот тезисы из выступления и ответ на вопрос: • AI теперь не просто про продуктивность. Он про то, чтобы держать весь контекст компании (переписки, данные о продажах, правила, код, инструкции и проч.) «на готове» и использовать их при принятии решений. • Так в компании информация перестаёт передаваться по иерархии (от начальника к исполнителю через менеджеров и наоборот), и это всё меняет — сотрудников нужно меньше, мидл-менеджмент не нужен, появляются новые роли (подробнее есть в лекции). • Том настаивает, что AI может делать работу сам и принимать решения сам. Пример: AI настроен регулярно анализировать воронку, вот он увидел в ней слабое место. Сам поресерчил и придумал, как это улучшить, сам запилил фичу, сам сделал A/B-тест, сам оценил результат, сам залил в финальный продукт. • И это те самые AI-loops, которые помогают сделать самоулучшающуюся компанию. • В такой схеме ценными становятся skills, «навыки» — описанные процессы, как бизнес делает что-то. Не софт, написанный под эти сценарии, а именно описание навыка, как этот процесс правильно выполнять. • И когда модель становится умнее → она просто переписывает код заново, а навык остаётся тем же (и эти навыки пока пишете именно вы, фаундеры). Софт эфемерен, навыки — фундамент. • У компании есть «мозг», который хранит все переписки, все скиллы, все данные — а люди сидят «вокруг», там, где нужно взаимодействовать с реальным миром. Люди — там, куда модели ещё не могут добраться. • Например, публичные выступления, этические вопросы, или моменты, где ставки слишком высоки или присутствуют эмоции. Что-то вроде разговора о расставании кофаундеров — то есть там, где нужно быть человеком, чтобы такое решить. • А ещё и продажи. Продажи следующие ≈20 лет по-прежнему будут строиться вокруг общения людей. • Заканчивает выступление Том вопросом: «Если бы вы запускали ваш бизнес сегодня, стали бы вы её делать в форме самоулучшающейся?». И сам на него отвечает намёком: «Вы только начинаете, у вас нет оправданий, чтобы строить как-то по-другому» Какие мысли? @y_everyday — рефлексируем об акселератор, создавший 100+ стартапов-единорогов

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