Менеджмент

Новое в законодательстве: отключение связи по требованию ФСБ, скидки через MAX и изменения в оплате ЖКХ

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

ФСБ сможет инициировать отключение связи

С 3 марта 2026 года вступил в силу ФЗ, который обязывает операторов связи приостанавливать оказание услуг по требованию органов ФСБ в случаях, которые установит Президент РФ .

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

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

Документ: Федеральный закон от 20.02.2026 № 33-ФЗ

Скидки и льготы: продавцов обяжут принимать подтверждения через MAX

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

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

Документ: Постановление Правительства РФ от 17.02.2026 № 148

Сроки оплаты ЖКХ изменились с 1 марта

С 1 марта 2026 года вступили в силу поправки, которые унифицируют сроки оплаты жилищно-коммунальных услуг. Теперь платить за жилье и коммуналку за прошлый месяц нужно до 15-го числа текущего месяца включительно . Раньше срок был до 10-го числа.

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

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

Документ: Федеральный закон от 24.06.2025 № 177-ФЗ

Защита прав потребителей: запрет на списание без согласия

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

Исполнитель обязан обеспечить возможность отказа потребителя от подписки, в том числе в электронной форме.

Документ: Федеральный закон от 15.10.2025 № 376-ФЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

–––––––––––

Мой ТГ канал

Как перестать быть центром всех решений и не потерять контроль :)

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

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

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

1️⃣ Что происходит, когда процессы держатся на одном человеке

Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.

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

2️⃣ Три страха, которые мешают передавать процессы

Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:

1. Я стану не нужна

2. Перегружу команду

3. Команда что-то сделает не так

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

А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.

3️⃣ Как мы перестроили систему консультаций

Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.

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

• Опытные аналитики по каждой заявке

• Скриптолог дня для базовых техвопросов

• Техлиды для сложных техвопросов

• Третья линия как финальная инстанция

В этой схеме больше нет обязательного шага «спросить у Кати» :)

Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это, и дала возможность сказать, если что‑то не работает.

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

4️⃣ Как мы перестали тратить часы на планирование дежурств

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

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

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


Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.

5️⃣ Как быть с кризисными ситуациями

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

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

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

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

Плагин Tasks. Часть 2

Запросы - еще одна мощная возможность плагина. Пишутся на нативно понятном языке. Позволяют: 

1. Отфильтровать задачи из вашего хранилища по срокам, папке, содержимому

2. Настроить отображение задач в заметке 

Например, чтобы отобразить все невыполненные задачи со сроком (due date) сегодня, достаточно прописать в блоке кода:

tasks 
not done 
due today

⚠️ Чтобы запрос заработал, прописываем его в блоке кода, выделяемом символами “```”

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Product Focus Club 2026 — конференция о будущем продуктов и бизнеса в эпоху AI

Product Focus Club приглашает предпринимателей, собственников бизнеса, топ-менеджеров, C-level, продуктовых лидеров и HR-директоров на закрытую конференцию нового формата, которая пройдет 17–18 апреля 2026 года в Москве, а также в онлайн-формате.

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

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

В программе конференции:

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

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

• практические воркшопы и мастер-классы;

• консультации и модерационные сессии;

• нетворкинг с предпринимателями и топ-менеджерами.

4 ключевых трека Product Focus Club 2026:

1. Продуктовая и бизнес-трансформация

2. Лидерство и команда в кризис

3. Стратегия прорыва и точки роста

4. AI & тренды

Основные темы:

• будущее продакт-менеджмента;

• стратегии роста и устойчивости бизнеса в 2026 году;

• продуктовые команды и культура;

• искусственный интеллект как источник конкурентных преимуществ.

В 2025 году конференция собрала более 250 участников и 30+ спикеров из компаний: Т-Банк, Сбер, VK, Альфа-Банк, Яндекс, Газпром Нефть, Авито, МТС, S7 Airlines и других.

Организатор конференции – Product Lab, обучение для компаний и отдельных сотрудников.

Регистрация открыта, количество мест ограничено.

Как снизить риски блокировки счета: правила финансовой гигиены для бизнеса

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

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

Соблюдайте финансовую дисциплину

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

Своевременно сообщайте об изменениях в ФНС и банк

При изменении сведений в ЕГРЮЛ/ЕГРИП (ОКВЭД, участники, директор, адрес) уведомите налоговую и банк. Несвоевременное обновление грозит блокировкой.

Проверяйте достоверность записей в ЕГРЮЛ и ЕГРИП

Налоговая проверяет сведения, особенно адрес. При недостоверности вносят запись в реестр. Если запись висит более 6 месяцев, компанию могут исключить из ЕГРЮЛ.

Подробно заполняйте платежные документы

Не пишите просто «по договору» или «за товар». Указывайте конкретно: за какие товары, работы или услуги, реквизиты договоров, счета, спецификации.
Попросите контрагентов делать так же. Прозрачные платежи - меньше вопросов от банка.

Оперативно отвечайте на запросы банка

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

Не дробите бизнес без необходимости

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

Минимизируйте наличные расчеты

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

Не снимайте крупные суммы наличными

Любое значительное снятие наличных сразу привлекает внимание банка. Если операция необъяснима с точки зрения бизнеса, последуют вопросы.

Сохраняйте все документы при наличных расчетах

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

Проверяйте контрагентов до начала работы

Смотрите: есть ли суды, исполнительные производства, долги по налогам (сервис «Прозрачный бизнес»), достоверность адреса и уровень риска на платформе ЗСК. Работа с недобросовестными контрагентами повышает риск блокировки ваших операций.

Платите налоги

Отсутствие или незначительный объем налоговых платежей по счету - тревожный сигнал. Банк может посчитать, что бизнес работает «в серую», и повысить уровень риска.

Не открывайте счета «про запас»

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

Правильно оформляйте отношения с работниками

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

Эти правила не гарантируют, что банк никогда не задаст вопросов, но значительно снижают риск попадания в «красную зону». Банки ценят прозрачных и дисциплинированных клиентов.

А на какую тему вы хотели бы подобную серию постов в будущем?
Пишите в комментариях.

Как будет выглядеть рабочий день инженера в 2029 году?

Ответ на этот вопрос можно найти в подкасте руководителя клиентской разработки RUTUBE Максима Ульянова. В гостях — Артём Арюткин, CPO платформы для разработчиков в Авито.

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

Из выпуска вы узнаете:

▪Чем CPO в DevEx отличается от CTO и зачем платформе продуктовый подход?
▪Что входит в техническую платформу Авито и почему важен принцип iPhone для разработчика?
▪Почему онбординг — это не «приятный бонус», а одна из ключевых метрик DevEx?
▪Зачем нужна технологическая стратегия и в каких бизнесах она реально избыточна?
▪Какие метрики первыми стоит начать считать для эффективности инженерных команд?
▪Почему платформы в крупных компаниях похожи и какие этапы развития они обычно проходят?
▪Каким компаниям нужна платформа и что меняется на масштабе 100 vs 500 инженеров?
▪Почему IT-индустрия «не зрелая» и какие ответы давно найдены в других отраслях?
▪Что такое «счастье разработчика» и почему его проще всего услышать в «разговорах у кулера»?
▪Почему в эпоху GenAI платформы могут стать ещё важнее?

Приятного просмотра и прослушивания!

Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активах «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.

Понял когда можно начинать увольнять сотрудников!

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

• Как усиление человека

• Как замена человека в процессах

1. ИИ как “экзоскелет”

В этой роли ИИ выступает в качестве персонального ассистента или “второго пилота”. Сотрудник выполняет свои функции, но использует нейросети для ускорения рутины, преодоления ограничений или усиления экспертизы. 

Плюсы подхода:

• Низкий порог входа: Часто это просто подписка на сервис.

• Гибкость: Сотрудник сам решает, когда и как включить экзоскелет. 

• Контроль качества: Человек остается в контуре, фильтруя галлюцинации и ошибки ИИ.

• Удовлетворенность сотрудников: Позволяет сосредоточиться на творческих и сложных задачах.

Ограничения:

• Привязка к человеку 1:1: Производительность конкретного сотрудника растет, но прямого снижения затрат не происходит.

• Зависимость от навыков: Эффективность зависит от цифровой грамотности сотрудника.

• Отсутствие системности: Результат может быть неравномерным по отделам, а знания могут оставаться в головах, а не в регламентах.

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

2. ИИ как “автономные агенты” (Цифровые сотрудники)

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

Плюсы подхода:

• Масштабируемость: Можно “нанять” тысячи цифровых сотрудников быстрее, чем обучить живых людей.

• Скорость: Агенты работают 24/7 и обрабатывают информацию в разы быстрее человека.

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

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

Почему этот подход сложен:

• Должна быть зрелость процессов: Бизнес-процесс должен быть описан, формализован и оцифрован. Автоматизировать хаос невозможно - ИИ его только приумножит.

• API и доступ к данным: У агента должен быть легальный и безопасный доступ к информационным системам компании. Критически важно четко разграничить уровни доступа агента.

• Система валидации: Ошибки должны отлавливаться автоматически, либо процесс должен строиться по принципу Human-in-the-loop (человек проверяет ключевые действия перед финальным одобрением).

Итог

Экзоскелет делает конкретного сотрудника сильнее и быстрее здесь и сейчас. Автономный агент делает бизнес в целом сильнее и независимее от количества человеческих ресурсов.

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

Мы психанули и скрестили аналитику маркетплейсов с аналогом MS Office. И пока отдаем это бесплатно.

Знаете, что больше всего бесит в торговле на Ozon и Wildberries? Не штрафы. И даже не платные приемки. Бесит зоопарк вкладок в браузере.

Вот типичный рабочий стол селлера или менеджера маркетплейсов:

1. В одной вкладке открыт сервис аналитики (за который отдано от 15 до 30 тысяч рублей в месяц).

2. Во второй — тяжеленный Google Sheets или Excel, куда менеджер руками копирует цифры, чтобы свести юнит-экономику.

3. В третьей — PowerPoint или Word, потому что инвестору или партнеру нужно красиво показать отчет за квартал.

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

Спойлер: мы не нашли нормального ответа. Поэтому пошли пилить YouStat.

Что мы сделали

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

Получилась единая экосистема:

• Аналитика уровня топов рынка. Сводная аналитики, разбор SKU, abc-анализ, бот для ответов на отзывы.

• Свои «Таблицы». Аналог Excel, который живет прямо внутри сервиса. Не нужно скачивать CSV-файлы и перекидывать их туда-сюда. Нашли прибыльную нишу — тут же в соседней вкладке раскидали юнит-экономику.

• Свои «Документы» и «Презентации». Полноценные редакторы. Собрали данные, упаковали в красивый отчет для инвестора, сохранили историю версий.

• И сервис для ведения бухгалтерии

P.S. Скоро докатим свои ИИ-шечку

По сути, мы сделали российский аналог MS Office, который «из коробки» умеет глубоко анализировать Ozon и WB.

В чем подвох и почему бесплатно?

Если вы завсегдатай VC или Хабра, у вас уже должен был сработать внутренний радар: «Очередной стартап обещает золотые горы бесплатно. Наверняка будут продавать мои данные или через неделю выкатят пейволл на 50к».

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

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

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

Мы открываем полный доступ к YouStat абсолютно бесплатно для всех ранних пользователей. Нам нужны бета-тестеры. Нам нужны люди, которые придут, начнут собирать свои таблицы, парсить конкурентов и... ломать наш продукт. А потом писать нам в саппорт: «Ребята, вот тут кнопка съехала, а вот тут таблица долго грузится».

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

Что дальше?

Сейчас сервис работает и открыт для регистрации. Никаких привязок карт, никаких скрытых триалов на 3 дня.

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

Ссылка на проект: youstat.tech

Заходите, тестируйте, ломайте. Буду рад ответить на любые вопросы в комментариях, поймать тапки за баги и выслушать конструктивную критику. Мы на связи!

Продуктовая разработка с агентами, замена agile-команд и роль продакт-инженера — эти и другие темы я обсудил с Юрой Агеевым, основателем ProductSense, в новом выпуске подкаста make sense.

Слушайте на удобной платформе: 
> Telegram 
> Mave 
> Apple 
> Яндекс Музыка
> YouTube

Таймкоды:
00:00 — Введение
01:58 — Личный сетап агентов, эксперименты и первые сценарии
03:34 — Почему тема агентов — это про орг. модель, а не про игрушки
06:05 — Откуда взялся Agile: ответ на рост сложности продуктов
09:10 — Идея мини-команд для быстрого тестирования гипотез с агентами
11:10 — Риски одиночки: туннельность, критика, фактор автобуса
12:05 — Платформенная команда: стандарты, «золотой путь» и «ворота качества»
14:05 — Зависимость централизации от культуры компании
16:12 — Продакт-инженер: продукт и инженерия в одном цикле
17:32 — Схлопывание ролей: инженеры учат продукт, продукты учат технику
19:33 — Практика пайплайнов в работе с агентами: сначала документация, потом код
26:03 — Контекст как главная ценность и способ удержания клиентов
29:01 — Один в поле не воин: почему запуск и масштаб важнее кода
30:28 — Можно ли доверять агентам?
33:54 — Конкуренция заставит ускоряться: когда агенты станут нормой?
35:55 — Практика внедрения агентов: выделенные пилоты и команды добровольцев
37:35 — Главные риски: стоимость токенов и деградация навыков
42:09 — Как будут трансформироваться процессы и agile-роли?
50:57 — Как правильно строить эксперимент: задачи, команды, обучение и метрики

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

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

Сам по себе PMF - это не метрика, в количественном виде измерить его нельзя. Фаундер/фаундеры обычно чувствуют его, что называется, “кожей”: начинаешь понимать, что не справляешься с обработкой заявок, тебе очень сильно начинают требоваться рабочие руки, телефон “горит”...  Но важно: PMF можно предвидеть. Некоторые цифры и результаты исследований покажут это.

Итак: 

Опросите ваших клиентов. Подготовьте небольшую анкету и пообщайтесь с теми кто уже купил ваш продукт. В идеале лучше разделить тех, кто купил единожды и тех, кто неоднократно возвращался к покупке. Самое важное, что тут нужно понять: ощутит ли клиент разочарование, если ваш продукт вдруг исчезнет? Если число тех, кто остро ощутит отсутствие вашего продукта приближается к половине опрошенных (40%), значит, вы близки к PMF.

Посчитайте NPS. Еще один показатель, который можно учитывать в рамках работы с PMF — это NPS, Net Promoter Score. Этот индекс показывает, насколько ваши покупатели готовы рекомендовать продукт своим друзьям и знакомым. Чтобы вычислить этот показатель, клиентов просят оценить, какова вероятность того, что они порекомендуют продукт друзьям и знакомым по 10‑балльной шкале. В зависимости от поставленной оценки, опрошенные делятся на “адвокатов бренда”, “нейтралов” и “критиков”. NPS — это разница между процентами критиков и процентами “адвокатов” бренда. Если число положительное, значит, клиенты склонны “хвалить” продукт. Если отрицательное — продукт не нравится.

Изучите Retention. Это значит “удержание”, когда клиент приобретает привычку пользоваться вашим продуктом. Для разных ниш и продуктов частота “возвращения” будет разной. Проследите, растёт ли у вашего продукты число “постоянщиков”?

Дополнительными показателями PMF также являются простые метрики по типу роста продаж, роста дохода. Если вы, как я уже писал выше,  перестаете справляться с потоком заказов и вынуждены нанимать больше сотрудников, если появляются хвалебные отзывы, лиды всё активнее превращаются в сделки — значит это PMF или вы близки к нему.

Мысли про создание AI-агента, который будет помогать с "Важно, но не срочно" задачами. Часть 1

Последний месяц в сети хайпит OpenClaw (он же ClawBot, он же MoltBot).

У него есть доступы много куда — вы наверняка уже видели новости о том, как он самостоятельно тратит деньги или общается с женой (не своей)

Но меня интересует механизм работы его core feature — проактивности

Это первый масштабный агент, который не ждёт сообщения, а сам приходит и говорит: «Эй, я вот это сделал, глянь»

Я хотел собрать такого агента ещё год назад, когда обнаружил и начал исследовать Model Context Protocol, который дал моим LLM-кам доступ во внешний мир. Но тогда не хватило ни знаний, ни механизма.

Сейчас, благодаря OpenClaw, Claude Code + Codex стало понятнее, как именно это можно реализовать

И вот последнюю неделю я понемногу развиваю этот концепт

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

Суть в одном предложении
AI-агент, который знает мои цели на год и выполняет первые, самые сложные 15% работы, которые приведут меня к этим целям в долгосрок.

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

И чаще всего проблема не в том, что я не знаю, что делать, а в том, что мне впадлу начать

Ресёрчить варианты. Разбираться в деталях. Сделать первый шаг. Вот эти первые 15% — самый проблемный шаг для меня

Поэтому я подумал — а что если агент будет делать именно это?

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

Представьте, что агент каждый день приходит к вам с такими сообщениями

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

SEO и органика
Я опять помониторил SEO твоего сайта и сайты конкурентов. Советую сделать A, B, C, D, чтобы мы подросли в органике. Вот конкретные правки с приоритетами

Контент и кросс-постинг
Твой последний пост на LinkedIn набрал 10К просмотров — тема зашла. Давай этот пост ещё и в Threads, Instagram и на Хабр адаптируем? Вот три черновика под каждую площадку

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

Мониторинг конкурентов
[Конкурент] вчера выкатил новую фичу — вот что изменилось. Это может повлиять на позиционирование твоего продукта. Вот 2 варианта, как отреагировать: адаптировать лендинг или написать пост-сравнение.

Портфолио и резюме
За последний месяц ты закончил 2 проекта и написал 4 поста. Вот обновлённая версия секции «достижения» для LinkedIn-профиля и сайта. Опубликуешь?

Здоровье
Ты 4 месяца переносишь задачу "Записаться к стоматологу. Поэтому я решил действовать и нашел 3 клиники рядом с тобой с рейтингом выше 4.5, у двух есть слоты на эту неделю. Записать?

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

То есть агент не просто читает календарь — он понимает, что ему чего-то не хватает, и сам приходит за недостающим контекстом

Я хочу, чтобы агент не просто напоминал по моим задачам в календаре, а ресёрчил → структурировал → предлагал конкретный микро-шаг → спрашивал «актуально ли?»

Хочу чтобы конвертировал мои абстрактные хотелки из раздела «Важно, но не срочно» в конкретные day-to-day actions.

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

Пока это концепт. Но направление, в котором я копаю, кажется мне одним из самых интересных применений AI-агентов — не делать за тебя, а снимать барьер старта и помогать тебе двигаться к твоим Long Term Goals — по типу коуча/ментора

У подобного агента будут доступы к интернету и моему календарю. А общаться мы с ним будем через Telegram — видимо, как и с OpenClaw

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

Во второй поделюсь наработками и инсайтами

Маркетолог сливает 30% прибыли. И даже не краснеет...

Маркетингу ставят план по количеству и цене квалов.

А теперь давайте зададим маркетологу вопрос: "Сколько прибыли мы заработали с тех квалов, которых ты привел в прошлом месяце?"

Готов поспорить на ящик коньяка, он не ответит. Девяносто процентов маркетологов живут в мире “охватов, кликов, заявок”. Они не видят воронку дальше квала. И крутят рекламу вслепую, потому что не знают, кто, сколько и когда покупает.

Дальше — веселее. Спросите РОПа и маркетолога: «Что такое квалифицированный лид?» Гарантирую, ответы будут очень разные.

Маркетолог приводит человека с вопросом про цены. Продажники говорят: "Это мусор, напрягаться не будем". Это и есть та самая дыра в воронке, куда улетают до 30% лидов, продаж и прибыли.

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

Система квалификации лидов BANT+TSL (Google Таблица).

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

Когда задача считается выполненной

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

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

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

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

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

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

4. Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

Стоит ли давать разработчику второй шанс? Кейс об «эффекте бумеранга»

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

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

В такой ситуации тимлиду важно отделить эмоции от управления.

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

• Что изменилось в его ресурсе и фокусе?

• Появилась ли внутренняя мотивация вместо внешней?

• Готов ли он брать ответственность за результат, а не просто закрывать тикеты?

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

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

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

А как вы относитесь к «бумерангам»? Стоит ли входить в одну и ту же реку дважды, или в ИТ это не работает?

Как крупнейший брокер перенес 200 серверов и 100 ТБ данных в российское облако без потерь и неожиданностей

💼 Что за компания

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

🕵️ Задача

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

«Ренессанс Брокер» переносил системы с известными нагрузками, поэтому опирался на конкретные цифры производительности базы данных и сети:

• для транзакционных запросов должно сохраниться среднее время отклика,

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

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

👨‍💻 Решение

На пилотном этапе брокер сосредоточился на тестировании фундаментальных сервисов Cloud.ru Advanced: виртуальных машин, блочного хранилища и объектного хранилища стандартного и холодного класса хранения. Тестирование подтвердило, что инфраструктура Cloud.ru соответствует текущим требованиям к производительности. Это стало одним из аргументов для принятия решения о начале полномасштабной миграции, так как позволило гарантировать бизнесу отсутствие ухудшения в работе критически важных приложений и баз данных.

Сроки миграции в облако Cloud.ru были спланированы и реализованы в два этапа. На приоритетную миграцию закладывали 2–3 месяца. Второй этап по плану должен был занять около 6 месяцев: за это время надо было не просто перенести системы, но и архитектурно их усовершенствовать, например, переехать на новую версию ПО или изменить стек с одной СУБД на другую, включая критически важное разделение зарубежной и российской инфраструктур для соответствия новым регуляторным и законодательным требованиям. 

📈 Результаты

Миграция полностью уложилась в запланированный срок. Все сервисы, включая 200 серверов и 100 ТБ данных, были перенесены с минимальным временем простоя. Изменения затронули практически всех сотрудников компании. Для них переход был максимально прозрачным и свелся в основном к смене адресов для подключения: они продолжили работать с уже знакомыми системами, но уже в новой среде.

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

Другой важный результат — сохранение и укрепление высокого уровня SLA в новой среде: брокер обеспечил выполнение строгих требований к доступности и полную сохранность данных.

Подробнее о кейсе на сайте

Плагин Tasks. Часть 1

Этот плагин лежит в основе моей системы планирования.

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

1. Создаём в заметке задачу:

- [ ] Задача

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

3. С помощью палитры команд или горячих клавиш открываем расширенные настройки. Там можно сделать задачу повторяющейся.

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

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

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

"Знание некоторых принципов избавляет от необходимости знания многих фактов"

Эту прекрасную фразу приписывают Гельвецию (хотя и не только ему).

Автора попытался указать, поэтому можно переосмыслить так, как мне еще больше нравится:

"Знание базовых принципов помогает сэкономить на множестве неудачных экспериментов"

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

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

</скрип суставов>