Все потоки

Почему LLM не может написать маркетинговую стратегию: три проблемы с точки зрения данных

Мы провели эксперимент: дали ChatGPT подробный бриф реального бизнеса (стоматологическая клиника, имплантация, средний чек 120 000₽, бюджет 300 000₽/мес) и попросили написать маркетинговую стратегию. Промпт составили максимально детально — роль, контекст, задача, требуемые разделы.

Результат: 18 страниц с оглавлением и структурой. Проблема не в объёме и не в форматировании.

Проблема 1: distribution shift между обучающими данными и реальным бизнесом

LLM генерирует описание целевой аудитории на основе паттернов из обучающей выборки — усреднённых данных о «типичной» аудитории ниши. Результат предсказуемо generic:

"Мужчины и женщины 30-55 лет, средний и выше среднего доход, 
проживающие в Москве. Ценят качество, безопасность и современные 
технологии. Ищут клинику с хорошей репутацией и опытными врачами."

Замените «стоматология» на «автосервис» или «частную школу» — описание не изменится. Потому что модель не имеет доступа к ground truth: реальным данным о том кто именно приходит в эту конкретную клинику.

После 12 глубинных интервью с реальными пациентами картина принципиально другая:

Сегмент 1 (42% обращений): женщины 45-60 лет
- Главный страх: боль и осложнения
- Цикл принятия решения: 2-6 месяцев
- Триггер записи: видео с врачом объясняющим процедуру

Сегмент 2 (27% обращений): мужчины 35-50 лет  
- Главный страх: длительность лечения
- Цикл принятия решения: 1-3 недели
- Триггер записи: конкретный план с числом визитов

Сегмент 3 (18% обращений): выбирают для пожилых родителей
- Главный страх: безопасность для возраста 70+
- Триггер записи: кейс с пациентом того же возраста

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

Проблема 2: отсутствие constraint satisfaction при распределении ресурсов

LLM генерирует список каналов без учёта реального constraint — бюджетного ограничения клиента:

"Яндекс.Директ, Google Ads, Instagram*, ВКонтакте, SEO, 
контент-маркетинг, работа с отзывами на агрегаторах"

7 каналов при бюджете 300 000₽/мес дают ~43 000₽ на канал. Это ниже порога статистической значимости для тестирования практически в любом из них.

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

Проблема 3: KPI без causal model

"Увеличить количество первичных пациентов до 80 в месяц. 
Снизить стоимость привлечения на 20%. 
Повысить конверсию сайта до 5%."

Откуда 80? Почему 20%? Почему 5%?

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

Число «80» может оказаться заниженным в 2 раза или физически недостижимым — без unit economics это невозможно проверить.

Что LLM делает хорошо в этой задаче

Чтобы не быть голословным — где модель действительно ускоряет работу:

Хорошо:
+ Обработка транскриптов интервью → выделение паттернов
+ Анализ открытых данных о конкурентах → структурированный отчёт
+ Генерация гипотез для A/B тестирования на основе сегментации
+ Форматирование и структурирование уже собранных данных

Плохо:
- Замена первичного сбора данных
- Оптимизация под конкретные ограничения без входных данных
- Прогнозирование без causal model

Итог

Проблема не в том что LLM «плохо пишет стратегии». Проблема структурная: модель оптимизирована для генерации текста похожего на маркетинговую стратегию — но не для решения оптимизационных задач с реальными данными конкретного бизнеса.

Это разные задачи. Первая — задача на паттерн-матчинг по обучающей выборке. Вторая — задача на constraint satisfaction и causal reasoning с domain-sp

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

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

Сегодня должна была начаться масштабная забастовка сотрудников Samsung. Но не началась. Компания смогла договориться с профсозом перед самым началом забастовки.

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

Особую остроту конфликту придает тот факт, что профсоюз требует высоких фиксированных выплат даже для тех подразделений Samsung, которые работают в убыток. [Цитата из статьи по ссылке выше]

Я не знаю детально, что там в Samsung'е. Ибо могут быть нюансы. Многое зависит от того, что именно из себя представляют эти "убыточные подразделения" и как в них формируются выплаты. Возможно, что именно в Samsung'е позиция руководства и оправдана. Однако в целом вопрос выплат сотрудникам убыточных подразделений мне кажется важным. На мой взгляд, такие выплаты часто бывают несправедливыми.

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

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

1. они могут производить "побочный" продукт, который усиливает позиции основного. Такое часто бывает у производителей "железа". Например, компания может производить микропроцессоры и в ней может быть подразделение, которое производит софт для них (допустим, компиляторы). Софт по большей части может раздаваться бесплатно. Да, часть софта может быть платной и поддержка может быть платной, но в целом софтверное подразделение вполне себе может быть убыточным (осознанно!). А прибыль будут приносить "железки"

2. компания сама сохраняет убыточное направление в надежде, что когда-то оно раскрутится. Бывает, что не раскручивается никогда, а компания продолжает вбухивать в него деньги. А бывает, что в какой-то момент начинает генерировать прибыль (как Яндекс.Такси, например, которое долгое время было убыточным, а потом начало зарабатывать)

3. исследовательские подразделения. Они могут работать над перспективными прототипами. То есть прибыли от них нет, одни убытки. Когда прототип взлетает, то его передают в продуктовое подразделение, сотрудники которого начинают получить премии за каждую новую фичу, а сотрудники исследовательского подразделения сосут лапу (обычная история, кстати)

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

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

Нейросети, компиляторы и гонка AI-железа — новый выпуск «Битовых масок»

В новом выпуске «Битовых масок» говорим о нейросетях, больших языковых моделях и аппаратной разработке для ИИ. В гостях — Андрей Камаев, эксперт по разработке ПО искусственного интеллекта, который начинал карьеру еще во времена независимой OpenCV-компании Itseez, а позже работал в Intel. Вместе с Еленой Лепилкиной и Антоном Афанасьевым он обсудил, как индустрия пришла к современным LLM и что сегодня происходит на рынке AI-железа.

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

Выпуск получился одновременно историческим и практическим. Вы узнаете:

• как индустрия пришла к современным LLM и что происходит на рынке AI-железа;

• почему NVIDIA лидирует, а AMD пока не смогла догнать конкурентов;

• чем отличаются компиляторы для нейросетей и почему сложно создать специализированный AI-ускоритель;

• как устроены LLM «изнутри» и почему нейросети можно назвать «вредным джинном»;

• какие навыки помогут начинающим разработчикам строить карьеру и конкурировать с ИИ.

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

Личный бренд и бренд продукта – странная и не всегда простая связка.

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

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

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

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

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

Наверное, самый здоровый вариант –  где-то посередине. Хотя я не уверена, что уже до конца понимаю, где именно проходит эта середина.

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

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

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

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

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

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

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

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

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

Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:

• Принятие риска (Risk Acceptance)

• Отказ от риска (Risk Avoidance)

• Митигация риска (Risk Mitigation)

• Передача риска (Risk Transfer)

Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.

Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.

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

AI Persona Lab” — конструктор цифровых личностей для бизнеса и экспертов

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

Как это работает:
Пользователь загружает свои материалы (видео, тексты, кейсы, голосовые).
AI анализирует не только контент, но и паттерны мышления.
На выходе создаётся “живая” AI-персона, которая:
— консультирует клиентов 24/7
— отвечает в стиле эксперта
— принимает решения, как он
— может вести диалоги, продажи и даже споры

Цель сделать ..оцифровку мышления эксперта” (Expert Mind Cloning)

КТО ЧТО СКАЖЕТ ?

Лайфхак по промптингу

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

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

✔️ Хотите качественный промпт и крутой результат? Тогда напишите этот промпт с помощью ИИ-чата или ИИ-агента. Вот и весь лайфхак.

Как это работает и почему?

Обычно мы обращаемся к ИИ в тех сферах, в которых сами не являемся большими экспертами. А это значит, что нам сложно составить правильный, подробный и ДЕТАЛИЗИРОВАННЫЙ промпт, который в идеале от нас и ждет ИИ-машинка для лучшего исполнения своей работы.

🥇 Например, я не художник. Я ничего не понимаю в стилях, свете, фактурах и прочем, и прочем. Но я могу сказать ChatGPT:

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

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

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

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

Конечно, я даю доступ к исходным файлам, коду и аналогичным исследованиям из прошлого. Но я не трачу на это много времени. Мой промпт занимает максимум две минуты + копирование многостраничного итогового промпта в агента в другом чате. Через час я получаю качественное и «красиво» оформленное исследование, которое приятно читать. И главное — я не потел над промптингом!

Вот такой лайфхак.

А какими лайфхаками пользуетесь вы?
—
ИИ-лайфхакер обитает в телеге Ланчев PRO ИИ

Lavern: финский юрист выложил в open source агентную правовую систему

Antti Innanen - финский юрист и LegalTech-инноватор - опубликовал на GitHub Lavern: агентную правовую систему которую его команда строила шесть месяцев. 150 000+ строк кода, 67 специализированных агентов, девять workflow. И всё это - в свободном доступе.

Его объяснение простое: «Когда стоимость создания близка к нулю, нет смысла сидеть на месте или держать это при себе». По мне - логика железная, особенно на фоне того как большинство LegalTech-продуктов тщательно закрывают всё что можно и нельзя.

Сам Antti добавляет контекст: Harvey Agents, Claude for Legal, Codex for Legal - агентный подход в юридической работе внезапно стал мейнстримом. Lavern он выпускает именно в этот момент - и называет это «open-source моментом» для права. До этого был MikeOSS, теперь Lavern. Linux тоже пришёл из Финляндии, если что.

Продукт заточен под западную правовую специфику - для российской практики нужна серьёзная адаптация. Но это не главное.

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

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

Репо и сайт Lavern - в комментариях.

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

Разработчики “Герои 3” как-то поделились лором: события игры вообще-то происходят в далеком будущем, а вся эта магия и расы - просто забытые технологии.

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

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

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

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

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

Экономика и банальная пыль.

Блины на заводах не бывают идеально чистыми. Из одного блина выходит 500 мелких кристаллов, случайная пылинка запорет два-три. Брак копеечный. Но если резать огромные куски, их на блине поместится штук десять. Одна пылинка — минус 10% партии. А если их с десяток, весь блин летит в помойку. Себестоимость такого гиганта просто улетит в космос.

Синдром утюга.

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

Скорость света.

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

Ладно, если делать один кирпич бессмысленно, почему не воткнуть в материнку два обычных процессора?

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

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

Я подумал: блин, для наших процессоров это же идеальный путь!

А потом уткнулся в реальность. Чиплеты круто работают, когда ты можешь печатать их мелкими. А у нас заводы вроде “Микрона” уперлись в 65–90 нанометров. Тайваньская TSMC, которая печатала сложную мелочь, маршрут закрыла из-за санкций.

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

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

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

Клиент не платит: пошаговый алгоритм от претензии до суда

Продолжаем серию постов о договорах и финансах.

Что делать? Действуем по шагам. Холодная голова и чёткий план.

Профилактика - лучшее лекарство от долгов

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

Способ оплаты - предоплата. Это правило на 100% избавит вас от неоплаты вашей работы.

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

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

До начала работы добавьте в договор или оферту:

⦁ Предоплату (аванс). Минимально 50-70% от суммы. Это отсекает несерьёзных клиентов и покрывает ваши базовые затраты.

⦁ Неустойку (пени) за каждый день просрочки (0,1–0,5% в день).

⦁ Штраф за отказ от подписания акта - если в течение 3-5 рабочих дней нет мотивированной претензии, работа считается принятой.

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

Если вы работаете «на доверии» и без документов - первый шаг уже пропущен. Но не всё потеряно.

Дружеское напоминание (через 3-5 дней после просрочки)

Клиент мог просто забыть. Не сжигайте мосты. Позвоните и напишите в мессенджер (и заскриньте переписку):

- «Иван Иванович, обращаю внимание, что по договору №123 от [дата] наступил срок оплаты. Прошу оплатить до [дата]. Спасибо».

Цель: зафиксировать факт просрочки и дать шанс без конфликта.

Претензия - самый важный шаг

Без неё суд не примет иск (или оставит без движения). Для арбитражного суда соблюдение претензионного порядка обязательно (ч. 5 ст. 4 АПК РФ). Для суда общей юрисдикции - не всегда, но лучше перестраховаться.

Что указать в претензии:

⦁ Кто должник (ФИО, ИНН, адрес).

⦁ Основание долга (договор, акт, переписка).

⦁ Сумма основного долга и расчёт неустойки/процентов.

⦁ Срок добровольной оплаты (например, 10 дней).

⦁ Юридическое обоснование ваших требований.

Как отправить: по ЭДО или заказным письмом с уведомлением и дублировать на e-mail/мессенджер. Главное чтобы осталось доказательство отправки.

Что даёт претензия:

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

⦁ Если не заплатят у вас есть доказательство соблюдения досудебного порядка.

Оцениваем ситуацию и перспективу судебного спора с помощью юриста

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

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

Исковое производство (есть спор):

Подаёте иск в районный суд (если клиент - физлицо) или арбитражный суд (если клиент - юрлицо или ИП).

К иску обязательно приложить:

⦁ доказательства соблюдения претензионного порядка;

⦁ доказательства выполнения работы (акты, переписка, односторонний акт);

⦁ расчёт долга и неустойки.

После суда - приставы или банкротство

Получили исполнительный лист? Направляйте в ФССП или сразу в банк должника (если знаете, что счёт один и нем есть деньги).

Если должник - физлицо и вы знаете его место работы, то исполнительный лист можно направить работодателю.

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

Главный вывод

Суд - это не страшно. Страшно ждать, когда долг станет «просроченным по исковой давности» (3 года - и всё, деньги не вернуть никогда).

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

А теперь вопрос к вам: сталкивались ли с неоплатой? Как действовали? Получилось ли вернуть деньги? Делитесь опытом в комментариях 👇

Маркетологи и пиарщики, привет! А вас не бесит, когда запускаешь кампанию в новом канале, где аудиторию понимаешь только примерно — и в итоге тратишь время, бюджет и нервы напрасно? В партнёрской программе Хабра всё иначе: вы сначала узнаёте, кто нас читает, какие форматы есть и для каких задач они подходят, а уже потом предлагаете Хабр клиентам.

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

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

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

В программе:

— разбор 10+ рекламных форматов Хабра;
— кейсы компаний из разных сегментов: «Норникель», «Самолёт», LaVivion, VIVO, «СМ-Клиника», «Гемотест», «Островок» и других;
— обучение по работе с брифом, аудиторией и подбором форматов;
— сертификат эксперта по Хабру для агентства и участников обучения.

После обучения агентство получает статус партнёра. А вместе с ним — возможность получать агентское вознаграждение от 10% до 30%, бесплатные блоги на Хабре, рост партнёрского уровня и доступ к совместным ивентам, обмену лидами и мероприятиям Хабра.

Подать заявку можно до 3 июня. Следующий набор — не раньше октября.

→ Оставить заявку на партнёрскую программу Хабра

Утечки данных в ритейле: онлайн-торговля вышла на первый план

Экспертно-аналитический центр InfoWatch опубликовал исследование «Утечки информации в сфере торговли, 2021-2025 гг.». В отчете специалисты ЭАЦ InfoWatch приводят статистику по инцидентам в мировом и российском ритейле за пять лет.

По итогам исследования:

• в мировой торговле зарегистрировано почти 5000 утечек данных, в России — 711 инцидентов;

• чаще всего утекают ПДн покупателей — более 11 млрд записей в мире и 610 млн в России;

• более половины инцидентов в России — это маркетплейсы и интернет-магазины.

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

РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа

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

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

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

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

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

✔️ Alibaba добавила анализ видео в систему синхронного перевода Qwen3.5-LiveTranslate

Китайский техногигант представил мультимодальную модель синхронного перевода Qwen3.5-LiveTranslate на базе архитектуры Qwen3.5-Omni. Система понимает текст на 60 языках и генерирует речь на 29.

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

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

Демоверсия доступна на платформе Qwen Omni. Релиз API в облаке Alibaba Cloud ожидается в ближайшее время.

https://qwen.ai/blog?id=qwen3.5-livetranslate

«Моложе с каждым годом: Как дожить до 100 лет бодрым, здоровым и счастливым» Крис Кроули, Генри Лодж

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

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

Отсюда – вынужденная осторожность моих постов про здоровье. В этой теме очень мало достоверных знаний. Хотя, в том же управлении людьми – тоже, но… Но если я, или вы прочитаете неправильную книгу по управлению, примените, то рискуете лишь потерять работу – можно найти новую. Со здоровьем такой возможности нет.

Поэтому писать буду мягонько и осторожненько. Ничего не советуя и не настаивая. Если вам в данный момент тема здоровье не интересна – смело пропускайте. Перечитаете позже.

Итак, книга. Она прям классная книга – про то, как подготовиться к пенсионному возрасту. Рассматривается три аспекта – здоровье тела, здоровье мозга, отношения с людьми (как часть здоровья и тела, и мозга).

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

Мне книжка очень понравилась. Написана интересно, с юмором, множеством примеров. И главное – очень конкретная. И цель у книги и её материала вполне конкретная, и рекомендации – тоже.

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

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

Из Книжного стека.

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

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

В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.

Если хотите закрыть базу по Linux и автоматизации

• 18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.}

• 4 июня, 20:00. «Продвинутый Bash».
  _{Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.}

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
  _{Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».}

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

• 2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
  _{Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.}

• 28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
  _{На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.}

• 18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
  _{Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.}

Если отвечаете за стабильность систем

• 1 июня, 20:00. «Мониторинг распределенных систем».
  _{На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.}

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
  _{Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.}

• 3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
  _{Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.}

Если зона ответственности включает защиту инфраструктуры

• 16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
  _{На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.}

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

ROI по внедрению AI

Как понять, что AI вообще сработает в вашем кейсе, в вашем бизнесе? Нужно считать ROI (Return on Investment) до начала внедрения.

Например, есть задача, которая занимает ~4 часа у сотрудника, сотрудник получает ~100 000 руб., его 4 часа стоят ~2500 руб. 

Сотрудник делает задачу раз в неделю. Расход ~10 000 руб. в месяц или ~120 000 руб. в год на эту задачу.

Чтобы автоматизировать эту задачу, например, надо 20 часов AI Dev средней стоимостью 3000 руб. в час. ~60 000 руб. 

Тут, если вы опытный руководитель ИТ, то надо умножить этот прогноз на число Pi, тогда будет 180 000 руб.

Получается, вы вкладываете 180k и получаете 120k, ~66% доходности. Не самая высокая, но приемлемая величина, если таких задач будет много, то вы преуспеете.

Больше по теме тут.

Продакт-менеджмент в 2026 году: почему рынку уже недостаточно «человека с идеями»

20 мая в Центре «Пуск» МФТИ прошла открытая встреча «Карьера в управлении продуктами в 2026-м: что важно знать».

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

Что еще обсуждали на встрече:

— Продакт-менеджер сегодня может работать в разных ролях. Технический продакт говорит с разработкой на одном языке и понимает архитектуру продукта. Индустриальный продакт опирается на экспертизу в конкретной сфере — например, в медицине, образовании, финтехе, логистике или B2B. Менеджер продукта по росту (Growth PM) работает с воронкой, метриками и экспериментами.

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

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

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

Сегодня продолжим этот разговор на Дне открытых дверей онлайн-магистратуры МФТИ «Управление ИТ-продуктами».

На эфире выступят академический директор программы Елена Тупикова и выпускники магистратуры — Екатерина Киселева и Дмитрий Пелик. Обсудим, как устроена программа, какие навыки развивают студенты, как проходят проекты с индустриальными партнерами и как поступить в 2026 году.

Когда: 21 мая, 18:00 по Мск. Где: онлайн. Регистрация: https://t.me/mipt_events_bot?start=c1777546389600-ds

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

ROI по внедрению AI

Как понять, что AI вообще сработает в вашем кейсе, в вашем бизнесе? Нужно считать ROI (Return on Investment) до начала внедрения.

Например, есть задача, которая занимает ~4 часа у сотрудника, сотрудник получает ~100 000 руб., его 4 часа стоят ~2500 руб. 

Сотрудник делает задачу раз в неделю. Расход ~10 000 руб. в месяц или ~120 000 руб. в год на эту задачу.

Чтобы автоматизировать эту задачу, например, надо 20 часов AI Dev средней стоимостью 3000 руб. в час. ~60 000 руб. 

Тут, если вы опытный руководитель ИТ, то надо умножить этот прогноз на число Pi 🙂 тогда будет 180 000 руб.

Получается, вы вкладываете 180k и получаете 120k, ~66% доходности. Не самая высокая, но приемлемая величина, если таких задач будет много, то вы преуспеете.

Больше по теме тут.

7 историй про профессиональный путь в IT 

Собрали истории студентов и экспертов Практикума: о том, как они меняли профессию, пробивались в бигтех, учились после работы и проваливали (а затем успешно проходили) собеседования. Полезно всем, кто в начале своего профессионального пути или только рассматривает переход в IT.

1. От джуна до тимлида за 5 лет — история роста и секреты продуктивности

Автор: Денис, тимлид в компании MedControl и старший код-ревьюер в Практикуме.

Он рассказывает, как развивался в разработке, перековал себя из программиста в руководителя и выстроил рутину, чтобы всё успевать. Сменить профессию Денис решил в 36 лет, поэтому статья может быть интересна тем, кто думает начать новую карьерную главу в зрелом возрасте. 

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

Автор: Сергей, аналитик данных в Озоне и студент онлайн-магистратуры НИЯУ МИФИ и Практикума на программе «Специалист по работе с данными и ИИ».

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

3. «Приходила уставшая, ставила таймер на два часа и училась»: как я стала DevOps-инженером

Автор: Настя, DevOps-инженер и выпускница курса «DevOps для эксплуатации и разработки». 

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

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

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

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

5. Из актрисы в бизнес-аналитика: как я выбирала новую профессию, училась и искала работу 

Автор: Лена, бизнес-аналитик в телеком-компании, выпускница курса по бизнес-анализу в Яндекс Практикуме, а в прошлом — актриса и преподавательница английского.

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

6. Не бойтесь, просто ходите: как пройти первые собеседования, если ты QA-инженер без опыта

Автор: Кристина, QA-инженер в госкомпании и экс-ревьюер курса «Инженер по тестированию» в Практикуме. 

За все время в профессии она прошла 10 собеседований, по итогам которых получила 3 офера. В этом материале Кристина рассказывает, к чему готовиться и почему главная задача новичка — не выучить ответы, а победить волнение. 

7. Много спрашиваю и откладываю встречи на последний момент: мой опыт прохождения собеседований

Автор: Ярослав, бэкенд-разработчик в компании «Синимекс» и ревьюер на курсе «Java-разработчик» в Практикуме. 

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