Менеджмент

Как Kubernetes, Jira и Keycloak не помогли выпустить продукт

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

Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.

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

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

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

Меня позвали разобраться.

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

Когда доступ появился, меня встретила авторизация через Keycloak.

Напомню: разработчиков трое.

Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.

Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.

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

Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.

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

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

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

Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.

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

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

Забавно, что это полная противоположность истории с The Signal.

Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.

Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.

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

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

А вы в какой крайности?

Вообще, по официальным данным из Единого реестра ФНС на 10 июля 2026 года числится 6,61 млн субъектов малого и среднего бизнеса.

Всего у них работает 15,09 млн наёмных сотрудников — в среднем 2,28 работника на один субъект МСП.

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

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

Причём самого ИП без наёмных сотрудников ФНС работником не считает, и поэтому здесь показаны именно наёмные рабочие места, а не все люди, занятые в малом бизнесе.

Что делать, если ваш руководитель — чайка?
«Он появляется внезапно, громко говорит, даёт указания и исчезает. А через неделю возвращается и удивляется, почему ничего не сделано».

Супер‑стиль, особенно ощущения от общения, не правда ли?

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

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

Для команды — хаос: планы ломаются, приоритеты скачут. Ну и последствия разгребают конечно те, кто остался.

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

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

2) Переводите эмоции в вопросы. У себя, и — что сложнее — у начальствующего. Не «так опять всё сломается», а «как мы поймём, что этот подход работает?» или «что будет признаком, что его стоит остановить?». Возвращаем фокус на результат.

3) Фиксируйте решения. Если на встрече что‑то решили — запишите и отправьте краткое резюме. Сохраняем контекст, в том числе для того чтобы «поймать на слове» (да, токсичненько, но иногда — помогает).

4) Предлагайте пилоты. Вместо «ок, давайте пробовать» — «давайте проверим это на одном проекте». Остаемся в безопасной зоне, используем реальные данные.

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

А у вас был такой руководитель? Что помогало — или что точно НЕ помогало?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Три шляпы Билли Миллигана

Есть три шляпы, которые я попеременно надеваю в течение дня:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подборка книг по эффективной работе в команде

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

Собрали подборку книг, которые помогут отработать эти навыки на практике.

• «Наука общения», Ванесса Ван Эдвардс

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

• «Пять пороков команды», Патрик Ленсиони

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

• «Идеальный командный игрок», Патрик Ленсиони

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

• «Правила команды. Искусство думать вместе», Максим Поташев, Павел Ершов

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

• «Как создать настоящую команду», Дэвид Шервин, Мэри Шервин

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

T-shaped снова в моде?

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

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

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

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

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

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

Импортозамещение: «лишь бы российское» уже недостаточно

Наконец посчитали, что российский ИТ-рынок в 2025 году вырос на 13% и превысил 4 трлн рублей. Быстрее всего росли сегменты программного обеспечения и ИТ-услуг, а одним из главных драйверов оставалось импортозамещение.

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

Лицензия – только входной билет

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

• Как решение встроится в существующую инфраструктуру?

• Кто отвечает за сопровождение при сбоях и обновлениях?

• Как система восстанавливается после ошибочного изменения?

• Можно ли масштабировать внедрение без роста операционных рисков?

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

Каталог как проверка зрелости внедрения

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

• создание резервных копий и восстановление отдельных объектов и атрибутов;

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

• мониторинг массовых и ошибочных изменений;

• понятный порядок действий администратора после инцидента.

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

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

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

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

Электронная почта на Госуслугах станет официальным каналом для юридически значимых сообщений

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

Ключевые изменения:

Для бизнеса и ИП: адрес электронного ящика на Госуслугах станет обязательным реквизитом в ЕГРЮЛ и ЕГРИП.

Госорганы, ЦБ, госкомпании и юрлица с долей РФ >50% обязаны направлять юридически значимые сообщения через ЭПС (исключения: межведомственное взаимодействие, налоговый ЭДО, обращения граждан и пр.).

У всех пользователей появится возможность вести переписку через Госуслуги.

Платность: ежемесячная абонплата для ИП и юрлиц (кроме унитарных, учреждений, публично-правовых и ЦБ). При неуплате доступ приостановят. Плата за отправку сообщений - для физлиц и компаний (кроме органов власти и ЦБ). Бесплатно - для госорганов, унитарных, учреждений, а также социально значимых сообщений (пенсии, льготы, ЖКХ и т.п.).

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

Сроки вступления в силу: закон вступает в силу с 1 марта 2027 года (основные нормы). Отдельные положения - с 1 сентября 2027 года (уведомления госорганов, платежки ЖКХ).
Документ: Проект Федерального закона № 1254384-8

Ужесточение требований к трудовым мигрантам - поправки приняты в третьем чтении

С 1 января 2027 года работающие в РФ иностранцы должны будут содержать себя и членов семьи на уровне не ниже прожиточного минимума. ФНС ежеквартально передаёт данные о доходах в МВД с 1 октября 2026 года. При отсутствии данных или доходе ниже норматива патент не выдадут либо аннулируют - иностранцам с детьми придётся выехать за 15 дней (исключение - при первом оформлении). Низкий доход за год может стать основанием для отказа или аннулирования РВП.

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

Что ещё меняется с 1 марта 2027 года: порог зарплаты для ВКС вырастет почти в 3 раза - до 717 тыс. руб. в месяц (сейчас 750 тыс. за квартал). Для отдельных категорий - 358,5 тыс. руб. Суммы будут индексировать ежегодно.

Документ: Проект Федерального закона № 1158407-8

Банки вправе заключать договоры жилищных сбережений с 1 января 2027 года

Появится новый вид договора. Банк принимает деньги от гражданина, начисляет проценты и возвращает их с процентами при оплате жилья, ДДУ или ИЖС.

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

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

Жилищные сбережения застрахованы - размер возмещения 100% от суммы депозита, но не более 10 млн руб.

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

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

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

Заёмщик сможет указать, что ему нужны каникулы максимум на 1,5 года. День их окончания не должен быть позже даты, когда второму или каждому следующему ребёнку исполнится 1,5 года.

Документы - свидетельство о рождении/усыновлении или удостоверение многодетной семьи. Мера доступна и по старым договорам. Заёмщик выбирает: приостановку платежей или уменьшенный платёж. Максимум - 15 млн руб., предмет - единственное жильё.

Хорошая мера поддержки для семей с детьми.

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

А что вы думаете об этих изменениях?👇

Забирать или оставлять

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

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

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

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

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

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

Семь бед — пихай нейросеть

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

Человек думает, как это упростить, и ответ в последнее время всегда один — внедрить нейросеть. Человек идёт к начальству, получает одобрямс и начинает внедрять LLM, но с наскока и в лоб это не срабатывает — нейросеть врёт, теряет контексты, делает не то и не так.

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

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

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

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

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

Как так‑то? Как‑то так...
Что помешало человеку погуглить спросить у тех же нейросетей, как решать задачу? Нейросети знают про Вики, Конфлюэнс и Постгресс... Что? А бес его знает...

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

Хочу сделать своего бота для монетизации платного контента в 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)»?

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

Пользователю не нужен умный ИИ. Ему нужен предсказуемый результат

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

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

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

Проще всего это объяснить через людей.

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

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

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

Как мы на это напоролись: документооборот для бухгалтеров

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

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

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

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

Тогда мы перестроили пайплайн.

Теперь бухгалтер с помощью ИИ не делает документ. Он с помощью ИИ пишет программу, которая делает документы по шаблонам — и работает всегда детерминированно.

Разница выглядит тонкой, а меняет всё:

• Написал программу один раз корректно — она будет корректно отрабатывать всегда. Не «в 95% случаев», а всегда.

• Написал некорректно — можно указать на ошибку, она поправится, и правка тоже закрепится навсегда.

• Вылез corner case, в котором программа должна вести себя иначе, — поправил, и это осело на уровне программного кода, а не на уровне промпта.

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

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

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

Что это даёт бизнесу

Главное — предсказуемость, а вместе с ней доверие. Пользователь перестаёт играть в рулетку и получает систему, которая ведёт себя одинаково. Ошибка становится не поводом разувериться в ИИ, а обычным багом: нашли, поправили, закрепили.

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

Так у нас и заработала двухуровневая структура. Наверху — умная, творческая, непредсказуемая LLM. Внизу — тупая, надёжная, предсказуемая программа. Каждый на своём месте и занят тем, что умеет.

Принят закон об ИИ - что меняется для бизнеса и разработчиков с 2027 года

Ранее обсуждали законопроект Минцифры о использовании ИИ.

Закон об ИИ принят в окончательном чтении

8 июля Госдума приняла закон об ИИ. Он вводит базовые понятия и правовую рамку. Фокус сместился с регулирования на поддержку развития.

Что регулируется и что попадает под действие закона

Закон действует только для больших фундаментальных моделей (БФМ) - с 1 млрд параметров. Малые и open-source системы под него не попадают.

Что такое большая фундаментальная модель:
⦁ программа для выполнения интеллектуальных задач на уровне человека или выше
⦁ использует алгоритмы и обучается на составах данных
⦁ содержит не менее 1 млрд параметров
⦁ является основой для создания и доработки различных видов ПО

Категории моделей ИИ

Закон вводит два понятия: суверенная и национальная большая фундаментальная модель.

Суверенная модель:
⦁ разработчик - российское юридическое лицо
⦁ разработка на всех стадиях осуществляется этим российским юрлицом
⦁ обеспечивается полная техническая воспроизводимость цикла разработки, включая обучение
⦁ подготовка ответов и хранение данных - в ЦОД на территории РФ, принадлежащих российским юрлицам
⦁ модель прошла подтверждение соответствия законодательству РФ и традиционным российским духовно-нравственным ценностям

Национальная модель:
⦁ разработчик - российское юридическое лицо
⦁ существенные характеристики определяются и изменяются российским разработчиком
⦁ допускается использование компонентов по открытой лицензии (включая иностранные open-source решения)
⦁ подготовка ответов и хранение данных - в ЦОД на территории РФ
⦁ модель прошла подтверждение соответствия законодательству РФ и ценностям

Ключевое отличие: суверенная модель должна быть создана "с нуля" российским разработчиком с полным контролем всех этапов. Национальная может использовать open-source компоненты.

Маркировка ИИ-контента

Закон разрешает маркировку ИИ-контента. Владельцы крупных сайтов (500+ тыс. пользователей в сутки) обязаны дать пользователям возможность ставить предупреждение об ИИ.

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

Интеллектуальная собственность при обучении ИИ

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

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

Сроки вступления в силу

С 1 сентября 2026 года - Основные положения закона (базовые понятия, цели, принципы)
С 1 марта 2027 года - Требования к суверенным и национальным моделям, обязанности разработчиков, полномочия Правительства, маркировка ИИ-контента
До 1 сентября 2032 года - Переходный период для уже внедрённых систем ИИ (при условии обработки данных на территории РФ)

Что важно для целевой аудитории

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

Для ИТ-компаний: для прикладных open-source решений барьеров нет. Если разрабатываете БФМ под господдержку - потребуется подтвердить статус.

Иностранные модели и API не запрещены, но в отдельных сегментах могут стать неприемлемыми.

А что вы думаете об этом законе? Планируете ли использовать ИИ в своей деятельности? Делитесь мнением в комментариях 👇

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

Потом перешёл на недельные циклы и мне зашло.

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

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

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

Но в целом для небольших команд недельные циклы работают лучше. По крайней мере у меня.

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

Совместный календарь

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

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

Инструкция для Google Календаря:

1. Создать отдельный календарь. Можно назвать его «Вася+Маша» и назначить специальный цвет событий, чтобы отличать от личного календаря.

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

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

4. Включить синхронизацию созданного календаря в iPhone/CalDAV.

Совместный календарь позволяет:

• держать в одном месте все общие события: концерты, ужины, поездки;

• избежать ситуации, когда два события назначаются на одно и то же время;

• разносить личные дела во времени, когда дети ещё маленькие, и кто-то должен оставаться дома;

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

Теперь ты тимлид: роль, майндсет и границы ответственности

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

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

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

Три направления работы тимлида

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

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

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

Границы ответственности и принятие решений

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

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

• discovery составляющая — продакт-оунер, дизайнер, аналитик, редакторы и т. д.;

• техническое руководство — руководители разработки и функциональные руководители направлений; 

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

• смежники: соседние команды, партнеры, HR-функция, административный персонал и т.д.

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

От теории к практический кейсам

В следующих статьях мы рассмотрим наиболее распространённые ситуационные кейсы:

• Варианты старта: тимлид в новой команде или в существующей.

• Целеполагание: как планировать, когда всё горит и ничего непонятно.

• Команда и люди: офферы, лоу-перформинг, увольнение, друзья, лояльность.

• Процессы: «и так нормально», бюрократия, эксперименты.

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

• Сложные ситуации: конфликты, смена продукта, откат обратно в инженеры, микроменеджмент.

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

Почему хорошие вопросы ценятся не меньше хороших ответов

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

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

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

Спрашиваем «как», не разобравшись с «зачем»

❌ «Как нам реализовать эту фичу?»

✔️ «Какую задачу решаем этой фичей? Есть ли другие способы?»

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

Не проверяем, был ли похожий опыт в команде

❌ «Как правильно настроить X?» 

✔️ «Кто-нибудь в команде уже настраивал X или сталкивался с похожей задачей?»

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

Не даем контекста

❌ «У меня ошибка, можете помочь?»

✔️ «Получаю ошибку X при действии Y. Уже проверил A и B, но проблема осталась. Вот лог / скрин / ссылка. Подскажите, где еще посмотреть?»

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

Просим оценку, когда нужна обратная связь

❌ «Правильно ли я сделал?»

✔️ «Что можно улучшить в этом решении? Есть ли риски, которые я не учел?»

Вопрос «правильно ли?» часто сводит ответ к короткому «да» или «нет». Но в работе важны нюансы: возможные риски, альтернативы, слабые места. Если сразу попросить не оценку, а обратную связь, обсуждение получится полезнее.

Не задаем фокус для ответа

❌ «Что думаешь?»

✔️ «Посмотри, пожалуйста, логику: понятно ли, какую проблему решаем и почему предлагаем именно такое решение?»

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