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

Матрица Эйзенхауэра в 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

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

–––––––––––

Мой ТГ канал

Что общего между разговором и созданием инновационного продукта?

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

Появление нового продукта или сервиса на рынке устроено так же. Любой продукт, как и любая технология, не нейтрален. Это слепок дискурсивной рамки, в которой живёт фаундер и его команда. Даже если создатели уверены, что действуют исключительно на основе объективных данных и живут в фукуямовской иллюзии «конца истории», сами критерии объективности и направления поиска уже заданы культурным контекстом и коллективным бессознательным команды.

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

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

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

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