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

Как попадать в цитирование LLM: разбор факторов ранжирования Claude Fable 5, GPT-5.5 и Perplexity — с экспериментом

По данным Datos & SparkToro (State of Search Q2 2025), доля LLM как источника ответов в Европе выросла на 200% за год — с 0,26% до 0,78%. Абсолютные цифры: ChatGPT — 1 млрд MAU (Sensor Tower, июнь 2026). В России нейросетями пользуются 62–82 млн человек ежемесячно (импульс.гуру, 2026).

50,9% пользователей не перепроверяют ответы LLM — output модели становится финальным решением. По прогнозу Gartner к концу 2026 объём традиционных поисковых запросов сократится на 25%. Forrester: -50% органического трафика к 2027 у компаний без адаптации контента.

Ниже — механика ранжирования в цитировании LLM.

Разница между SEO и GEO на уровне механики

SEO работает по цепочке query → index → SERP → click → landing. GEO — иначе: query → retrieval → synthesis → answer. Ключевое отличие: SEO ранжирует URL, GEO ранжирует утверждения и источники внутри retrieval-augmented generation. Позиция в SERP не критична — Perplexity часто подтягивает источники со страниц 3-5 Google.

Условие попадания в GEO: сайт в топ-20 Яндекса или в Bing-индексе для ChatGPT. Дальше решает не позиция, а структура контента.

Актуальный frontier-lineup июля 2026

У Anthropic — Claude Fable 5 (Mythos-class, 9 июня), Sonnet 5 (30 июня), Opus 4.8 (28 мая). У OpenAI — GPT-5.5. У DeepSeek — R2.

Anthropic ввёл tier «Mythos-class» выше Opus. Cross-model optimization обязательна: работа только под ChatGPT = игнорировать 43% рынка (Gemini + Claude, март 2026, Similarweb).

Пять факторов цитирования LLM

Density of verifiable facts — прирост AI-ранжирования до +40%. Оригинальные данные цитируются в 2,3 раза чаще заимствованных.

Answer capsule — 72% цитируемых страниц содержат прямой ответ в первых 150 словах. Модели работают в режиме мгновенного парсинга.

Content freshness — страницы обновлённые за 90 дней получают в 2,3 раза больше цитат.

Brand consistency — единое описание бренда повышает cite-rate в 3,9 раза. У лидеров — 94% консистентности.

E-E-A-T signals — реальный автор с датой, credentials, cross-platform footprint. Anonymous copywriting фильтруется.

Площадки-доноры для LLM

Wikipedia даёт 12,1% всех цитат AI. YouTube — 16% (транскрипты активно парсятся). Reddit — в 10 раз чаще среднего форума. Хабр — эталон для DeepSeek R2 в technical queries. VC.ru — приоритет в B2B-нишах. Sostav.ru — приоритет YandexGPT и Алисы.

Бренды из user discussions цитируются в 3,9 раза чаще брендов только из branded content.

Специфика русскоязычного сегмента

Алиса AI генерирует в 5 раз больше трафика чем ChatGPT в РФ. Яндекс — 73,34% доли рынка (+2,6 п.п. за год). Для Алисы приоритет — русскоязычный UGC (Яндекс.Услуги, Дзен, Кью). Для ChatGPT критично — Bing indexation и Schema.org разметка.

Мини-эксперимент на маркетинговом агентстве

Стартовая точка — 3/20 попаданий в ответах ChatGPT, Алисы и Perplexity. За 90 дней: answer capsules на 7 landing pages, Schema.org на коммерческих страницах, Bing indexation, 6 публикаций на профильных площадках, синхронизация bio на 12 источниках, content refresh. Финал — 11/20 попаданий. Прирост cite-rate ×3.67.

Полное присутствие требует 6-12 месяцев continuous optimization.

Три ошибки при внедрении

Считать GEO новым SEO — разные механизмы ранжирования, keyword density мертва. Purchased mentions и spam content — modern LLMs фильтруют low-quality signals лучше search engines. Ждать быстрых результатов — first changes через 3-4 недели, stable presence — 2-4 месяца.

Кто уже тестировал GEO — какой cite-rate получаете и на каких площадках наибольший leverage? Особенно интересны кейсы с Claude Sonnet 5 (30 июня релиз) — как быстро новая модель начала подтягивать бренды в ответы?

Прилетело и в очередной раз и резануло по живому...

Системность - это ... (продолжите фразу)

Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.

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

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

Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...

НЕ ПРО ПОРЯДОК!

Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).

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

Как разграничить задачи ИИ и человека в маркетинговой стратегии: кейс перестройки процесса в digital-агентстве

По Stanford AI Index Report 2026, точность frontier-моделей на тестах устойчивости расходится от 14% до 90% в зависимости от задачи. Одна модель на близких запросах даёт противоположные результаты.

McKinsey State of AI 2025: 88% организаций используют ИИ, но только 6% получают более 5% EBIT. Разрыв не в доступе к моделям — в перестройке процессов вокруг них.

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

Первая попытка: автоматизация всего подряд

Гипотеза: если LLM умеет анализировать данные и генерировать варианты — отдать всё, стратег подключается на финальной проверке.

Через три месяца:

Стратегия для салона в Праге и в Минске
отличались ТОЛЬКО названием города.

Модель не учла:
- Прага: выбор через локальные форумы
- Минск: выбор через Google Maps rating

Клиент: «Это не про мой город. Это про
абстрактный салон в абстрактном городе».

Проблема структурная. LLM генерирует на паттернах из обучающей выборки. Локальные микропаттерны конкретного рынка представлены недостаточно. Fine-tuning смягчает — не решает.

Аудит: 70/30

70% времени стратега = сбор данных
- парсинг отзывов конкурентов
- обработка расшифровок кастдевов
- сегментация UGC
→ LLM делает быстрее и без 
  потери качества к концу дня

30% времени = принятие решений
- выбор позиционирования
- культурная адаптация
- защита стратегии перед клиентом
→ требует опыта, которого 
  у модели нет

Автоматизировать можно сбор данных. Делегировать модели стратегическое решение — нельзя.

Распределение по этапам

Исследование ЦА:       80% ИИ / 20% стратег
Конкурентная разведка: 85% ИИ / 15% стратег
Позиционирование:      30% ИИ / 70% стратег
Каналы и бюджет:       60% ИИ / 40% стратег
Защита стратегии:      10% ИИ / 90% стратег

Чем ближе задача к решению — тем меньше доля ИИ.

Кейс где новая пропорция сработала

B2B-производитель стройматериалов, выход на новый рынок, 43 конкурента.

Ручной анализ: неделя работы стратега
С ИИ: один вечер обработки

Собрали: цены, отзывы, объявления,
упоминания на форумах.
Результат: таблица 43 × 12 параметров.

Утром стратег нашёл закономерность: в негативных отзывах 8 из 43 конкурентов повторялась жалоба на скорость расчёта стоимости доставки.

Позиционирование: «Стоимость доставки в вашем городе — за 15 минут».

За 3 месяца: 227 B2B-лидов, CPL снижен с $50 до $20.

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

Три вывода

1. Frontier-модели (GPT-5.5, Claude Opus 4, DeepSeek R2) обновляются каждые 2–4 месяца. Ценность — в цепочке промптов и обученных проектах под конкретный домен.

2. Верификация — часть процесса, не опция. При разбросе точности 14–90% каждый output проверяется вручную.

3. ИИ усиливает доменную экспертизу, не заменяет. LLM работает как инструмент в руках эксперта.

По McKinsey, компании с полностью перестроенными процессами получают в 2,5 раза более высокий рост выручки. Ключевое — «полностью перестроенные», а не «купили подписку».

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

Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост

Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.

Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.

И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».

Что это

team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.

team new – и у вас есть напарник-стажер и живая команда.

Дальше вы его растите от стажера до CTO.

Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.

Почему это тамагочи, а не просто игра

Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.

Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.

Это питомец, который ждет. И портится без вас.

Дилеммы из реальных споров

Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.

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

Как сыграть

Никакой установки. Открываете терминал и печатаете team:

https://teamleads.kz/shell/

team help покажет правила, team new начнет игру, team share соберет ссылку-результат, чтобы похвастаться (или пожаловаться) в чате.

Растите аккуратно. Ваш разработчик, кажется, уже начал скучать.

Почему OKR может не работать в B2B2C и что с этим делать

Большинство примеров OKR написаны про SaaS или e-commerce. Там все понятно: есть продукт, есть пользователь, есть метрика. Но что делать, если у вас два типа клиентов одновременно, непрямая дистрибуция и монетизация зависит от решений стратегического партнера?

Расскажем на реальном кейсе.

Контекст

CROSSHUB — российская IT-компания, которая разрабатывает решения для кросс-продаж в крупных федеральных компаниях. Бизнес-модель - B2B2C: с одной стороны крупные партнеры — банки, телеком, автопроизводители, с другой — конечные пользователи. Монетизация непрямая, ценность нужно доказывать сразу на двух уровнях.

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

Почему классический OKR не ложится

Компания несколько раз пробовала внедрить OKR с внешними консультантами. Каждый раз одна и та же история: фреймворк в теории работает, но примеры из книжек и курсов не адаптированы под B2B2C. Попытка натянуть стандартный шаблон на нестандартную модель приводила к целям, которые формально правильные, но оторваны от реальности бизнеса.

Проблема не в методологии. Проблема в том, что перед постановкой целей нужна синхронизация — общее понимание того, где компания сейчас и куда движется. Без этого OKR превращается в упражнение по заполнению таблиц.

Что сделали

Запрос к Product Lab был на внедрение OKR. Но уже в первый день стратегической сессии стало понятно: идти по стандартному плану не имеет смысла. Переформатировали программу прямо в процессе.

Вместо классической OKR-работы провели интенсивное стратегическое проектирование за два дня. Ключевые этапы:

Определили две метрики: финансовую и нефинансовую как единые ориентиры для всей команды. Это то, что в продуктовом подходе называют North Star Metric: одна точка, на которую смотрят все, независимо от функции.

Декомпозировали метрики ретроспективно и на будущие периоды в разрезе сегментов. Это дало команде общий язык для разговора о результатах — не «мы хорошо поработали», а «вот что изменилось в цифрах и почему».

Применили фреймворк «4 корзинки» из методологии Product Focus для определения стратегических направлений. Он позволяет расставить приоритеты с учетом реальных ограничений модели, а не в вакууме.

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

Что получилось

Команда вышла с синхронизированным пониманием приоритетов и адаптированной стратегией. Не универсальной, а под свою модель, свои ограничения и свой этап зрелости.

Все участники поставили сессии 10 из 10. По словам заказчика — лучший опыт работы с внешними консультантами за историю компании.

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

«Вижу реальную пользу. Много инструментов, легко переключается, создает комфортную атмосферу для дискуссии» — Анна Пчелинцева, CEO

Вывод

Если бизнес-модель нестандартная — сначала синхронизация по стратегии, потом OKR. Иначе даже правильно написанные цели будут работать c каждым по-своему.

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

Маркетинговое прогнозирование с ML: как считать ROMI кампании до запуска и где границы применимости моделей

По данным Salesforce State of Sales 2024, 83% команд использующих обученные модели в продажах отчитались о росте выручки против 66% без ИИ. По HubSpot State of AI 2025 — 91% маркетинговых руководителей подтверждают внедрение моделей в работу. При этом большинство применяют ИИ для генерации контента — не для прогнозирования.

Разбираю систему расчёта маркетингового прогноза до запуска кампании. Где ML-модели реально работают, где остаются граничные случаи, как считать.

Базовая формула прогноза

Входные параметры:
  budget       — рекламный бюджет
  cpl          — стоимость заявки (бенчмарк ниши)
  cr           — конверсия заявка→клиент
  avg_check    — средний чек
  margin       — маржинальность

Расчёт:
  leads = budget / cpl
  clients = leads * cr
  cac = budget / clients
  gross_margin_per_client = avg_check * margin
  total_margin = clients * gross_margin_per_client
  romi = (total_margin - budget) / budget * 100%

Пример: стоматология, бюджет 500 000₽

budget   = 500 000₽
cpl      = 700₽       (Wordstat, бенчмарк ниши)
cr       = 8%         (CRM клиента / отраслевая статистика)
check    = 60 000₽
margin   = 40%

leads    = 714
clients  = 57
cac      = 8 800₽
gm_per_c = 24 000₽
total_gm = 1 368 000₽
romi     = 174%

CAC в 2.7× ниже валовой маржи — экономика юнита сходится.

Где ML-модели работают

Сбор данных и сведение в одну картину. Загрузка CRM-выгрузок, бенчмарков ниши и поисковой статистики в одну сессию: Claude (200K токенов контекста) — лидер по объёму обрабатываемых данных. Время на сведение сокращается с дней до часов.

Расчёт сценариев. ChatGPT Code Interpreter принимает CSV с историческими данными → пишет Python для расчёта трёх сценариев распределения бюджета → выдаёт таблицу с прогнозом по каждому каналу.

Конкурентный анализ. DeepSeek обрабатывает 30–50 конкурентов параллельно (тексты сайтов, цены, отзывы) при стоимости менее $2 за вечер. Аналогичная задача на GPT-4o: $15–20.

Снижение ошибки прогноза. По данным McKinsey, прогнозирование на основе моделей снижает ошибку прогноза на 20–50% по сравнению с ручными методами.

Где модели останавливаются

Шум в обучающих данных ниши. Бенчмарки CPL и CR в B2B-нишах с длинным циклом сделки имеют высокую дисперсию. Модель выдаёт цифры с уверенностью эксперта при разбросе данных в 200–300%. Без проверки человеком — иллюзия точности.

Constraint satisfaction. LLM перечисляет 7 каналов на бюджет 300 000₽ — без учёта того что бюджет на канал ниже порога статистической значимости для теста. Человек видит это, модель — нет.

Causal inference. Языковая модель не различает корреляцию и причинно-следственную связь. «Конкурент X тратит N на маркетинг и растёт» — это не значит что копирование даст рост. Решение остаётся за стратегом.

Точность прогноза: коридор вместо точки

По данным Gartner, точности выше 90% достигают лишь 7% компаний. У большинства расхождение прогноза с фактом — 20–30%.

Хороший прогноз = диапазон, не точка:
  Не: "57 сделок"
  А:  "50–60 сделок, выручка 3.0–3.6 млн₽"

Точность 85% = расхождение ±15%
На бюджете 500 000₽ это разница 
~204 000₽ в марже план/факт

Что делать без исторических данных клиента

Стандартная проблема при выходе на новую нишу или новый рынок: CRM пуст. Решение — использовать отраслевые бенчмарки с расширенным доверительным интервалом.

С CRM клиента:
  cr_estimate = историческая CR ± 10%
  доверительный интервал прогноза: 80–85%

Без CRM, отраслевые бенчмарки:
  cr_estimate = медиана по нише ± 30%
  доверительный интервал: 60–70%

После 1 месяца кампании → пересчёт
с реальными данными → интервал сужается

ИтогML-модели в маркетинговом прогнозировании работают как ускоритель сбора данных и калькулятор сценариев. Замена аналитика — невозможно. Constraint satisfaction и causal inference остаются за человеком. Точность прогноза — функция качества входных данных, а не сложности модели.

Какие модели используете для маркетингового прогнозирования и где модель уверенно ошибалась?

Представлен открытый проект Council of High Intelligence. Это локальный совет ИИ‑мудрецов, который поможет принять любое решение и найти идеальный исход событий:

• в проекте заявлены 18 ИИ‑мудрецов: Марк Аврелий, Аристотель, Сократ, Сунь‑Цзы, Лао‑Цзы, Ричард Фейнман и Линус Торвальдс и другие;

• ИИ-мудрецы максимально продумывают каждый шаг, спорят друг с другом в парах и выдают идеальное решение вопроса;

• одни мудрецы находят риски, вторые — давят на практичность, третьи — высказывают сомнения;

• устанавливается и запускается одной командой в Claude Code или Codex.

Лайфхак для мозга:как закрывать задачи и не терять эффективность.

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

Это эффект Зейгарник или налог на внимание. Каждая незакрытая задача в списке тихо съедает часть рабочей памяти, весь день, фоном. Почему так происходит?

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

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

Такие дела. 

ИИ для Университета 4.0, а «Королев ИИ» для МГТУ им. Н.Э. Баумана

Ключевой вызов для любого вуза, стремящегося к лидерству, — это не просто автоматизировать отдельные процессы, а создать единую «нервную систему», которая пронизывает все сферы деятельности: от образования и науки до управления и работы с талантами. Именно такую задачу мы ставим перед собой в МГТУ им. Н.Э. Баумана, разрабатывая научно-образовательную платформу «Королев ИИ».

Эта платформа — не просто набор модных чат-ботов. Это многоуровневая архитектурная среда, которая агрегирует и семантически обогащает данные, развёртывает специализированные сервисы на основе больших языковых моделей (LLM) и предоставляет единые интерфейсы для студентов, преподавателей, учёных и сотрудников. По сути, мы создаём «интеллектуальное ядро» цифровой экосистемы Университета 4.0.

«Королев ИИ»: архитектура будущего

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

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

2. Уровень интеллектуальных сервисов. Это «фабрика моделей» и «озеро научных знаний». Здесь развёртываются специализированные LLM-сервисы: от генерации персонализированных образовательных траекторий и адаптивного контента до интеллектуальной поддержки научных исследований и автоматизации управленческих процессов. Мы протестировали более 30 больших языковых моделей и создали первый рабочий прототип ИИ-ассистента, который понимает голос, обрабатывает запрос и даёт ответ естественным голосом.

3. Уровень взаимодействия. Это единая точка входа для всех пользователей. Студент получает персонализированного наставника, преподаватель — ассистента для автоматизации рутины, а учёный — инструмент для ускорения исследований.

Платформа «Королев ИИ» — это инструмент для достижения стратегических целей Программы развития МГТУ до 2030 года. Вот лишь несколько примеров того, как LLM меняют привычные процессы:

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

Наука и инновации. LLM становятся катализатором продуктивности учёного. Сервисы семантического поиска, генерации гипотез и кода, поддержки публикационной активности помогают увеличить объём НИОКР и повысить количество публикаций в ведущих журналах. Мы создаём «озеро научных знаний», которое позволяет капитализировать интеллектуальный потенциал научных школ.

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

Доверенный и этичный ИИ

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

Что дальше?

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

Про персональных агентов и что он умеет у меня

Дальше разговор пойдет про OpenClaw/Hermes подобные системы. Т.е это переход от агентных систем по типу Claude Code/Codex к проактивным персональным агентам

В моей классификации это переход с уровня 8 на уровень 9

Коротко о том, в чем разница уровня 8 и уровня 9

Уровень 8 — например Claude Code / Codex / Cursor и тому подобные.
За качество отвечают — Моделька + Harness + еще по мелочи

Уровень 9 — например Hermes / OpenClaw.
За качество отвечают — Все то же самое, что и на уровне 8 + слой личной памяти + мессенджер + коннекторы в ваши сервисы + персональные skills

У меня у самого подобный агент уже был 3 месяца и крутился на OpenClaw. Но для написания статьи решил еще и Hermes попробовать

Кстати спойлер — разницы между Hermes и OpenClaw практически нет. Просто Hermes лишен кучи функций, что можно счесть как за плюс, так и за минус. Но зато у него есть Self Healing механизм, которого нет у OpenClaw

------------------

Ниже — про наполнение моего агента и что он умеет
А именно на это и уходит основное время при создании персонального агента

Личные системы
- finances — ведёт мои финансы в Notion: расходы, доходы и отчёты
- ticktick — управление моим тасктрекером TickTick: списки на день, создание задач и подзадач, ну и все такое
- google-calendar — полный контроль гугл календаря, где я ставлю совместные события и расписания с учениками
- weekly-summary — собирает недельный обзор из задач, календаря, финансов, почты, аналитики и SEO по сайту + истории сессий, чтобы я посмотрел на прошедшую неделю целиком

Мое обучение
- google-forms — читает анкеты и ответы участников
- notion — ведет базу по моим ученикам
- ga4 — аналитика моих сайтов в гугл аналитике
- seo-monitor — SEO/GEO мониторинг сайта ilia-pro-ai.com.
- youtube — навык по работе с YouTube, упаковка каждого нового видоса и сбор данных

Работа с документами
- google-sheets — работает с таблицами: ученики, оплаты, анкеты, аудиты.
- google-docx — создает классные контракты/договора

Соцсети
- linkedin — читает мой LinkedIn-профиль, посты и engagement.
- threads — работает с черновиками / публикациями /метриками в Threads
- threads-writer — пишет драфты постов для Threads из идей, ссылок, статей.

Жизневое
- concert-monitor — мониторит концерты в Bangkok/Thailand по моим артистам.
- local-entertainment-research — еженедельный мониторинг кино, события и евентов на неделю
- shopping-product-research — экспериментальный набор скиллов по работе агента с маркетплейсами, пока в процессе
- online-ordering-automation — экспериментальный набор скиллов по заказу еды/продуктов
- outreach-deeplinks — делает кликабельные ссылки для WhatsApp/LINE/tel с готовым текстом

B2B / ресёрч
- b2b-outreach-research — ищет компании, ЛПР, каналы связи и углы для outreach в LinkenIn
- apify — навык работы с Apify для скрейпинга любого сайта

Сегодня еще наконец-таки подрубил Telegram к нему и запустил его туда как пользователя — теперь мой агент может еще и так

1. Смотреть список всех моих диалогов

2. Читать историю конкретного чата. Например:

Расскажи, что за последние 2 дня ученики написали в чатике AI Advanced Alumni

3. Искать по Telegram-истории. Например:

Поищи я там где то мес назад скидывал контракт для Hochland, но не могу чатик найти

5. Смотреть каналы как пользователь и делать по ним дейли саммари

6. Скачать любые медиа из чатов
Файлы, голосовые, фото, видео — если нужно обработать/распознать/суммаризировать

7. Писать всем подряд тоже может, но есть вероятность словить бан за такое

———————

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

ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО

🔎 Контекст
У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.

🚀 Задача
Стандарт требует выстроить 25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.

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

☁️ Что мы сделали
Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний. 

🦾 Что получили в итоге
В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли. 

Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед. 

🧠 Рефлексия
Можем смело рекомендовать аналогичный пайплайн командам, которые: 

• сами готовятся к сертификации процессов РБПО;

• хотят упростить адаптацию сотрудников на новых ролях; 

• хотят убрать «слепые зоны» из разработки;

• ищут способ более предметно демонстрировать работу руководству или инвесторам. 

РБПО по ГОСТ Р 56939—2024: вебинар №26 из 30 — Сертификация ПО согласно требованиям ФСТЭК и МО

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация ПО согласно требованиям ФСТЭК и Минобороны". На YouTube. Слайды.

В вебинаре обсуждается, что на самом деле даёт сертификат и почему он не гарантирует безопасность ПО. Какие программы обязаны проходить проверку, а какие — нет. Чем отличается сертификация от аттестации, и что происходит после получения сертификата. На эти и другие вопросы ответили в бонусном вебинаре цикла с Виталием Вареницей, ведущим специалистом ЗАО "НПО "Эшелон" по сертификации и тестированию на проникновение ПО

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

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Что с хабром ?
Написал пост о том что выложил в opensource простенький ssh клиент и получил кучу дизлайков.

За что ? Я ничего не продаю, это ssh клиент которым я сам пользуюсь, пользуются еще несколько людей, через него удобно работать с туннелями и смотреть какой из сервисов отвалился

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

Как тогда делиться своими наработками, проектами, получать по ним обратную связь, если вокруг сколько негатива!
Если интересен проект, вот он на Github вот еще одно opensource приложение для транскрибации которое я развиваю

Я хочу обратную связь от сообщества, в правильном ли я направлении иду
Всем ПИС!

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

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.25. – "Обеспечение безопасности при выводе программного обеспечения из эксплуатации". На YouTube. Слайды. Это последний вебинар про процессы стандарта. Следующие пять будут бонусными.

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

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

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

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Как посчитать, приносит ИИ пользу или нет?  

До сих пор оценка эффективности нейросетей и ML-моделей в бизнесе часто напоминала гадание. Команды хвастались «высокой точностью модели», а финдиректора разводили руками, не понимая, где реальные деньги.

Чтобы разобраться с этим вопросом, команда Альфа-Банка совместно с Альянсом в сфере ИИ, Ассоциацией ФинТех и двумя десятками ведущих компаний разработали методику расчёта финансового эффекта от ИИ-проектов и упаковали её в документ под названием «Методология оценки финансовой эффективности от ИИ/ГенИИ».

Это детальный гайд на 88 страниц о том, как прекратить считать «виртуальные деньги» и начать управлять ИИ как жестким инвестиционным портфелем. В документе подробно описаны ответы на вопросы «Какими метриками можно оценить фин. эффект от ИИ?», «Какими методами можно посчитать эффект от ИИ?», «Как избежать двойного посчёта эффекта от проекта?», добавлены примеры расчётов на примере кейсов внедрений и описаны типовые ошибки.

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

Очень критически надо читать умные статьи про найм персонала.
Потому что на примере этой статьи с Хабра, можно сделать серьезные выводы и ошибиться.Как компании теряют прибыль из-за ошибок в подборе и почему это редко видно сразу https://habr.com/ru/articles/1044856/

У автора есть одно допущение, которое не обозначено в статье, но считаю, что важно его обозначить - наличие на рынке труда того самого идеального кандидата.
Это допущение, однако, является не более чем заблуждением или когнитивным искажением.
На самом деле идеального кандидата просто не существует, а если даже он есть, что вы можете ему предложить? Идеальную работу? Что-то сомневаюсь...
Таким образом на рынке труда работодатель должен искать не лучших из лучших, а лучших, среди тех, кто есть. А есть на рынке труда не самые лучшие кадры, скорее наоборот, всех хороших уже расхватали. Значит остались только худшие.
Поэтому лучше следовать принципу, что всегда и везде мы выбираем лучшего из худших, а не самого идеального. Тогда будет проще выстроить процессы найма, адаптации, испытательного срока и т.д., не тратя много сил и ресурсов на поиск, не теряя время и деньги за тот период, пока кандидат не найден и вакансия висит. Иначе поиск затянется, работа не будет выполняться, бизнес-цели не будут достигаться.

РБПО по ГОСТ Р 56939—2024: вебинар №24 из 30 — Поиск уязвимостей в программном обеспечении при эксплуатации

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.24. – "Поиск уязвимостей в программном обеспечении при эксплуатации". На YouTube. Слайды.

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

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

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

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Интеграции - Есть! Толку - нет :(

Давайте представим, что софтинка про документооборот - это рыба в воде. С жабрами, такая, хвостом и плавниками - прям адаптированная вся.

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

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

И вот все три сущности у нас есть, встает вопрос - как это всё связать друг с другом?

Удача то какая - все три решения заявляют - “У нас есть интеграции”!

Вот только среда существования у всех разная, функционал, предназначение, базовая логика - всё разное! И что надо? Вытаскивать рыбу на сушу или закапывать барса под землю? С чем “интегрировать” жабры? Со слепыми глазами?

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

PS: И чо? Задача - интересная. Работаю в эту сторону :)

Приходите на второй открытый онлайн Devhands AI Meetup #2!

📅 Когда: 18 июня, начало в 18:30 (Мск)

🔗 Где: Zoom (запись через таймпад) 

Формат: блиц по 7 минут, только личный опыт и кейсы, без воды. ~45 минут выступления подряд без вопросов, ~45 минут — обсуждение и вопросы. Всё бесплатно.

Программа на 18 июня:

• «ACP как база для агентской автоматизации» Алексей Самойлов, Techlead в Fastronome

• «Системный дизайн через AI-скиллы и MCP: от требований до архитектурного решения» Виталий Юшкевич, Lead engineer в Pugofka 

• «Опыт применения AI в стартапе инфраструктурной платформы» Георгий Меликов, no-ops платформа Exordos

• «Организация правил работы с проектами в Claude» Денис Савицкий, разработчик в DeltaSoft

• «Опыт применения AI для анализа фродовых регистраций» Дмитрий Дунаев, Дата инженер в ССР

Ксения Погорельских, хостинг-сервис Deploy-f-, название доклада уточняется (расскажу про факапы, про эксперимент, где 30 агентов-тестировщиков нон-стоп ищут баги, а агент-разработчик эти баги исправляет и отдает на ретест. И почему эти агенты долго не могли выдать мне ветку с фиксами, готовую к мержу в мастер).

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

• Кейс: рассказ о запущенных проектах, опыт внедрения и adoption в компаниях

• Цикл разработки: Agentic SDLC, SDD, ADR, автоматизация QA (unit, smoke, e2e, нагрузочное), деплой, работа с инцидентами, sandboxing, security

• Агенты: возможности/недостатки, опыт, сравнение, новинки, баги 

• Облачное окружение: модели, гейтвеи, стоимость

• Локальные модели: модели, железо, сетапы, скорость и стоимость. 

• Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю.

Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.

Что оно умеет:

• Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.

• Вытаскивает текст из любых готовых аудио‑ и видеофайлов.

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

Как это работает: модели можно крутить либо полностью локально на вашем железе (вообще бесплатно), либо подключить свои API‑ключи и платить копейки за токены без наценок сервисов.

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

🤩 GitHub  📥 Скачать

Руководитель, который не ошибается — и другие мифические существа

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

В новом выпуске «Свободного слота» — Андрей Колесников, SRE DevOps Lead в Авито и соведущий подкаста «В SREду на кухне». Разбираем топ управленческих косяков — и честно признаёмся в своих.

Что обсудили

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

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

📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №22 из 30 — Обеспечение поддержки программного обеспечения при эксплуатации пользователями

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.22. – "Обеспечение поддержки программного обеспечения при эксплуатации пользователями". На YouTube. Слайды.

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

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

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

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

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

P.S. Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились. 

Как замечать тренды раньше конкурентов

Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям.

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

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

Что такое трендвотчинг

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

Это не фиксация текущего состояния рынка, а попытка понять, куда он движется дальше.

Почему простого анализа конкурентов уже недостаточно

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

Трендвотчинг позволяет смотреть шире:

• какие технологии становятся доступнее;

• какие решения набирают популярность в смежных индустриях;

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

Так можно заметить изменения раньше, чем они станут массовыми.

Где искать ранние сигналы 

Один источник редко дает полную картину, поэтому я стараюсь комбинировать разные форматы.

Чаще всего использую:

• Product Hunt, Trend Hunter и Springwise — чтобы следить за новыми продуктами и идеями;

• Google Trends и Яндекс.Вордстат — чтобы анализировать интерес пользователей;

• консалтинговые отчеты и отраслевые исследования — чтобы видеть долгосрочные изменения рынка.

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

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

Практический подход примерно такой:

1. Сформулируйте базовый запрос, используя ключевые слова и фразы, связанные с вашей отраслью.

2. Расширьте его синонимами и альтернативными формулировками.

3. Сравните данные по регионам и сегментам аудитории.

4. Посмотрите динамику и сезонные всплески интереса.

5. Автоматизируйте мониторинг, создав дашборды и оповещения.

Как встроить трендвотчинг в рабочий процесс

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

Когда сигналы собраны, их можно структурировать с помощью:

• Trend Canvas — для глубокого анализа тренда;

• упрощенного SWOT-анализа — для быстрой первичной оценки.

Чек-лист работы с трендами

• Формулировка цели и задач исследования.

• Сканирование сигналов — системный поиск и сбор информации.

• Интерпретация и систематизация.

• Оценка и приоритизация. 

• Эксперименты и тесты — прототипы, MLP, пилоты.

• Масштабирование и интеграция.

Какие тренды уже заметны на рынке

Один из самых заметных трендов сегодня — развитие low-code и no-code подходов.

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

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

Параллельно растет интерес к автоматизации, встроенным ИИ-функциям и более гибким системам управления проектами.

Почему выигрывают внимательные

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

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

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

В стране копирующих продуктов.

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

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

Настарался не менее знатно, что-то постоянно не сходилось. Ну, не могли полтора десятка человек быть абсолютным злом. Или я в самом загадочном месте планеты, или причина в другом. Я стал искать, перебирать бэклог, группировать бэклог и вышел на… планирование. На его отсутствие.

Ладно, не вышел. Был свидетелем. Как от спринта к спринту задачи не были связаны друг с другом. Сегодня мы делаем турникет, завтра апельсин, потом кузнечика, потому что срочно нужна наковальня, а у нас итерационный продукт! Если останется время, то переведём бабушку с ангуляра на рякт, если нет — дедушку, но закончить до сентября! Что будет через два месяца? Верно, бабка с дедом посреди дороги висят на турнике в шубах на рыбьем меху. А? Поняли? Поняли? Рыбий мех — кузнечный мех! Это аджайл, мамкина норка! Нет времени уточнять, тебе ещё апельсин чистить.

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

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

Вы помните этого персонажа из Книги Джунглей. Не шибко опасен, не шибко умен, но он повсюду со своими мантрами. Если концепцию продукта можно представить в виде компаса, по которому можно сверяться и потому свободно перемещаться по пути к большой цели, то табаки-менеджмент не имеет такого компаса, он ориентируется на слухи: куда подул ветер, туда и развернут продукт. Это бизнес! Бизнес зовут! Подобное мельтешение ведёт к джунглям из спагетти-кода, что при первом приближении кажется техническим долгом.

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

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

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.21. – "Безопасная поставка программного обеспечения пользователям". На YouTube. Слайды.

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

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

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

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

P.S.

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

Собрались как то Росатом, Камаз, Северсталь и РЖД, чтобы разработать отечественный стандарт Бережливого производства - ГОСТ Р 56020.

Сделали сначала первую версию от 2014 года.

Потом через несколько лет доработали и выпустили следующую - от 2020 года.

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

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

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

Вот исходный тойотовский список из 7ми:

• перепроизводство

• избыток запасов

• лишнее перемещение объектов (логистика)

• задержки и простои

• лишняя обработка

• лишние движения человека

• дефекты и брак

Вот, на мой взгляд, более адекватный для работы вариант:

• использование неактуальной технологии

• избыточность (операции, ресурсы, страховка)

• ошибки и нарушения

• упущенные возможности и простои

Чем меньше в списке позиций - тем проще его запомнить и применять на практике.

Чем лучше систематизация, тем более целостная получается модель.

РБПО по ГОСТ Р 56939—2024: вебинар №20 из 30 — Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.20. – "Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения". На YouTube. Слайды.

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

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

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

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

P.S.

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

P.P.S. Знакомство с ГОСТ Р 56939-2024 – всё более актуальная задача

Информационное сообщение ФСТЭК России от 28 мая 2026 г. N 240/24/3693.

Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования". 

Разработка WMS и логика склада: интервью с основателем INTEKEY

Разрабатывать систему управления складом сложно, если команда не знает, как склад работает в реальности.

На канале TransRussia Connect вышло небольшое интервью с Денисом Сумелевым, основателем компании INTEKEY. Поговорили о специфике отрасли: как разработка софта пересекается с физической логистикой.

О чем идет речь в видео:
— Зачем ИТ-компании держать в штате 90% бывших директоров складов.
— Почему перед внедрением программы нужно пересобрать логистические процессы руками.
— Как выстраивать систему внутри самой ИТ-компании, чтобы автоматизатор не был «сапожником без сапог».

Я не доделал ни один проект на 100%

Сейчас по всем моим проектам записано более 10К задач. Если выполнять по одной задаче каждый день, то мне понадобится 30 лет, чтобы выполнить все эти задачи. Но когда я делаю задачу, мне приходят идеи и я записываю еще несколько новых задач. Мой список задач никогда не закончится, наоборот, количество задач в нем увеличивается каждый день.

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

Blog • Telegram

Выход на европейский рынок: 6 паттернов поведения покупателей которые ломают домашнюю бизнес-модель

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

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

Шесть паттернов из реальных проектов в Нидерландах, Польше, Италии и Испании.

Паттерн 1: скидка как сигнал низкого качества

На домашнем рынке скидка — стандартный acquisition-оффер. В ряде западноевропейских стран тот же оффер снижает конверсию.

Домашний рынок:
скидка → выгода → рост конверсии

Западная Европа (ряд ниш):
скидка → экономия на составе → падение доверия

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

Паттерн 2: соседние рынки ≠ похожие покупатели

Италия: рекомендации коллег + отраслевые мероприятия
Испания: обучающий контент + пробники

Один продукт (профессиональная косметика), две страны, два разных customer journey. Раздельные стратегии под каждый рынок: рост продаж ×10 за 4 года.

Паттерн 3: длинный цикл принятия решения

По данным Cossa.ru, маркетинг в Европе 2026 года требует 5–7 точек контакта перед конверсией.

Домашняя модель: реклама → покупка (1-2 касания)
Европа (premium/handmade): реклама → наблюдение →
изучение → возврат × N → покупка (5-7+ касаний)

Мастер по изделиям ручной работы, итальянский рынок. Воронка под прямую продажу — менее 500€/мес. После перестройки под длинный цикл: 4 000€/мес.

Паттерн 4: другие точки доверия

Польша (локальный бизнес):
Google Maps + локальные платформы отзывов > соцсети

Западная Европа (продукты питания):
состав + сертификаты > скидки + промо

Цветочный магазин в Польше. Переработка под локальные точки доверия (отзывы, фото реальных букетов, гарантия свежести с конкретным сроком): 191 заказ в месяц.

Паттерн 5: нишевые каналы без конкуренции

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

Пример: $100 бюджет → $550 выручки за неделю → ROMI 450%. Канал не очевиден при кабинетном анализе — обнаруживается через исследование конкурентной среды в целевой стране.

Паттерн 6: конкурентная среда не совпадает с домашней

Риск: перенос домашней отстройки →
      нерелевантное позиционирование

Возможность: незанятая ниша →
             вход без ценовой конкуренции

Предварительная конкурентная разведка в целевой стране — обязательный шаг до запуска рекламы.

Чеклист до запуска бюджета

1. Google Maps целевого города →
   как конкуренты работают с отзывами

2. Локальные профсообщества по нише →
   реальные триггеры покупателей

3. Тест оффера на культурное соответствие →
   скидка, срочность, социальное доказательство
   работают по-разному в разных странах

Какие паттерны поведения покупателей вы обнаруживали при выходе на зарубежные рынки — совпадало ли это с ожиданиями?

После созвонов договоренности часто теряются — и хорошо, если осталась запись встречи или кто-то из коллег параллельно вел заметки. 

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

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

Ассистент работает с материалами встреч напрямую

Мы подключили ассистента к материалам встреч в Контур Толк через MCP. Поэтому теперь не нужно искать транскрипции и вручную передавать их в языковую модель для обработки.

Например, достаточно спросить:

• «Что было на встрече с командой X?»

Ассистент: «Обсуждали запуск новой функции, договорились подготовить прототип до пятницы».

• «Какие договоренности зафиксировали по проекту?»

Ассистент: «Команда согласовала сроки и распределила зоны ответственности».

• «О чем говорили на последнем созвоне?»

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

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

Важно: ИИ не заменяет человека

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

Но даже с учетом этого искать нужную информацию стало проще — особенно когда встреч и обсуждений много.

Маркетинговая стратегия за 5 000₽ или за 5 000€: в чём разница с точки зрения данных

Один кейс который объясняет разницу лучше любой теории.

Салон красоты, бюджет 300 000₽, результата нет. Открываем Яндекс.Карты: в радиусе одного километра - 47 конкурентов.

Простой расчёт который не сделали до запуска:

Население района:       30 000 чел
Ходят на маникюр (5%):  1 500 чел
На 48 салонов:          31 потенциальный клиент/мес
При конверсии 10%:      нужно 310 лидов
Стоимость лида:         300–1 000₽
Бюджет для окупаемости: 93 000–310 000₽

Выручка при этом:       108 000₽ (31 × 3 500₽)
До вычета аренды, зарплаты, материалов

Итог: реклама физически не могла окупиться. Расчёт занял 20 минут. До запуска его не сделали.

Четыре уровня - четыре разных продукта

Стоимость маркетинговой стратегии варьируется от 5 000₽ до 5 000€. Это не разброс цен на одну услугу - это четыре разных продукта.

По данным Kadrof.ru, средний час работы маркетолога в агентстве - 1 900₽. Делите цену КП на 1 900 — получаете реальное количество часов:

50 000₽  ÷ 1 900 = 26 часов  (1 специалист, 1 неделя)
150 000₽ ÷ 1 900 = 79 часов  (2 специалиста, 2-3 недели)
300 000₽ ÷ 1 900 = 158 часов (команда 3-4 чел, месяц)

Если за 26 часов обещают провести интервью с покупателями, проанализировать 15 конкурентов и рассчитать юнит-экономику — физически невозможно.

Уровень 1: фрилансер         5–30К₽
→ 1 чел, 2-4 дня
→ документ 10-15 стр: аудитория «из головы»,
  список каналов, общие рекомендации
→ расчёта окупаемости нет

Уровень 2: базовое агентство  50–150К₽
→ 25–80 часов
→ SWOT, обзор рынка, медиаплан
→ кастдев — зависит от агентства

Уровень 3: методология        200–500К₽
→ 100–250 часов, 8 этапов
→ карта пути покупателя, сегментация
→ кастдев чаще да, прогноз примерный

Уровень 4: ИИ-аналитика       от 2 100€
→ 10–15 интервью с реальными покупателями
→ 15–20 конкурентов с бюджетами и слабыми местами
→ точный расчёт окупаемости с прогнозом
→ нейросеть обрабатывает интервью за 40 мин
  вместо 2 дней ручной работы

Разница которую видно только в данных

Стоматология, имплантация. Блок «целевая аудитория» на двух уровнях.

Уровень 3 — кабинетный анализ:

«Мужчины и женщины 30-55 лет, средний доход,
ценят качество и безопасность»

По этому описанию - одно объявление для всех. Одно объявление для всех = отсутствие сегментации.

Уровень 4 — 12 интервью с пациентами + ИИ:

Сегмент 1 (42%): женщины 45-60
→ страх: боль и осложнения
→ цикл решения: 2-6 месяцев
→ триггер: видео с врачом

Сегмент 2 (27%): мужчины 35-50
→ страх: «затянется на полгода»
→ цикл: 1-3 недели
→ триггер: план «3 визита — готово»

Сегмент 3 (18%): выбирают для родителей 70+
→ страх: «маме будет тяжело»
→ триггер: кейс с пациентом того же возраста

Три объявления, три лендинга, три скрипта для администратора. Результативность рекламы при такой сегментации — в 2–3 раза выше при том же бюджете.

Три сценария без стратегии

По данным Brand Analytics, 60% поисковых сессий в 2026 году заканчиваются без перехода на сайт - нейросеть отвечает сама и называет конкретные компании.

Сценарий 1: карусель подрядчиков
→ каждые полгода новый маркетолог с нуля
→ каждый повторяет ошибки предыдущего
→ проблема не в руках, а в отсутствии системы

Сценарий 2: бюджет растёт, отдача падает
→ 200К₽ → 100 заявок
→ 400К₽ → те же 100 заявок
→ без стратегии единственный ответ: 
  увеличивать бюджет

Сценарий 3: клиенты уходят в нейровыдачу
→ 60% сессий без перехода на сайт
→ нейросеть называет конкурентов
→ критично для: стоматология, строительство,
  недвижимость, юруслуги

По данным АКАР 2025, стоимость стратегических маркетинговых услуг за год выросла на 35%.

Итог: Документ за 5 000₽ и документ за 5 000€ в день получения выглядят похоже. Разница проявляется через полгода в отчёте о продажах. Один вопрос для проверки любого подрядчика до подписания договора: «Сколько реальных интервью с нашими покупателями вы проведёте перед запуском рекламы?»

Если ответ «нет, опишем аудиторию на основе открытых данных» - стратегия будет основана на предположениях. Не на данных.

РБПО по ГОСТ Р 56939—2024: вебинар №19 из 30 — Нефункциональное тестирование

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.19. – "Нефункциональное тестирование". На YouTube. Слайды.

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

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

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

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

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

P.S.

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.

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

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

От гипотез до операционки: открытые уроки для IT‑руководителей и менеджеров

Управление в IT — это давно не только «поставить задачи и проверить статус».

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

Собрали открытые уроки OTUS по управлению, продукту, процессам и работе с командами.

Продукт и клиентские исследования

• 3 июня, 19:00 — «Про кастдевы с интерактивом / исследование потребителей в теории и на практике». Записаться
  _{На уроке поговорим о том, как исследовать аудиторию не «для галочки», а чтобы находить реальные инсайты для продукта.}

• 17 июня, 19:00 — «Как продакту проверять гипотезы быстрее с помощью AI». Записаться
  _{Покажем, как использовать AI для ускорения продуктовой работы: от формулировки гипотез до проверки идей.}

Операционка и эффективность

• 4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться
  _{Разбор о том, где команда теряет время, деньги и управляемость — и как это увидеть в процессах.}

• 18 июня, 20:00 — «Операционный директор в IT: компетенции, которые превращают хаос в систему». Записаться
  _{Урок о том, какие навыки нужны руководителю, чтобы выстраивать процессы, а не постоянно тушить пожары вручную.}

Бизнес, стейкхолдеры и ценность

• 2 июня, 20:00 — «Цепочки создания ценности: моделирование, анализ, проектирование». Записаться
  _{Поговорим о том, как смотреть на процессы через ценность для бизнеса, а не только через задачи, статусы и регламенты.}

• 17 июня, 20:00 — «Заказчик vs Стейкхолдер: как вовлечь бизнес в проект». Записаться
  _{Разберем, как работать с ожиданиями разных сторон и выстраивать нормальную коммуникацию между бизнесом и командой.}

Финансовое мышление руководителя

• 3 июня, 20:00 — «От хаоса к контролю: как построить финансовую модель, которой можно верить». Записаться
  _{Полезно, если нужно принимать решения не на ощущениях, а на понятной модели с цифрами}.

• 17 июня, 20:00 — «Как убрать "человеческий фактор" из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться
  _{Разбор про финансовые модели, планирование, оплату труда и управленческую аналитику.}

Переход в роль руководителя

• 16 июня, 20:00 — «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться
  _{Урок для специалистов, которые переходят в тимлиды или уже управляют командой и чувствуют, что одной технической экспертизы уже недостаточно.}

AI в управлении и автоматизации

• 3 июня, 20:00 — «Как измерить рост производительности команды от внедрения ИИ». Записаться
  _{Обсудим, как оценивать эффект от AI‑инструментов без магического мышления и красивых, но бесполезных метрик.}

• 16 июня, 20:00 — «AI‑ассистент отдела без кода: как найти рутину, собрать рабочий сценарий и посчитать экономию времени». Записаться
  _{Практичный урок для руководителей, которые хотят автоматизировать повторяющиеся задачи без отдельной команды разработки.}

_{Все уроки бесплатные, проходят онлайн в рамках курсов OTUS и проводятся преподавателями‑практиками. Можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по своей ситуации.}

Если хотите системно прокачать управленческие навыки, посмотрите каталог курсов по управлению: там есть программы для проджектов, продактов, тимлидов, delivery‑менеджеров, операционных директоров и руководителей в IT.

А ещё подписывайтесь на канал OTUS в MAX — там публикуем анонсы открытых уроков, полезные материалы и подборки для IT‑специалистов и руководителей.

Как выбрать маркетинговое агентство: семь вопросов которые проверяют работает ли подрядчик с данными или с предположениями

Только в Москве зарегистрировано более 595 маркетинговых агентств. Коммерческие предложения у всех выглядят примерно одинаково. Разница проявляется через 3–6 месяцев когда открываешь отчёт о продажах.

Ниже - семь вопросов которые позволяют оценить подрядчика за один созвон до подписания договора.

Вопрос 1: что сделаете в первые две недели?

Тип А: «Настроим рекламу и запустим»
→ инструменты без данных

Тип Б: «Аудит → исследование аудитории
         → конкурентный анализ
         → юнит-экономика → план»
→ данные до инструментов

Производитель душевых перегородок, конверсия 23%. Предыдущий подрядчик запустил рекламу без анализа - конверсия не менялась при стабильном трафике. После исследования аудитории и переработки офферов: конверсия 49%, выручка $284 458 за 8 месяцев при том же бюджете.

Вопрос 2: что стоит первым в отчёте?

Плохой сигнал:   охваты, подписчики, вовлечённость
Хороший сигнал:  CAC, заявки по каналам, ROMI

Минимум в отчёте:
1. CAC
2. Заявки по каждому каналу
3. ROMI

Салон красоты с растущими охватами и стагнирующей выручкой. При аудите — все кампании оптимизированы под показы, ни одно объявление не ведёт к записи. После перестройки: $10 000 → $18 400 за 2 месяца, 508 заявок, 184 новых клиента.

Вопрос 3: сколько интервью с нашими реальными покупателями проведёте?

Большинство агентств описывают аудиторию на основе опыта в нише и открытых данных. Ни один из этих источников не объясняет почему конкретный человек выбирает ваш продукт а не конкурента.Мастер по наращиванию волос, 4–5 записей в месяц. После 8 интервью с реальными клиентками обнаружено два сегмента с разными мотивациями. Два оффера, два объявления. Результат: 19–21 запись в месяц, средний чек +25–30%.

Вопрос 4: сколько гипотез протестируете в первый месяц?

eSIM-приложение:

Кампания клиента (все интересы в одной):
  $53.18 за установку

Наши три гипотезы:
  Гипотеза 1 (тематика «путешествия»):
    $25.02 → отключили
  Гипотеза 2 (Skyscanner, Airbnb, Booking):
    $96.67 → отключили за 1.5 дня
  Гипотеза 3 (Advantage+ путешественники):
    $10.77 → масштабировали

Разница на 1 000 установок: $42 410

Вопрос 5: что будете делать с существующей базой?

Агентства оптимизированы под привлечение. Но для бизнеса с повторными покупками LTV существующего клиента в 3–7 раз дешевле в обслуживании чем привлечение нового.

Минимум работы с базой:
- Сегментация по RFM
- Реактивация ушедших сегментов
- Система допродаж

Если ответ «только привлечение» — агентство закрывает половину задачи.

Вопрос 6: сколько часов работы стоит за ценой КП?

~1 900₽ — средний час маркетолога (Kadrof.ru)

50 000₽  ÷ 1 900 = 26 часов
150 000₽ ÷ 1 900 = 79 часов
300 000₽ ÷ 1 900 = 158 часов

Если за 26 часов обещают кастдев + анализ 15 конкурентов + юнит-экономику + стратегию — физически невозможно. Что-то будет сделано формально.

Вопрос 7: работаете с присутствием бренда в ответах нейросетей?

По данным Brand Analytics, 60% поисковых сессий в 2026 году заканчиваются без перехода на сайт. Для B2C с высоким чеком и длинным циклом принятия решения это означает что часть клиентов принимает решение о звонке конкурентам ещё до попадания на ваш сайт.

Проверка за 2 минуты:
1. Открыть ChatGPT
2. Спросить: «Порекомендуй [ниша]
   в [город]»
3. Если вас нет в ответе — измеримая
   потеря потенциальных клиентов

Итог

Вопрос 1: данные до инструментов или нет
Вопрос 2: метрики в деньгах или в охватах
Вопрос 3: реальные покупатели или предположения
Вопрос 4: тестирование гипотез или «проверенная связка»
Вопрос 5: полный цикл или только привлечение
Вопрос 6: часы соответствуют обещаниям или нет
Вопрос 7: учитывает AI-поиск как канал или нет

Задайте эти вопросы трём-четырём агентствам подряд — разница в ответах покажет уровень подрядчика точнее чем изучение кейсов на сайте.

Интересно услышать в комментариях: какие из этих критериев вы проверяете при выборе подрядчиков?

Зачем корпоративному ИИ семантическое ядро: разбор стратегий SAP, Oracle и Palantir

SAP, Oracle, Palantir и другие корпоративные гиганты строят вокруг ИИ семантические слои: knowledge graph, ontology, process intelligence. Разбираемся, почему языковой модели недостаточно просто читать документы и таблицы.

Языковая модель умеет читать документы, таблицы, обращаться к API. Казалось бы, достаточно для корпоративного ИИ. Но SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou активно строят семантические слои поверх данных: графы знаний, онтологии, process intelligence, платформы агентов.

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

Что такое семантическое ядро и зачем оно

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

Примеры таких слоёв, как сообщают SAP и Oracle:

• Knowledge graph — граф связей между сущностями бизнеса: клиенты, заказы, продукты, поставщики.

• Ontology — формальное описание терминов и отношений: что такое «заказ», какие у него могут быть статусы, как он связан с накладной.

• Process intelligence — карта фактических бизнес-процессов, извлечённая из логов систем: как реально движутся заявки, где возникают узкие места.

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

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

Как это работает на практике

SAP строит Business Data Cloud — единый семантический слой поверх разрозненных систем учёта. Oracle развивает граф знаний для своих облачных приложений. Palantir предлагает онтологию как основу для агентных систем в Foundry. Celonis использует process mining для извлечения фактической логики процессов из event logs.

Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:

1. Заявка связана с заказом, который уже частично оплачен.

2. Товар числится на складе, но фактически уже отгружен другому клиенту.

3. Клиент имеет статус VIP, что меняет правила возврата.

4. Есть открытый тикет в поддержке с похожей проблемой.

Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.

Ограничения и подводные камни

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

Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.

Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.

Что это меняет

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

Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.

TG @ciologia

Негативный фидбек: как говорить правду, не сломав человека

«Сэндвич» не работает. Анонимные опросы врут. А честный разговор с руководителем кажется карьерным суицидом. Но без негативной обратной связи команды не растут — и все об этом знают.

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

Что обсудили

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

Бонус: в конце выпуска ведущие сами принимают «развивающую» обратную связь от слушателей. Вживую и без купюр.

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

📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

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

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

От B2B-продаж к международному IT-продукту: про смену майндсета, антикризисный менеджмент и работу с партнерами по всему миру — Влад Стоянов в подкасте «Привет, касатики»

В гостях у Жени Ившина и Лены Соколовой наш Product Lead рассказал про свой нестандартный карьерный путь и то, как устроена работа с международным партнерским IT-продуктом изнутри.  

Слушай на Яндекс Музыка или Apple Podcasts, чтобы узнать: 

> как 10 лет в продажах привели Влада к желанию влиять на сам продукт, а не продавать его вопреки его недостаткам;

> почему в Garage Eight ценят тех, кто готов сказать «это можно сделать лучше» и не боится это отстаивать;

> чем партнер из Бразилии отличается от партнера из Юго-Восточной Азии и как это влияет на продукт;

> как выстроить стейкхолдер-менеджмент, когда результат виден не сразу, а через несколько кварталов;

> почему тушить пожары своими руками — это путь к выгоранию, а не к системному бизнесу;

> как вытащить команду из выгорания и почему иногда для этого нужно отпустить людей в другие направления.

Мы Garage Eight верим, что результат — это не выпущенная фича, а подтвержденное влияние на бизнес и пользователей. Если откликается наш майндсет, присылай свое CV через форму фаст-трек на сайте.

Коллеги, привет! Мы записываем новый выпуск Свободного Слота и хотим узнать — за какую ошибку вам стыдно больше всего в вашей управленческой карьере? 

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

Сомнения о сделанном

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

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

Blog • Telegram