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

Склад(бище) дашбордов или закон убывающей предельной полезности

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

За последний месяц вижу немало дискуссий о том, что дашборды умирают. В LinkedIn приводили статистику: 20-30% дашбордов уходят в зону околонулевой активности. А у вас с этим как обстоят дела? Смотрели статистику использования своих дашбордов?

Почему это происходит, моя версия

Аналитики в IT, прежде всего, обладатели хардов – SQL, Python, BI. Но владение инструментом – это не то же самое, что интерпретация данных. Это уже другой тип мышления. Он у тех, кто задает данным логический курс. Не считает метрику, а решает, что она значит, причем в контексте других метрик.

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

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

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

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

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

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

Дашборд – это инструмент в цепочке создания ценности, а не самоцель. Если после просмотра дашборда не меняется ни одно решение, действие или понимание ситуации – возникает закономерный вопрос: а зачем он вообще нужен? Вспомним еще один закон - Гудхарта: если мера становится самоцелью, она перестает быть хорошей мерой. Без добавленной ценности в виде серьезной аналитики с бизнес смыслами он так и останется просто красивой картинкой.

Что делать

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

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

Как HiveTrace ускорила запуск AI Firewall для корпоративных приложений с генеративным ИИ

🏭 Что за компания
HiveTrace разрабатывает AI Firewall для защиты приложений на базе генеративного ИИ в корпоративном контуре. Решение анализирует запросы пользователей до их передачи в модель и проверяет ответы модели перед отправкой пользователю. Это защищает от промпт-атак, снижает риск утечки чувствительной информации во внешние системы и помогает соблюдать требования по работе с персональными данными.

⚡ Задача
Чтобы запускать пилоты и масштабировать внедрения у корпоративных заказчиков, HiveTrace требовалась готовая инфраструктура, соответствующая требованиям ИБ-команд: с Kubernetes, GPU и возможностью быстро развернуть решение без доработки существующих компонентов.

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

☁️ Что сделали
Для размещения AI Firewall HiveTrace выбрала платформу Cloud.ru Evolution. Решение развернули на базе Evolution Managed Kubernetes с GPU.

Managed-сервисы Cloud.ru оказались совместимы с компонентами HiveTrace, поэтому команде не пришлось адаптировать продукт под новую среду. Это позволило использовать готовую инфраструктурную основу для пилотов и последующих внедрений у заказчиков.

Дополнительно модель HiveTracePro включили в сервис Evolution Foundation Models. Теперь пользователи Cloud.ru могут подключать ее как дополнительный уровень защиты приложений с генеративным ИИ. Модель дополняет Guardrails Filter — инструмент Cloud.ru для маскирования чувствительных данных при работе с языковыми моделями.

🦾 Что получили в итоге
HiveTrace ускорила запуск проектов у корпоративных клиентов: для внедрения AI Firewall больше не нужно отдельно готовить и адаптировать инфраструктуру. Команда может сосредоточиться на развитии продукта и новых механизмах защиты, а заказчики — быстрее подключать защиту своих ИИ-приложений от распространенных угроз.

Подробнее читайте на сайте.

Пользователь заработал $120 тыс., размещая рекламу на виртуальном унитазе. Он взял 3D‑модель обыкновенного унитаза, повесил там счётчик донатов и добавил рекламу всякого криптоскама на крышку и ободок (там им и самое место). При этом собранных денег автору проекта оказалось мало — он планирует получить за такой перфоманс миллион долларов.

Представлен ресурс Claude Watermark Remover для удаления криптометок из Claude от Anthropic.

Anthropic со 2 августа 2026 года начала внедрять маркировку контента, созданного Claude. В сгенерированный текст встраивается невидимый водяной знак, который не влияет на смысл или читаемость и может сохраняться после копирования и некоторых правок. Это может усложнить использование Claude для написания дипломных работ, книг и исследований. Во все актуальные модели встроили криптометки по стандарту C2PA. Метки невозможно увидеть и они сохраняются даже при копировании на другие ресурсы.

Два типа решений которые я принимаю по-разному

Заметил за собой паттерн который долго не мог сформулировать.

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

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

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

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

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

Как вы разделяете у себя эти два типа?

Проджект или Продакт?

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

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

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

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

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

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

Поделюсь тем что удивило.

Большинство людей выбирают сервис по стоимости подключения. Это почти всегда ошибка.

Настоящая стоимость - в модели работы сервиса. А моделей сейчас три.

Модель 1 - комиссия с каждой оплаты

Tribute, Paywall и похожие сервисы берут 10-20% с каждой транзакции. Деньги идут через их систему, они выплачивают тебе остаток по расписанию.

Считаем на конкретных числах. При обороте 30 000 рублей в месяц комиссия 10% это 3 000 в месяц и 36 000 в год. При обороте 100 000 - уже 10 000 в месяц и 120 000 в год. При 300 000 - 30 000 в месяц и 360 000 в год только за пользование платформой.

Плюс: не надо думать о платёжках, просто подключился и работаешь.

Минус который мало кто считает заранее: при обороте от 100к в месяц комиссия начинает ощутимо давить. А ещё - Tribute работает через иностранное юрлицо (TRBT Limited). Для самозанятых это дополнительные вопросы по 173-ФЗ о валютном контроле.

Модель 2 - Telegram Stars

Нативная валюта платформы. Пользователь платит не выходя из Telegram, конверсия выше.

Но есть нюансы которые многие узнают постфактум. Если пользователь купил Stars через iOS или Android - Telegram отдаёт разработчику примерно 70%, остальное уходит Apple или Google. Если через десктоп - почти всё твоё. Вывод только через Fragment в TON, для рублёвой отчётности лишний шаг.

Для кого подходит: проекты где аудитория сидит в основном на десктопе, или те кто не против крипто-вывода.

Модель 3 - фиксированный тариф

Деньги идут напрямую на твой счёт в ЮKassa или CloudPayments, сервис берёт фиксированную абонентку.

Та же математика. При обороте 30 000 в месяц платишь фикс около 2 000 - экономия против 10% всего 1 000, разница несущественная. При 100 000 в месяц фикс те же 2 000, экономия уже 8 000. При 300 000 - фикс 2 000, экономия 28 000 в месяц. За год это больше 300 000 рублей которые остаются у тебя а не у платформы.

Из российских сервисов с такой моделью смотрел Nemiling - там фиксированный тариф от 1 790 ₽ в месяц без ограничений по количеству проектов, деньги приходят напрямую на счёт, бесплатно до 5 000 ₽ оборота.

Что ещё важно при выборе - и про что почти не пишут.

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

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

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

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

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

При обороте до 20-25 тысяч в месяц разница между моделями почти незаметна - можно брать что удобнее. При росте выше - фиксированный тариф начинает выигрывать математически.

А вы как выбирали инструмент для монетизации Telegram-проекта - считали экономику заранее или уже потом пересчитывали?

Документация, которую никто не читает, и документация, которую читают. В чём разница

Работал в командах, где документация была, и где её не было. И в командах, где она была, но не работала. Последнее - хуже всего.

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

Документация, которую читают, обычно такая: короткая заметка прямо рядом с задачей. «Почему мы сделали именно так». «Что пробовали до этого». «Что точно не трогать и почему». Как правило, написана человеком, который только что через это прошёл.

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

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

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

Обновляйте документацию при каждом изменении кода, включайте это в Definition of Done.

Ежеквартально проверяйте документацию на актуальность, удаляйте устаревшее или лучше архивируйте для сохранения истории.

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

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

Локальный ИИ в компании - когда это оправдано

Читал недавно материал про то что локальный ИИ в 2026 году становится нормой для многих компаний. Хочу добавить продуктовый угол к этой теме.

Запускал несколько проектов где вопрос «облачная модель или локальная» стоял всерьёз. Вот когда локальный вариант действительно оправдан.

Работа с персональными данными. 152-ФЗ не оставляет выбора если у вас данные российских пользователей и вы хотите их гонять через LLM. Либо обезличиваешь до потери смысла, либо поднимаешь локально. Третьего нет.

Предсказуемые затраты при больших объёмах. Облачные API дешёвые пока объём маленький. При тысячах запросов в день считать токены становится болезненно. Локальная модель это капитальные затраты один раз.

Специфический домен. Если задача очень узкая - юридические документы конкретной компании, внутренняя документация, корпоративный стиль - дообученная локальная модель часто бьёт универсальную облачную по качеству на этой задаче.

Когда локальный вариант не оправдан: когда хочется попробовать и посмотреть. Разворачивать инфраструктуру под гипотезу которую ещё не проверили - дорого и медленно. Для экспериментов облако лучше.

Кто уже пробовал локальные модели в продакшене - какие задачи закрываете?

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

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

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

Три реальные причины почему платники не остаются надолго.

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

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

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

Всё это лечится, но не контентом. Контент это необходимое условие, а не достаточное.

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

Один оператор сравнения чуть не удалил тысячу пользователей 

На днях наводил порядок в логике автопродления подписок Telegram-бота.
Казалось, задача на полчаса.

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

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

Сначала я подумал, что платёж не успел записаться в базу. Проверил – платёж записался.

Потом начал искать проблему в часовом поясе. Тоже нет.

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

Причина оказалась намного проще: в фундаменте не стоял тот оператор сравнения.

Вместо subscription_end < now
я написал subscription_end <= now.

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

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

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

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

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

Что изменил:

1. Перенастроил удаление: теперь оно происходит не сразу.

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

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

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

3. Добавил тест на этот сценарий, чтобы избежать повторения <=ошибки.

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

Мораль:
даже очевидные условия нужно проверять на границах. 

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

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

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

Все, что нужно знать про нового главу Apple — пожилая пользовательша принесла на ремонт Apple Cinema Display 2004 года выпуска, который сломался впервые за 22 года. Cinema Display был первым проектом в Apple, над которым работал лично Джон Тернус. Устройство всё ещё работает, но дисплей в последнее время не в лучшей форме.

Новый проект True Tech: менторские сессии с экспертами MWS!

Запускаем серию открытых менторских сессий с экспертами MWS: делимся опытом и помогаем расти тимлидам и специалистам уровня Senior и выше.

Первый ментор серии — Александр Фокин, стратег MWS, 15+ лет в IT. Помогает компаниям разрабатывать и внедрять стратегии, развивать RnD-культуру и интегрировать инновации. Прошел весь путь от инженера до руководителя и смотрит на задачи как инженер: меньше хайпа — больше конструкции и результата.

С чем поможет:
🎯 Сформулировать личную стратегию: куда и как развиваться, как выбрать направление и собрать карту роста.
🧭 Понять основы стратегического мышления и как принимать решения, когда данных нет, а будущее размыто.
🚀 Собрать стратегию, «продать» ее и начать реализовывать.

Что включает проект:
🗓️ Две сессии по 60 минут с интервалом 1–2 недели. Плюс домашнее задание, которое поможет закрепить знания на практике.

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

Как попасть:
📝 До 10 сентября заполните короткую анкету по этой ссылке. Саша прочитает все заявки и выберет менти по четкости запроса и совпадению темы.

Западные ИИ-модели закрываются для РФ. Что это значит для продуктов

В июне 2026 года Минторг США закрыл доступ к моделям Anthropic для неграждан США. OpenAI согласовывает клиентов новых моделей с правительством. Это не слухи - это уже работающая реальность.

Для большинства российских пользователей это пока незаметно: ChatGPT в браузере доступен, Claude тоже. Но для бизнеса который строит продукты на API - история другая.

Что это значит на практике.

Если ваш продукт завязан на OpenAI или Anthropic API - у вас есть риск который нужно оценить. Не паниковать, но понимать.

Альтернативы есть и они нормальные. GigaChat вырос за последний год. YandexGPT тоже. DeepSeek доступен через API. Для большинства продуктовых задач этого достаточно. Не для всех, но для большинства.

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

Кто уже перешёл на отечественные модели в продакшене - как ощущения?

«Это разовая ситуация» - самая дорогая фраза в процессах

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

В каждой команде с которой я работал была своя версия этой фразы. «Это нетипичный случай». «Сделаем руками, один раз». «Для этого клиента отдельный порядок».

Через год выясняется что таких «разовых» ситуаций накопилось сорок штук. Каждая требует чьего-то времени. Никто не помнит почему именно так. Новый человек в команде не знает что делать и спрашивает того кто знает. Тот кто знает тратит время на объяснение вместо работы.

Ручное исключение это не проблема само по себе. Проблема когда оно становится невидимым. Когда его не фиксируют, не считают и не решают является ли оно симптомом чего-то в процессе.

Простое правило которое помогает: если одно и то же исключение случилось три раза - это уже не исключение. Это дыра в процессе которую надо закрыть.

Как вы отслеживаете ручные исключения в своих процессах и правилах?

Открыли доступ к курсам по ML-системам от основ до продакшна. И да: это бесплатно

Кто-то смотрит на ML как на способ оперативно занять рыночную нишу, не понимая, какой технический фундамент необходим для реализации идеи очередного прорывного продукта. Кто-то запускает идеальный эксперимент в ноутбуке, но выясняется, что он не работает в продакшене. Это две крайности одной и той же проблемы: мало кто понимает, как работают ML-системы от первого винтика данных до последней шестеренки мониторинга. Чтобы глобально исправить это, мы собрали весь свой опыт провайдера облачных и ИИ-решений в линейку курсов Cloud.ru ML System Design и сделали доступ к ней открытым.

Какие курсы есть в линейке? 

• «Машинное обучение в облаке»⏳15 ч — как использовать облачную инфраструктуру для разработки, обучения и эксплуатации ML-систем.

• «ML в продакшене»⏳2 ч — база, которую нужно знать, чтобы довести модель от эксперимента до стабильной работы в боевой среде с учетом инфраструктуры, данных и процессов.

• «Основы ML‑систем и обработки данных» ⏳3 ч — базовое устройство ML-систем, пайплайнов данных и ключевых компонентов end-to-end решения.

• Training Data⏳3 ч — как собирать, очищать, версионировать и поддерживать обучающие данные без деградации качества.

• Feature Engineering ⏳4 ч — как проектировать и поддерживать признаки, которые работают не только в обучении, но и в проде.

• Model Development ⏳3 ч— как разрабатывать модели с учетом требований к качеству, воспроизводимости и дальнейшему деплою.

• «Офлайн-оценка ML‑модели»⏳3 ч — как корректно валидировать модели до продакшена и не переоценивать их качество.

• Model Training⏳4 ч — как строить надежные и масштабируемые процессы обучения моделей.

• Inference⏳4 ч — как организовать инференс (онлайн и батч) с учетом latency, нагрузки и архитектурных ограничений.

• Model Monitoring⏳3 ч — как отслеживать деградацию моделей, data drift и аномалии в проде.

• MLOps⏳4 ч — как выстроить процессы, CI/CD и инфраструктуру для жизненного цикла ML-моделей.

• «Проектирование ML-системы»⏳2 ч — практический кейс для отработки навыков, который поможет персонализировать ленту новостей.

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

Проходите курс и создавайте зрелые ML-продукты! 

Представлен открытый проект no‑gdid, который позволяет избежать слежки со стороны Microsoft через GDID (расшифровывается как Global Device Identifier, глобальный идентификатор устройства — это уникальный идентификатор, присваиваемый каждой установке Windows, который отслеживает телеметрию, специфичную для устройства).

Инструкция по использованию проекта gdid. Примечательно, что штатное отключение телеметрии не даёт заблокировать работу с GDID, который хранится на серверах Microsoft.

Ранее ФБР использовала идентификатор Windows 11 для ареста за распространение программы‑вымогателя.

Три метрики которые я перестал считать

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

DAU и MAU в отрыве от контекста. Цифра растёт - хорошо. Падает - плохо. Но сама по себе она ничего не говорит о том почему. Видел продукты с растущим DAU и ухудшающейся юнит-экономикой одновременно. Рост привлечения маскировал проблему с удержанием.

NPS. Красивая цифра для отчётов. Но детракторы часто просто уходят молча не заполняя опрос. Промоутеры заполняют охотно. В итоге метрика смещённая. Видел продукты с высоким NPS и растущим churn одновременно.

Completion rate онбординга. Люди проходят кликая далее не читая. Метрика зелёная, понимания продукта нет. Об этом уже писал, но продолжаю видеть это в проектах снова и снова.

Общая проблема у всех трёх: показывают что происходит, но не объясняют почему. А решения нужно принимать именно на основе почему.

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

Какие метрики вы перестали считать или считаете что переоцениваете?

Про утопию «люди думают, а роботы работают», или про то, как корпорации пытаются вернуть вотерфолл

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

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

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

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

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

Источник Телеграм-канал Chief Philosophy Officer 

Хочу сделать своего бота для монетизации платного контента в Telegram.

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

Кандидаты, которых изучил:

Tribute и Paywall - деньги идут через внутряннию систему сервисов, они забирают комиссию с каждой транзакции (от 10 до 20%). Tribute официально декларирует плоскую комиссию 10% выплаты по расписанию два раза в месяц. Для меня это хорошая модель: чем больше оборот, тем больше я заработаю. Но если смотреть глазами пользователя, при росте оборотов 10-20% начинают очень заметно съедать прибыль, и сегодня многие склоняются в пользу другой модели.

Nemiling - там переводы идут напрямую на счёт, а вместо комиссии фиксированный тариф за оборот: бесплатно до 5k руб/мес, дальше два плана без ограничения по количеству проектов - 1790 руб/мес при обороте до 60 000 руб/мес и 2990 руб/мес при обороте выше - без ограничений. По сути, это классическая SaaS-модель с подпиской.

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

Как ведут себя цифры при обороте

Если по‑честному взглянуть на цифры, разница между процентной моделью (как у Tribute/Paywall) и фиксированной подпиской (как у Nemiling) становится болезненной уже на средних оборотах.

Если владелец канала стабильно делает 50 000 в месяц.
С комиссией 10% он каждый месяц отдаёт по 5 000, а за год набегает около 60 000 только за пользование платформой.
В фиксированной истории вроде Nemiling на таком уровне автор платит около 2 000 в месяц, то есть примерно 21-22 тысячи в год. Получается, вместо 60k он отдаёт чуть больше двадцати - просто потому, что платит фикс за сервис, а не процент с каждой оплаты.

А если автор стабильно держит в районе 300-500 тысяч в месяц?
При процентной модели 10% это уже 30-50 тысяч в месяц, то есть от 360 до 600 тысяч в год только за то, что он пользуется сервисом.
В фиксированной модели он всё так же платит несколько тысяч в месяц, суммарно порядка 35. Разница уже не просто ощутимая, а стратегическая.

Так вот как создателю бота, мне хочется запуститься с моделью как у Tribute или Paywall, она она обещает хорошие деньги, но с другой стороны, смогу ли я успешно конкурировать с такими закоренившимися ботами. Хочется зайти в нишу и при этом сделать всё так, что-бы иметь конкурентное приемущество.

Если выбрать решение типа Nemiling: удобный рублёвый вывод на счёт, фиксированная плата при росте оборотов и экономия в разы. У меня будет "козырь" с котрым проще зацепиться и удержаться, хотя и окупаемость будет дольше.

Вопросы к сообществу

1. Кто юзает ботов платных подписок: какую модель в итоге выбрали и почему?

2. Какие тонкие нюансы с выводом и отчётностью вы встречали при работе с Tribute, Paywall, Stars, Nemiling, investmember? Особенно интересует опыт с рублёвой отчётностью и валютным контролем.

3. Есть ли на сегодняшний день надёжные гибридные решения - например, фиксированная подписка + внутренняя опция «оплатить через Telegram (Stars)»?

Буду признателен за конкретные цифры, кейсы и ссылки на опытные расчёты. Спасибо!