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

Прокрустово ложе

В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.

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

А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).

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

А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!

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

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

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

Дебаж 🐞с ноги 🦶

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

Продажи в найме и в своём деле — разные навыки. Я узнал это через несколько лет впустую.

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

А потом вышел в своё и не смог позвонить клиенту.

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

Я придумал механику и заложил её в Founder Mode — бот с тремя вопросами: приоритет недели, было ли движение, что остановило. Никакой методологии. Он делает то, что раньше делал работодатель: создаёт маленький внешний взгляд, перед которым неловко бездействовать.

Карточки выходят каждый день в Telegram. На Хабре — по понедельникам: итог недели и один приоритет, реальные сложности.

Теперь про продукт.

Я делаю перекус для тех, кто не успевает позавтракать. Не «полезный» как ярлык — конкретный состав: медленная глюкоза, жиры, клетчатка, полный аминокислотный профиль. Несколько итераций состава, несколько волн дегустаций — вкус 9,1/10.

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

Карточка этой недели — ниже. Это живой опыт, не кейс из прошлого.

Если вы сейлз, который думает о своём деле — скорее всего, узнаете здесь что-то своё.

ИИ для бизнес-аналитика

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

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

Мы поговорили с Полиной, бизнес-аналитиком в команде Скорозвон, и задали ей несколько вопросов: где ИИ полезен на практике, какие результаты удалось получить и какие инструменты стоит попробовать.

1️⃣ Где ИИ помогает в работе аналитика?

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

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

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

2️⃣ Где ИИ уже приносил заметный результат в вашей команде?

Один из ярких кейсов — анализ диалогов в колл-центре. Робот успешно находил «теплых» лидов, но конверсия в покупку оставалась низкой. 

Мы подключили анализ диалогов с помощью LLM и выяснили, что корректно работали только около 7% операторов.

Ошибки у них были довольно базовые, но их сложно заметить без детальной аналитики:

• не знали о звонках робота

• сбрасывали звонки клиентов или вызывали негатив

• повторно проводили идентификацию

• работали с плохим оборудованием

LLM помог быстро проанализировать большой объем диалогов и собрать это в понятную аналитику.

3️⃣ Что изменилось после этого?

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

А еще:

• итоговая конверсия увеличилась примерно в 1,5 раза

• выручка по проекту выросла в 2 раза

С точки зрения личной эффективности я теперь экономлю до 20 часов в месяц на прослушке диалогов и могу анализировать до 100 диалогов в час. 

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

4️⃣ Какие задачи еще можно отдать ИИ в работе аналитика?

Помимо анализа данных:

• подготовка презентаций 

• написание текстов

• проведение исследований

• сбор и структурирование данных

• оформление документации

Это не заменяет аналитика, но сильно упрощает старт и ускоряет процесс.

5️⃣ Какие инструменты тебе показались полезными?

Из того, что я использовала в работе:

1. GigaChat — хорошо справляется с исследованиями на российском рынке

2. SkyWork.ai и Gamma — помогают быстро собрать презентацию и структуру доклада

3. НейроЭксперт — удобно работать с файлами и базой знаний

4. Ассистенты для генерации промптов от Naumen — чтобы не просто перефразировать промпт, а уточнить задачу через вопросы и сделать его точнее

5. Кастомные агенты с использование Claude Code — чтобы автоматизировать процесс и сократить ручную работу

6️⃣ Есть ли риски или ограничения, о которых важно помнить?

Да, и об этом часто забывают. Перед использованием данных важно:

• уточнять у клиента, что является конфиденциальной информацией

• обезличивать данные

• проверять результаты

ИИ может сильно ускорить работу, но ответственность за итог все равно остается на аналитике.

Клиент + Продакт + Сервис = любовь QBR

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

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

1️⃣ Что такое Quarterly Business Review (QBR)

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

Формат больше похож на разговор, где клиенту уделяют внимание на уровне команды, а не одного менеджера.

2️⃣ Зачем вообще появился этот формат

Он вырос из конкретных проблем. 

1. Клиентский сервис чаще реагировал, чем инициировал диалог — клиент приходил сам, когда уже есть проблема.

2. Продукт общался с клиентами точечно — под конкретные задачи, без системности.

3. Клиенту не хватало понимания, влияет ли он вообще на продукт.

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

3️⃣ Почему не сработали Excel-таблицы

До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.

Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.

4️⃣ Что изменилось, когда позвали клиента в диалог

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

5️⃣ Как устроена встреча

Есть базовая структура:

• разбираем текущие вопросы и контекст по клиенту;

• обсуждаем, что происходит в бизнесе клиента;

• синхронизируемся по метрикам эффективности;

• собираем обратную связь и сложности в работе;

• рассказываем про обновления и планы продукта;

• фиксируем договоренности.

6️⃣ Что важно в ролях

1. Менеджер клиента — ведет встречу и держит контекст.

2. Руководитель сервиса — подключается к сложным вопросам.

3. Менеджер продукта — отвечает за продуктовую экспертизу.

Без полного состава встреча сильно теряет в качестве.

7️⃣ Что может пойти не так

• Встреча превращается в список «хотелок»

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

• Клиенту некомфортно отвечать на вопросы про бизнес

Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.

• Клиент приходит с негативом

Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде. 

• К следующей встрече нет изменений

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

8️⃣ QBR работает, если

1. Клиентский сервис и продукт готовятся к встрече вместе.

2. Разговор идет про бизнес клиента, а не только про продукт.

3. Подключены участники со стороны клиента на разных уровнях.

4. Договоренности фиксируются и превращаются в конкретные действия.

РБПО по ГОСТ Р 56939—2024: вебинар №05 из 30 – Управление недостатками и запросами на изменение программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.5. – "Управление недостатками и запросами на изменение программного обеспечения". Слайды.

Цели пятого процесса по ГОСТ Р 56939—2024:

5.5.1.1 Обеспечение управления недостатками ПО.

5.5.1.2 Обеспечение управления запросами на изменение ПО.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Представлен открытый проект AI Marketing Skills, который позволяет использовать Claude Code в качестве маркетингового агентства. Этот ИИ-навык поможет маркетологам, таргетологам, СММ-специалистам или контентщикам в десятки раз повысить свою эффективность.

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

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

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

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

Что обсудили

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

Слушайте и смотрите новый выпуск на площадках:
📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

Ещё больше новостей — в нашем телеграм-канале

«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

Почему ваш бизнес на SaaS‑решениях для СЭД уже мёртв

Я помню 2019 год. Мы сидели в душной переговорке, рисовали маршруты согласования на флипчарте и искренне верили, что несём цифровую революцию. Полгода внедрения, бюджет с шестью нулями. Ради чего? Чтобы бухгалтер Петровна перестала бегать с бумажкой и начала кликать в интерфейсе.

Сейчас мне смешно. И страшно. Потому что рынок СЭД на 100 млрд рублей идёт ко дну.

В чём проблема?

Все СЭД построены вокруг человека. Каждая кнопка, каждый маршрут рассчитаны на то, что живой сотрудник нажмёт, проверит, подпишет. Система - это просто электронный конвейер для перекладывания виртуальной бумажки. Раньше это работало. Потому что альтернативой была бумага.

Что изменилось?

Появились LLM и ИИ-агенты. Это не чат-боты, которые отвечают “ваше обращение зарегистрировано”. Это автономные программы, которые понимают задачу, сами строят маршрут, дёргают нужные API и следят за сроками.

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

Почему вендоры не нужны?

Функциональность СЭД идеально разбирается на атомарные кубики: документ, карточка, маршрут, контроль, оркестрация. ИИ-агенты играют в эти кубики лучше людей.

Представьте: вы говорите агенту “все договора свыше 100 тысяч идут к Петровой, если её нет - к Сидоровой”. Всё. Не надо ТЗ на 50 страниц. Не надо ждать релиз от вендора. Не надо платить за поддержку. Система сама адаптируется. Меняется оргструктура? Агенты перестроят цепочки автоматически.

Интеграции? Да хоть с пейджером бабушки

Раньше мы ждали годами, пока вендор выпустит коннектор к очередному мессенджеру. Теперь LLM пишет интеграцию “на лету”. Ей плевать на формат API. Через пять лет появится новый супер-мессенджер - агент адаптируется за час.

Я проверил. Это работает.

Пока писал этот текст, развернул три узла на OpenClaw (open-source). Без единой строчки кода. Просто описал задачу словами.

Через час система уже создавала заявления по письмам “хочу в отпуск”, гоняла их по маршруту, пинала тормозящих в Телеграм и складывала подписанные PDF в архив.

Что дальше?

Рынок СЭД на SaaS похож на пассажира “Титаника”, который пересчитывает драгоценности в каюте. Формально ещё на плаву. Клиенты платят по инерции.

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

Единственный шанс для вендоров: перестать продавать софт и стать инфраструктурой для ИИ-агентов. Но, судя по скорости поворота крупных кораблей, они не успеют.

Ну что, кто первый в комментарии расскажет мне про ГОСТы, ЭЦП и почему ИИ никогда не заменит живого юриста? Погнали.

Поймал себя на мысли, что последние пару лет я просто варю ИИ с помощью другого ИИ, наполняя первый знаниями, идеями и инструментами. И чем дальше, тем больше история смещается к наполнению идеями. Знает эта зараза уже побольше меня. Моё контекстное окно явно проигрывает, а поиск занимает больше времени. Пока её узкое место - неумение работать на земле. Мне повезло. Второй год занимаюсь маршрутизацией курьеров и просто цифровых следов в существующих системах недостаточно. Надо подмечать практики у лучших кожаных мешков и принуждать по ним работать худшие мешки. Например, эта зараза угадывает с точностью до минуты (MAE) когда курьер вручит следующий заказ курьеру. Это с лифтами, пробками, домофонами, погодой и прочими приключениями в пути. Без всяких карт. Просто предсказываает, а потом придумывает всё остальное. Самые крутые курьеры вручают 25% заказов за 3 минуты до окончания дедлайна и почти не опаздывают. Скоро она научится делать это в разы лучше. Опоздания она уже снижает кратно. Когда-то расчет маршрута был сложной задачей. Сейчас он занимает доли секунды даже на огромных объёмах при фантастическом качестве. Для этого недостаточно изучить алгоритмы и подходы, попробовав их сочетания. Пришлось скормить ей кучу нюансов бизнеса и договориться в каких случаях какие компромиссы по жадности возможны.
Я пытаюсь переосмыслить собственную ценность. Похоже, я больше не аналитик, не разработчик. Я просто тот парень, который катается на дарксторы и рассказывает ИИ как можно попытаться сделать бизнес ещё лучше. Затем проверяю взлетает или нет. Улучшаю бизнес через изменения в системах и процессах. И так уже почти 30 лет.

Дайджест мероприятий на апрель

16 апреля, 19:00 (Мск)

Технологическое предпринимательство для начинающих. Часть 1: от идеи к экономике проекта

Открытая онлайн-лекция о том, как технологии становятся бизнесом. Без стартап-магии — только реальные кейсы, ошибки и экономика проектов.

На встрече разберем:

● Чем техпред отличается от просто цифрового продукта

● Почему сильная технология — еще не успех

● Как говорить с инвесторами и смотреть на проекты через экономику

● Ошибки, которые ломают даже яркие стартапы

Кейсы: Under Armour, Theranos, YotaPhone, Ё-мобиль, On, CaseGuru.

🎤 Спикер: Антон Пчелинцев — магистр бизнес-информатики, соавтор курса «Экономика для технологических предпринимателей».

Формат: онлайн-лекция

Участие бесплатное. Регистрация по ссылкам: https://t.me/mipt_events_bot?start=dl-1775661093137

https://vk.com/app6379730_-224205661#l=9&auto=1

23 апреля, 19:00 (Мск)

Технологическое предпринимательство для начинающих. Часть 2: разбор кейсов и практика питчей

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

Разбор реальных кейсов, питчинг идей участников, ответы на вопросы. Можно не только послушать, но и представить свой проект или идею.

🎤 Спикер: Антон Пчелинцев — магистр бизнес-информатики, соавтор курса «Экономика для технологических предпринимателей».

Формат: онлайн-лекция + практика питчей + ответы на вопросы

Участие бесплатное. Регистрация по ссылкам:

https://t.me/mipt\_events\_bot?start=dl-1776090447189

https://vk.com/app6379730_-224205661#l=10&auto=1

29 апреля, 19:00 (Мск)

ИИ‑агенты: от LLM к автономным рабочим процессам

Лекция + мини‑практика. Разберем, как проектировать, запускать и измерять эффект от ИИ‑агентов.

О чем лекция:

● Чем ИИ‑агенты отличаются от чат‑ботов и «просто LLM»

● Архитектура агента: планирование, вызов инструментов, память, оркестрация

● Паттерны построения агентных систем (single/multi‑agent, planner‑executor)

● Сценарии применения: поддержка, продажи, аналитика, операции

● Метрики, стоимость выполнения задач, ROI пилота

● Риски, безопасность, human‑in‑the‑loop

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

🎤 Спикер: Никита Финченко — менеджер продукта VK Tech, преподаватель в МФТИ, ВШБ и VK Education

Формат: 45 мин лекции + 45 мин практики и разбора решений

Участие бесплатное. Регистрация по ссылкам:

https://t.me/mipt_events_bot?start=dl-1776161105388

https://vk.com/app6379730_-224205661#l=11&auto=1

Я знаю, что ничего не знаю (с) Сократ

Казалось бы, уже более 7 лет я провожу аудиты безопасности и тестирование на проникновение. NMap, если и не затерт до дыр, то бодрый десяток команд уже настолько забетонирован на подкорке мозга, что если меня разбудить ночью и попросить составить запрос на сканирование 20-й подсети с отображением версий сервисов, с последующим применением к ним скриптов, с максимальным отображением вывода и последующей записи лога в формат grep’а, то я продиктую команду даже не разомкнув глаз.

Однако воистину: век живи - век учись! На одном из последних проектов, в котором я принимал участие со стороны “синих”, случилась интересная аномалия: все принтеры организации поверили в SkyNet и начали неистово печатать какую-то абракадабру. И я не говорю про 1-2 листка - это было тотальное истощение ресурсов: 1 строка на 1 листе, а таких листков около сотни. И даже очищение кэша через физическое отключение 220 не помогло. В общем, на полдня компания реально “встала”. Что же произошло?

В ходе изучения текста напечатанных “документов” мы с командой выявили, что все запросы на принтеры шли на порт 9100. Порт 9100/TCP является стандартным портом прямой печати Raw и часто называется JetDirect или RAW-печать. Он позволяет сетевому устройству отправлять задание на печать напрямую в буфер принтера без использования дополнительных протоколов, шифрования и авторизации.

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

После локализации проблемы и восстановления работоспособности парка техники я начал разбираться, почему за всю мою ИБэшную карьеру у меня такого никогда не случалось, ведь я сканирую сети практически каждый день? Так вот, если мы внимательно прочитаем документацию к приложению, мы узнаем, что у NMap есть исключения (так называемые Exclude Directive), в которые по умолчанию включены порты 9100-9107. Как вы можете понять, исключены они как раз по той причине, чтобы принтеры не тратили тонны бумаги на каждую проверку сканера. В общем, хорошее откровение.

П.С. Когда я собеседую кандидатов на вакантные должности, я внимательно изучаю резюме и стараюсь задать вопросы исключительно по нему (и на половину вопросов мне не могут ответить)). И когда я вижу в секции скилы “NMap”, я люблю задавать вопрос, как программа определяет, что порт на хосте открыт, закрыт или зафильтрован. Теперь у меня будет второй добивающе-контрольный вопрос: сканирование каких портов по умолчанию не производится и требует явного указания?

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Зачем продукту исследования

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

Поговорили с Илоной, продуктовым дизайнером Project Ruler, о том, как команда использует исследования в работе и какие выводы из этого делает.

• конкурентный анализ

• глубинные интервью

• древовидное тестирование

• опросы

• юзабилити-тестирование

3️⃣ Как выглядел конкурентный анализ?

Мы использовали его как основу для гипотез. Смотрели не просто интерфейсы конкурентов, а конкретные сценарии: как пользователь выполняет задачу → куда идет → что видит.

Разложили все по критериям UX/UI, собрали в единую базу и выделили паттерны и антипаттерны. После этого уже было с чем идти к пользователям.

4️⃣ Какую пользу получили от глубинных интервью?

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

Дополнительно прогоняли обезличенные данные через ChatGPT и находили то, что сами могли упустить.

5️⃣ Зачем понадобилось древовидное тестирование?

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

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

6️⃣ Что оказалось самым неожиданным?

Вот несколько ключевых мыслей:

• Уведомления раздражают — 8 из 10 пользователей их просто выключают и потом переживают, что что-то пропустили.

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

• 8 из 10 пользователей не списывают трудозатраты — это стало поводом пересмотреть приоритеты и не перегружать продукт лишним функционалом.

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

• Некоторые функции почти не используются — оказалось, что диаграмма Ганта большинству не нужна.

• Блок «Недавние» очень востребован — пользователи прямо просили его добавить.

7️⃣ Был момент, когда исследования помогли не продукту, а вашей команде?

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

8️⃣ Какой главный вывод из всего этого опыта?

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

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

Многим кажется, что 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, работают совсем по другой логике.

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

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

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

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

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

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

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

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

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

GameDev мини-скоринг вашего игрового проекта за 15 минут

Пройдите тест: насколько ваша игра готова к релизу? 5 вопросов (для 5 категорий процесса управления игровым проектом).

Форма для оценки по ссылке>>.

Шкала оценки определена на основе анализа 45+ реальных, крупных игровых провалов, практического опыта в управлении рисками и работе с операционной эффективностью процессов различных компаний. Только здравый смысл, методология, данные и статистика.

Как считать:

1. По каждой категории поставьте балл от 1 до 5 (не обманывайте себя)

2. Умножьте на вес категории

3. Сложите и посмотрите на итоговый балл

Значения порогов:

• 42 – 83 🔴 Красная - критический риск, стоит переосмыслить концеп игры и/или управление ее развитием

• 84 – 147 🟡 Жёлтая - средний риск, можно работать, но необходимы корректировки

• 148 – 210 🟢 Зелёная - хороший потенциал, кандидат в успешные проекты

Обратная связь

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

Если шаблон оценки показался вам полезным, заходите в Telegram-канал - @GameDevRiskAdvisor. Подписывайтесь. Сможете больше узнать о рисках, метриках и ранних индикаторах проблем, присущих игровым проектам в индустрии GameDev. На канале мы регулярно и кратко разбираем игровые провалы, риски, делимся рекомендациями.

Мнение и опыт

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

Удачи в построении эффективных и устойчивых процессов.

С уважением,

Максим Торнов

Фундаментальная база для AI Advanced

Или каких "Косяков" стоит избегать, чтобы результаты LLM стали лучше

🛸 Косяк №1 — по незнанию или скупости использовать не Frontier модели
Значимый рост в глубине и качестве рассуждений наступил после Opus 4.5, а лучше 4.6 + Codex 5.3 xhigh

А вот например как выглядит API GitHub Copilot на 2026 год
"id": "gpt-4.1",
"is_chat_default": true,
"is_chat_fallback": true,

Это значит, что GPT 4.1 — стандартная модель в GitHub Copilot, которой уже почти год. И она не создавалась для агентной работы

Следовательно, некорректно все вокруг называть "Я пробовал ваш ИИ и он выдает фигню". Между Opus 4.6 и GPT 4.1 огромная разница

Туда же пойдет косяк 2

---

🛸 Косяк №2 — юзать сервисы по типу CURSOR / Replit / Lovable / Copilot

Всё это AI врапперы разной сложности, но суть одна — это врапперы, которые в большинстве своем используют модели Claude / GPT через API

Бизнес модель подобных сервисов заключается в том, чтобы с вас взять больше, а за API Usage заплатить меньше. Следовательно, AUTO выбор модели в таких сервисах почти всегда идет не от того, какая модель лучше в моменте, а какая модель на текущий момент времени будет дешевле для сервиса враппера

Ну и в дополнение — API в среднем дороже подписки в ~10 раз

Следовательно, условный CODEX / CLAUDE CODE даст вам в ~10 раз больше запросов, чем тот же самый CURSOR

При активном использовании нативный тул (Claude Code, Codex) выгоднее врапперов — нет прослойки, которая зарабатывает на марже между вашей подпиской и реальной стоимостью API

---

🛸 Косяк №3 — плохой Context Engineering

У меня есть любимая цитата

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome

Каждое словосочетание здесь — это большой и сложный домен. И чем лучше вы понимаете эту цитату, тем лучше будет ваш результат

При работе с моделью важен Spec Driven Approach — чем лучший контекст ты задаёшь для модели, тем лучше результат

---

🛸 Косяк №4 — не использовать Claude Code CLI для работы с Claude моделями

Помимо самого качества моделей еще немаловажным фактором является model-tool co-optimization.

Claude модели лучше работают с Claude Tools
Gemini модели лучше работают с Gemini Tools
Codex модели лучше работают с Codex Tools

Разработчики отмечают, что одна и та же модель Claude работает драматически лучше в Claude Code, чем в Cursor. Programmatic Tool Calling позволяет оркестрировать несколько вызовов в одном round-trip — ~37% сокращение токенов на сложных задачах

Ну и вообще, это база всех продуктов — свое работает лучше со своим

---

🛸 Косяк №5 — бездумно заполнять 1 000 000 Context Window

Часто слышу "А вот у гугл моделей 1 000 000 контекстное окно, я туда вгружаю все подряд кааайф"

Текущие модели — трансформеры — стали прорывными за счет механизма Attention, где каждый токен следит за каждым токеном

Что значит квадратичный рост compute — aka стоимость вычисления каждого следующего "слова"

Attention у трансформеров масштабируется квадратично. Стандартный контекст сегодня — 100K-200К токенов. От 100K до 1M — это 10x по длине. 10² = 100x по compute. Если бы 1M контекст реально работал на всю длину, каждый запрос стоил бы в 100 раз дороже. Но он не стоит — потому что создатели моделей используют всякие улучшалки по типу sparse attention, sliding window, KV-cache compression

По простому — компрессия ваших входных данных будет тем выше, чем больше "важного мусора" вы попытаетесь сунуть в контекстное окно

А если еще проще — чем больше вы засовываете в одну сессию, тем хуже будет ответ

Я вообще стараюсь начинать новую сессию уже после заполнения Context Window на 60к токенов

Итого

Использовать Frontier модель + нативный тул под нее + правильно оркестрировать контекст = намного качественнее результат

Уже нет смысла гоняться за лучшими моделями — важнее развивать метанавыки работы с ИИ и агентами

Смертельный марш: почему ваш проект обречен и как в этом выжить

Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).

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

Генезис катастрофы: Политика, политика и еще раз политика

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

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

Классификация неизбежного: В каком аду вы находитесь?

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

1. «Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.

2. «Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.

3. «Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.

4. «Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.

Принцип «Сортировки» (Triage)

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

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

Эстетика процесса

Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».

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

P.S. Циатата:

Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.

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

У меня не сходится логика RACI матрицы :(

Роли С и I - прекрасны, поэтому оставим их за бортом вопроса.

В моей картине мира есть Заказчик, Ответственный и Исполнител(ь,и).

• Заказчик (может быть внутренний) - принимает результат по требованиям.

• Ответственный - обязуется обеспечить соответствие целостного результата всем требованиям.

• Исполнители - делают руками.

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

Собственно во что я всё никак не могу въехать:

Буквы R и A из матрицы - не ложатся на привычную схему... Если нет Заказчика - (может быть даже внутреннего) - работа бессмысленна...

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

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

В случае, когда А-из-матрицы это и Заказчик и Ответственный в одном лице - тут конфликт интересов, как я уже выше упоминал.

Если R-из-матрицы это Исполнитель, который делает руками, и он тут называется Ответственным, то в случае нескольких исполнителей на проекте возникает соблазн спихивать эту ответственность друг на друга, что не конструктивно и без роли "главного" - матрица не помогает прочертить границы в этой ответственности.

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

У кого получается с пользой применять RACI - можете объяснить с какой стороны это кушается? Или это просто сладкая дичь для говорящих голов?

LTV — метрика, которая позволяет покупать клиентов дороже конкурентов

Большинство компаний считают лиды. Некоторые считают цену лида. Часть — даже конверсию в продажу. И почти никто системно не считает LTV. А потом в управленческой модели появляется жёсткий потолок: «Лид дороже 3 000 рублей нам не подходит». И этот потолок начинает определять весь темп роста.

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

Это и есть LTV — Lifetime Value.

Представьте двух собственников. Первый смотрит только на цену первой сделки. Если юнит-экономика сходится «в ноль плюс», он осторожничает, режет бюджет, тормозит масштабирование. Второй знает, что его клиент в среднем работает с компанией 2–3 года, делает повторные закупки и постепенно увеличивает чек. Он понимает реальную ценность клиента в системе, а не в одной транзакции.

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

Ответ очевиден.

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

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

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

И в какой-то момент происходит важный сдвиг мышления. Вы перестаёте спрашивать: «Как нам удешевить лид?» И начинаете задавать другой вопрос: «Как нам увеличить ценность клиента внутри системы?»

А это уже не про рекламу. Это про стратегию.

Масштабируется не бюджет. Масштабируется экономика клиента.

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

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

Например. Почему клиенты недовольны фичей?

1. Потому что некрасиво/непонятно задизайнили.

2. Потому что потребители, с такими-то целями использования продукта, ожидают другое поведение от фичи.

3. Потому что решение о неудовлетворённости было принято с помощью прямого вопроса в анкете, который предполагал, что потребителям вообще есть дело до этой фичи.

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

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

Регулярно пишу в Telegram-канал Chief Philosophy Officer о философии бизнеса и управленческого мышления. Заходите.

Написал бота чтобы не сойти с ума от количества чатов

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

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

В общем я сел и написал тг бота. Добавляешь его в нужные чаты – он молча сидит и собирает всю переписку в базу. Потом просто пишешь ему и он делает саммари, выгружает таблицу в Excel, показывает что чаще всего пишут люди

Раз в день короткий дайджест. Раз в неделю полный отчёт. Все данные хранятся на твоём сервере, никуда не уходят.

AI я использую локальный LLM, а в коде Openai, если будете устанавливать поменяйте на локальный или оставьте если вам нечего стесняться)

Выложил код на GitHub, настройка занимает 5 минут. Но экономит часы и нервы.
Вот ссылка https://github.com/Ata-ux/feedback_bot

Будут вопросы, пишите

–––––––––––

Мой ТГ канал