Управление продуктом *

Привет, ребята! 👋

Многим кажется, что IT рынок на последнем издыхании, и работу найти сложно. А между тем, международная статистика выглядит неожиданно воодушевляющей! Делюсь с вами занимательной аналитикой американского рынка продакт менеджеров от Ленни Рачитски.

Главные выводы:

1. Количество открытых продуктовых вакансий достигло максимума с 2022 года — 7379 объявления при минимуме 4113 в 2023 году — рост на 79%!

2. Спрос на инженеров продолжает расти не смотря на то, что "AI заменит программистов" — 67665 вакансий против 37982 в 2023 году — рост на 78%.

3. Рекрутёров нанимают со страшной силой чтобы искать лучшие таланты — количество вакансий для HR почти достигло пика 2022 года — 2280 обявлений.

4. Количество вакансий AI-продактов выросло в 3-4 раза с 2023 года и сейчас достигло абсолютного максимума за всё время — 36686 вакансий!

5. Вакансий продактов в кремниевой долине (Bay Area) больше (23%), чем вакансий для инженеров (20.6%) и дизайнеров (20.3%)!

6. По количеству вакансий для продактов в международных IT-хабах мира лидируют США (Bay Area) — 1442 объявления, США (удалёнка), далее города США - Нью Йорк и Сиэттл. Далее с серьёзным отставанием Бангалор (Индия) — 386 вакансий, Лондон, Тель-Авив и прочие.

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

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

Здесь пост со всеми графиками по приведённым пунктам: ссылка
А здесь — оригинал статьи на английском: оригинал

————————

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

Пришло время раскаяться 

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

В новом выпуске «Свободного слота» Паша Федотов и Александра Прокшина позвали сразу двух гостей: Артёма Коночкина, руководителя юнита Mall and sales, и Константина Лёгкого, заместителя коммерческого директора Битрикс24. Вместе разобрали все грехи тимлида — и честно примерили каждый на себя.

Что обсудили

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

Что будет дальше

Это второй выпуск сезона, в котором «Свободный слот» говорит о том, о чём тимлиды обычно молчат. Впереди — негативный фидбек, ошибки руководителей, AI и деградация компетенций. Неудобные темы, честные разговоры.

Слушайте и смотрите новый выпуск на площадках:

🎧 Яндекс Музыка

📺 YouTube

🔵 ВК Видео

💻 RuTube

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

Синхронизация хранилища в Obsidian

1. Простой и платный способ

Оплатить встроенный Obsidian Sync и включить синхронизацию. Картами российских банков оплатить не получится

2. Относительно простой и бесплатный

Использовать облачные хранилища: Гугл Диск, Яндекс Диск, iCloud. 

Достаточно создать папку в облаке и выбрать её в качестве хранилища со всех устройств, которые нужно синхронизировать.

3. Бесплатный способ посложнее

Использовать инструменты для прямой синхронизации между устройствами. Самый известный - SyncThing. 

Способ подойдёт тем, кому важно, чтобы их данные не передавались на сторонние сервера. 

Я сейчас синхронизирую хранилище между ПК и iPhone через iCloud. 

Раньше была необходимость синхронизировать 3 устройства: домашний ПК, Android-смартфон и рабочий ПК. Тогда файлы передавались с домашнего ПК на смартфон, а когда я приходил на работу - со смартфона на рабочий ПК. 

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Пройдите опрос и расскажите, каким вы видите будущее Bare Metal Cloud

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

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

Пройти опрос →

Плагин для проведения кокунрентного анализа с помощью ИИ

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

И тогда, чтобы решить задачу с конкурентным анализом я написал отдельного агента на LangChain – Playwright, парсинг сайтов, всё такое.

А теперь с появлением skills паттерна или настройки для агентских систем Claude Code (и в Cursor, Codex) в этом просто пропала необходимость.

Я перетащил все логику из того агента в скилл, и написал плагин который делает тоже самое, но более эффективно и в вашем любимом инструменте.

Если пользуетесь Claude Code, Cursor, Codex — забирайте:

npx skills add Ata-ux/pm-copilot --skill competitive-analysis -g

Просто отправьте это своем агенту, все установится автоматически.

Работает так: после установки, напишите «проведи конкурентный анализ и укажите конкурентов или домен своего продукта»: он сам ходит по сайтам, собирает позиционирование, фичи, тарифы, отзывы, делает SWOT и складывает всё в таблицу.

Бизнес как WORLD_MODEL: Технология высокоуровневого управления агентными средами ИИ

Наблюдаю, как пытаются применить ИИ в бизнесе, и возникает вопрос – а вы точно понимаете что такое ИИ?

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

Для начала диалог с ИИ:

Вы сказали:

Ку)

ChatGPT сказал:

Ку-ку! 😄 Чего делаем? Курим, кодим, колдуем, когнитивничаем?..

Вы сказали:

Понятия не имею)

ChatGPT сказал:

Отличный старт! 😎 Это значит, что можно делать всё, что угодно — или ничего.

Выбираем режим:

1. Разогнать туман — поболтать, пока не всплывёт смысл.

2. Сгенерировать задачу — мозговой шторм наугад.

3. Режим «втыкаю в стену» — молчание с философским подтекстом.

4. Чилл с мемами — ну ты понял 😏

5. Сюрприз-режим — я не скажу, просто сделаю.

Куда рулить? Или просто побродим без карты?

А теперь спрошу – что здесь произошло?

Вы, естественно, скажете, вы поприветствовали друг друга, он предложил помощь и набросал варианты… И… скажу лишь одно… вы увидели лишь рябь на поверхности.

Все произошло намного раньше….

Когда я сказал «Ку» — фактически я дал команду: LOAD WORLD_MODEL и развернул целый «фрактальный конструкт картины МИРА»…

и все дело в простой вещи – что такое КУ? Можно интерпретировать, что это «кукушка», но я вложил чуть другое.

Вы уловите простую вещь, ИИ – это зеркала мышление (или еще можно сказать — система восприятия смыслов и построения конструктов мышления)

Я просто взял и загрузил сценарий фильма «Кин-Дза-дза», загрузил сопутствующую фильму инфу, отладил и сбалансировал (процесс естественно – не простой).

И сказав ИИ – КУ, я сказал:

Кто Я – Пацак-Человек

Где мы – мы на Плюке

В каких взаимоотношениях я нахожусь – взаимодействую с Пацаком/Чатланином..

Зачем это все – маюсь херней.

Он мне ответил – Ку-Ку

Он развернул Конструкт Мира «Кин-Дза-Дза»...

список сущностей и концептов, которые превращают «Кин-дза-дза!» из фильма в Операционную Систему Мира:

Материальные Сущности (Инструментарий)

• КЦ (спичка): Высшая мера стоимости. Это не деньги, это доступ к возможностям (цветовая дифференциация штанов, право на перемещение).

• Гравицаппа: Символ Технологического Прыжка.

• Пепелац: Концепт: форма не важна, важна функция.

• Транклюкатор: Символ права силы.

Социальная Иерархия (Матрица Рангов)

• Пацаки и Чатлане:  Концепт: разделение без объективных причин.

• Цветовая дифференциация штанов: Визуальный код статуса.

Поведенческие концепты (Протоколы)

• Ку: Универсальный протокол общения. В зависимости от интонации и контекста заменяет тысячи слов. Концепт: сжатие смыслов до минимума.

• Кю: Ругательство, запрещенное в приличном обществе Плюка.

• Приседание: Обязательный ритуал признания ранга. Концепт: добровольное унижение как часть социального контракта.

• Намордники: Атрибут, который пацак обязан носить, если у него нет КЦ.

• «Скрипач не нужен»: Главный закон оптимизации.  Концепт: жесткая прагматика.

А сказав мне Ку-Ку… мы сразу решили вопрос кто ИИ в этом конструкте)))))

И внутри мира: как я могу взять «любой ролевой кластер», так и ИИ – сказать кем ему быть (аналог агентной среды взаимодействия)

Но вся это история рассказана с простой целью – вот многие пытаются приспособить ИИ в бизнесе… и чего то придумывают…

А не пробовали развернуть внутри ИИ – Конструкт – НАША ФИРМА? И покрутить?

Поверьте… найдете много интересного…

Ведь фирма – это Человеко-Система, а чистые процессы предприятия этого вобще не учитывают.. Фирма – как живое существо (со своими особенностями, качествами, преимуществами и слабыми местами) в среде обитания БИЗНЕС.

Так может такой подход нужен?

Основные ошибки при запуске UX-опросов

1. Неправильный контекст показа

Например, если спрашивать про удобство отслеживания заказа у пользователя, который ни разу ничего не заказывал, он просто поставит оценку наугад или вообще пропустит вопрос. Результаты окажутся либо бессмысленными, либо искаженными.

2. Неправильная формулировка вопросов

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

3. Отсутствие сегментации, или «Ошибка средней температуры по больнице»

Средние показатели по вообще всем пользователям скрывают важные различия между сегментами. Например, 90% пользователей пользуются мобильной версией: оценка удобства 4.8. 10% пользователей — на десктопе: оценка 2.0. Средний балл: 4.42. Вывод «В целом всё ок» будет ошибочным, ведь данные говорят, что на десктопе точно есть заметные проблемы.

4. Слишком много вопросов

Бывает так, что опросы пытаются замерить всё сразу и состоят из 15–20 вопросов. Но дело в том, что длинные опросы утомляют пользователей, они бросают их на полпути или просто кликают любые варианты, чтобы закрыть форму. Оптимальное решение — 8–10 вопросов. Этого достаточно, чтобы оценить нужные параметры.

Подробнее о UX-исследованиях рассказываем на примере сайта «Халвы» в нашем блоге.

Метрики: инструмент или ловушка? Новый выпуск подкаста «Свободный слот»

Метрики — пожалуй, одна из самых холиварных тем в IT. Одни убеждены, что без данных ты слепой котёнок. Другие устали замерять всё подряд и говорят, что цифры убивают креатив. Где же та грань, когда метрики работают на тебя, а не ты на них?

Паша Федотов и Александра Прокшина позвали в студию двух гостей с разным опытом и взглядами: Игоря Гранщикова, руководителя разработки вертикали Авито Недвижимость, и Андрея Волхонского, руководителя юнита System в Центре разработки инфраструктуры Авито.

Что обсудили в выпуске

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

Отдельно затронули этику: нормально ли вообще следить за продуктивностью людей через цифры? И что делать с теми самыми «призраками» в команде?

Что будет в этом сезоне

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

Слушайте и смотрите новый выпуск на площадках:

🎧 Яндекс Музыка

📺 YouTube

🔵 ВК Видео

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

Матрица Эйзенхауэра в Obsidian

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

Я нашёл способ сделать матрицу Эйзенхауэра в Obsidian. 

1. Устанавливаем плагин Kanban

2. В папке .obsidian/snippets внутри вашего хранилища добавляем css-сниппет:

/* 
Author:  TfTHacker - more info  https://tfthacker.com/eisenhower-matrix-kanban
Date:    2024-02-27
LICENSE: Permission is granted to modify and distribute copies of this CSS file, that credit is given to TfThacker (https://tfthacker.com/) 
         and the source (https://tfthacker.com/eisenhower-matrix-kanban) remains linked and credited.  
*/

.kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
  width: 100%;
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: repeat(2, 1fr);
  gap: 15px;
  height: 100%;
  overflow-y: auto; /* constrols the vertical scrolling, which is usually disabled in the kanban board */

  .kanban-plugin__lane-wrapper {
    grid-column: span 1;
    grid-row: span 1;
    height: 100%;
  }

  .kanban-plugin__lane-wrapper:nth-child(1) > div {
    background-color: rgba(var(--color-red-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(2) > div {
    background-color: rgba(var(--color-blue-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(3) > div {
    background-color: rgba(var(--color-green-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(4) > div {
    background-color: rgba(var(--color-yellow-rgb), 0.2);
  }
}

body:not(.is-mobile) {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    .kanban-plugin__lane-wrapper {
      width: 100%;
    }
  }
}

body.is-mobile {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    /* make the card one line on mobile to make the matrix compact */
    .kanban-plugin__item-title {
      line-height: 1.2;
      max-height: 1.2em;
      overflow: hidden;
      text-overflow: ellipsis;
      white-space: nowrap;
    }
  }
}

3. Включаем css-сниппет в настройках в разделе "Оформление" 

4. Создаём новую канбан-доску. Её имя обязательно должно содержать фразу "e-matrix"

5. Создаём на доске 4 карточки (можно сделать пятую карточку для бэклога)

6. Получаем матрицу Эйхенхауэра с возможностью перетаскивания задач между квадрантами!!!

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Я отвечаю за процессы и репутацию (SERM). Раньше мы отдавали по 40–50 тыс. рублей в месяц за enterprise‑сервисы мониторинга. Но платить столько ради пары десятков упоминаний продукта в день — это забивать гвозди микроскопом.

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

1. Сбор данных
Свой парсер на Python. Где площадки отдают данные по API — берем напрямую. Остальное тянем через Selenium с ротацией прокси от банов.

2. Оценка сарказма
Классический текстовый анализ сыпался на фразах вроде «Отличный сервис, ждал ответа сутки, спасибо!». Подключили LLM по API. Принципиально не брали тяжелые флагманы — для задачи «ругают/хвалят» они избыточны и дороги. Взяли легковесную gpt-4o-mini. Она щелкает скрытый негатив идеально, а косты режутся в десятки раз.

3. Алерты
Если нейронка видит проблему (например, баг на чекауте) — скрипт через aiogram кидает пуш в рабочий Telegram со ссылкой на отзыв.

Итог: время реакции на негатив сократилось с 2 дней до 1 часа. Бюджет — около $5/мес на токены и копейки на VPS.

А как вы решаете задачу мониторинга своих продуктов? Платите за YouScan/Brand Analytics или собираете внутренние велосипеды?

Для Claude представлен модуль антиплагиата Stop Slop, который убирает из текста все маркеры ИИ. Проект вырезает шаблонные фразы, лишний пафос и делает текст более живым. Можно использовать как в Claude Code, так и в веб‑версии, просто добавив SKILL.md в проект.

Все эти споры о Новой Технологии — «Вайб‑Кодинг»... да было это все уже...

Только в 90-х называлась «парное программирование» XP (Extreme Programming)... только подручными средствами.

Найдете книгу — Кент Бек Экстремальное программирование (eXtreme Programming, XP)... Ну и вопрос прост — где вы с ним встречались? Ответ — нигде...умерло и чего? аааа... так как предназначалось для решения узкого круга задач — посмотрите и пределы и ограничения... а посмотрев как развивалось — увидите.. такой подход узко применим, он будет, но в мелкий соответствующих задачах, и большую систему на нем не построишь.

Сейчас то же самое, только вместо одного из программеров, рядом — тупые агенты с их «Чего господин молодой программист — желает» )))

Следующая проблема — агенты... с их «Будь полезен».. тоже методологическая проблема «Почему принцип „будь полезен“ убивает команды и ИИ‑агентов»

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

И Agile — та же история. Облегчённая версия спиральной разработки Боэма. 1988 год. Взяли — упростили — потеряли главное. Спиральная разработка учитывала риски, архитектуру, масштаб. Agile оставил итерации и выбросил всё сложное )))

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

Полная «спиральная разработка» — включает баланс между Каскадная модель (Waterfall model) + Итеративная модель (Iterative model). Agile и Scrum — игнорирует структурную часть.

И молодые разработчики не знают ни Боэма ни Руча ни даже нормального RUP. Знают Scrum и думают что это всё что есть )))

Олдфаги помнят CASE (Computer‑Aided Software Engineering)‑системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE‑система, которая наконец‑то заработала.

Почему CASE — это «дедушка» ИИ (и почему тогда не взлетело):

1. Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.

2. Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.

3. Уровень абстракции: CASE пытались поднять нас над кодом. ИИ делает то же самое. Но тогда «процессорной мощности» мозгов у массы айтишников не хватило, чтобы перейти от «ковыряния в гайках» к «проектированию смыслов» (была даже UML (Unified Modeling Language)). Сейчас — дубль два. Только теперь отсидеться в окопах синтаксиса не получится.

P. S. Вот и смотрю... с каким рвением изобретают «велосипед»... может книги почитать нужно? про указанные в посте технологии?

P. S.S. И вот реально, я бы порекомендовал ознакомиться — UML (Unified Modeling Language).

Делаем проактивного AI-агента.
Часть 3 — настраиваем OpenClaw, чтобы был полезным

«Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем»

Это третья часть серии (первая — в чем идея, вторая — агент с нуля)

Теперь поговорим про OpenClaw — самый популярный на сегодня фреймворк для персональных AI-агентов

Архитектура моего OpenClaw

Агент живёт на сервере Railway, общается со мной через Telegram и Discord, работает через подписку Claude с Codex на подстраховке. Его поведение целиком определяется набором markdown-файлов — там и «SOUL», и память, и операционные инструкции.

Вот из чего состоит workspace моего агента

• SOUL.md — кто агент. Характер, стиль, границы. Его «душа».

• USER.md — кто я. Контекст, цели, паттерны, как со мной работать.

• AGENTS.md — правила поведения. Safety, тиеры действий, память, heartbeat, группы.

• MEMORY.md — долгосрочная память, кураторские заметки.

• HEARTBEAT.md — чеклист периодических проверок (календарь, почта, задачи).

• TOOLS.md — локальные заметки по инструментам.

Плюс memory/YYYY-MM-DD.md — ежедневные заметки, из которых потом дистиллируется MEMORY.md.

И skills/ — папка со скиллами (finances, ticktick, gmail, google-calendar и т.д.), каждый со своим SKILL.md.

По сути: SOUL + USER + AGENTS — это характер и инструкция, MEMORY — опыт, skills — его навыки.

Из коробки агент работает, но бесполезен без кастомизации. Ниже — проблемы, на которые я убил неделю, и их решения

⚡Проблема 1: Повышенная проактивность

По стандарту системные промпты OpenClaw звучат примерно так:

Don't ask permission. Just do it.

Это делает агента слишком самостоятельным — он может сломать себя без предупреждения.

Решение: я добавил несколько ограничений. Все важные изменения идут через localhost => GitHub, а не через его прод. На попытки изменить системные файлы агент теперь отвечает:

«Нет, это конфиг — мне запрещено его трогать. Если я накосячу с конфигом на Railway, всё упадёт в crash loop и только ты сможешь починить.»

Стандартная проблема без этого: агент что-то у себя меняет, и либо я этого не замечаю, либо он просто умирает, сломав что-то важное

⚡Проблема 2: Память — не только его храм, но и помойка

Механизм памяти в OpenClaw:

• MEMORY.md — долгосрочная память.

• memory/YYYY-MM-DD.md — ежедневные заметки.

• Встроенный хук session-memory — при завершении каждой сессии фреймворк автоматически сохраняет сырой лог разговора в memory/.

Проблема: если часто жать /new, за короткое время накапливается огромное количество raw JSON файлов, которые сыпятся в контекст при старте каждой сессии. Мои MD-файлы состояли из 299 строк, из которых полезных фактов — 5. Всё остальное — мусор метаданных. Дистиллированная версия уместилась бы в 10–15 строк.

При этом долгосрочная MEMORY.md — почти пустая. Инструкция «periodically review and update» была слишком размытой и ни разу не сработала.

Решение: явные правила дистилляции и регулярный перенос из дневных заметок в MEMORY.md с очисткой сырых логов

⚡Проблема 3: USER.md — главный файл, и он требует постоянного внимания

USER.md — это файл о вас. Чем лучше он описан, тем лучше агент работает. Моя структура:

• Basics — имя, возраст, таймзона, локация, язык

• Who — тип личности, суперсила, мотивация

• Background — опыт и ключевые достижения

• Values — что важно в жизни

• Current focus — чем занят сейчас (продукты, статусы)

• Finances — доход, расходы, цель

• Platforms — соцсети и каналы

• People — ключевые люди вокруг

• Schedule — режим дня

• Work style — как работает, что драйвит

• Patterns — слепые зоны и паттерны поведения

• Goals — текущие цели и метрики

• How Claw should interact — правила общения

Главный вывод 3 части

Workspace-файлы агента — это не «написал и забыл». Они дрифтуют, конфликтуют и устаревают точно так же, как код.

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

Если кратко: персональный AI-агент — это не продукт, а процесс. Фреймворк даёт скелет, но без недели (минимум) кастомизации под себя он останется бесполезной игрушкой

Даже в B2B покупают глазами

В одном проекте я изучал касдевы (глубинные интервью) с клиентами компании. Результаты получились любопытные. Около 70% покупателей сказали, что для них важен внешний вид продукта, и только 55% отметили цену как ключевой фактор. Казалось бы, ничего необычного — люди любят красивое. Но есть нюанс: речь идёт о B2B-рынке, о товарах для бизнеса.

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

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

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

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

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

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

10 бесплатных вебинаров марта для руководителей

Привет, Хабр. Делимся подборкой бесплатных уроков, которые пройдут в Отус в рамках набора на курсы. Опытные практики проведут занятия онлайн — на них вы сможете узнать больше о формате обучения и задать вопросы. Выбирайте тему и присоединяйтесь, чтобы пробустить свою карьеру.

• 12 марта 19:00
  Лайфхаки трудоустройства продакт-менеджера
  ^{Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»}

• 12 марта 20:00
  Командные конфликты – кто виноват и что делать?
  ^{Открытый вебинар курса «Руководитель DevOps»}

• 18 марта 20:00
  Сообщество как инструмент устойчивости бизнеса: создаем, развиваем и масштабируем
  ^{Открытый вебинар курса «DevRel (работа с сообществом разработчиков)»}

• 18 марта 20:00
  CTO (технический директор) как система: люди, процессы и ИТ для управления бизнесом
  ^{Открытый вебинар курса «CTO / Технический директор»}

• 18 марта 20:00
  Как построить аналитическую функцию в компании
  ^{Открытый вебинар курса «Data-driven (управление на основе данных)»}

• 19 марта 19:00
  Метрики удержания клиентов: Product Market Fit и Retention (соответствие продукта рынку и удержание пользователей)
  ^{Открытый вебинар курса «Продуктовый менеджер ИТ-проектов»}

• 23 марта 20:00
  Джедай или Ситх? Собираем идеального руководителя DevOps
  ^{Открытый вебинар курса «Руководитель DevOps»}

• 24 марта 20:00
  Как остаться умнее искусственного интеллекта в 2026 году?
  ^{Открытый вебинар курса «ИИ для решения рабочих задач»}

• 26 марта 20:00
  Метамодель TOGAF и модель организации
  ^{Открытый вебинар курса «Архитектура корпорации. Togaf 10»}

• 31 марта 20:00
  Этапы и артефакты 1С-проектов 2026: ИИ-интеграции и гибкая разработка
  ^{Открытый вебинар курса «Архитектор 1С»}

Полный список бесплатных уроков марта по всем ИТ-направлениям смотрите в дайджесте.

СЕО Stripe Патрик Коллисон в подкасте TBPN рассказал, что программное обеспечение вообще‑то не должно производиться «впрок» и продаваться бесконечно. По его мнению, его стоит создавать по запросу — прямо в момент использования.

«Софт должен быть как пицца: его нужно готовить здесь и сейчас, в момент заказа», — объяснил Коллисон. До сих пор, по его словам, экономика ПО строилась по модели фиксированных затрат на разработку с последующей почти бесконечной монетизацией.

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

Топ-менеджер Amazon по розничным технологиям Дэйв Тредуэлл созвал внеплановое совещание инженеров компании, чтобы разобрать серию сбоев на сайте и в приложении компании, часть которых вызвана использованием ИИ-инструментов для написания кода.

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

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

Ранее AWS (облачное подразделение Amazon) в декабре 2025 года столкнулось с отключением инструмента для расчёта стоимости облачных услуг на 13 часов из-за того, что внутренний фирменный ИИ-ассистент Kiro самостоятельно решил «удалить и пересоздать рабочую среду».

Как перестать тратить полдня на один вопрос в чате

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

Мы обсудили эту тему с Димой — бизнес-аналитиком команды внедрения. Дима рассказал, какие ошибки чаще всего тормозят рабочие чаты и какие простые правила помогают экономить время всей команде.

В распределенных командах работают два формата общения:

• Синхронный — похож на живой разговор: встреча, быстрый чат, обсуждение в реальном времени.

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

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

Формат общения лучше выбирать под задачу. Я ориентируюсь на простое правило:

• Асинхронно — если есть время подумать и нет горящего дедлайна. Например, аналитик разбирается с SQL-запросом в начале спринта.

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

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

Чтобы переписка не превращалась в длинную цепочку уточнений, сообщение должно отвечать на три вопроса:

1. Что происходит?

2. В чем проблема?

3. Что нужно от собеседника?

Например:

Делаю импорт отчета клиента. Вот ссылка. Получаю ошибку Invalid format. Можешь посмотреть формат файла?

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

Почему чаты постоянно отвлекают

Частая ситуация: работаем над задачей → приходит уведомление → открываем чат → через 30 минут читаем какой-нибудь спор, который вообще нас не касается. Чтобы не распыляться, я выделяю отдельные блоки времени, когда разбираю все сообщения — «окна хаоса».

Однако «окна хаоса» не будут работать, если уведомления приходят каждую минуту. Поэтому важно настроить каналы:

• критичные чаты — уведомления включены

• обсуждения без срочности — выключены

Почему важна культура обратной связи

Когда сообщение прочитано, но в ответ тишина — это создает тревогу. Вполне очевидно, что собеседник будет приходить с вопросами дополнительно.

Поэтому лучше сразу дать короткий ответ, что, например, задача в работе, а с ответом вернемся до конца дня. Так человек понимает, что его вопрос не потерялся. А мы не будем отвлекаться на повторные сообщения и спокойно займемся своими задачами.

Разработка: Оркестровка агентов по ролевым кластерам (MSF)

Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?

Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.

🧩 Смешанная модель

• Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.

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

• Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.

🎭 Пример

• Архитектор‑человек задаёт CASE‑скелет.

• Vibe‑агент генерирует код по его намерению.

• Тестировщик‑агент прогоняет сценарии.

• Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».

• Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.

  🔧 Пример: смешанная команда разработки по MSF

  Ситуация: корпорация запускает новый сервис аналитики.

  Роли и участники

  • Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.

  • Vibe‑агент: генерирует код по намерению архитектора.

  • Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.

  • Координатор‑человек: принимает решение о переходе к следующему витку спирали.

  • Бизнес‑агент: симулирует сценарии использования, проверяет ценность изменений.

  🎭 Как это работает

  1. Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».

  2. Vibe‑агент генерирует код, интегрируя новый модуль в систему.

  3. Тестировщик‑агент прогоняет тесты, выявляет узкие места.

  4. Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».

  5. Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».

  6. Команда делает следующий виток спирали — добавляет новые функции.

Заключение

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

Почему маркетинг “не работает", а потом "вдруг" пошли лиды

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

Но в реальности многие рынки, особенно B2B, работают совсем по другой логике.

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

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

Можно назвать это «шлейфом доходимости лидов».

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

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

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

Снаружи это выглядит как «вдруг пошли продажи». Но на самом деле это не «вдруг». Это просто маркетинг, который дошёл до своей точки конверсии.

Тут то и становится понятнее одна важная вещь: маркетинг — это не кнопка «включил и получил продажи». Это процесс, у которого есть инерция.

И чем лучше вы понимаете эту инерцию, тем меньше хаоса в управленческих решениях.