Менеджмент

Сколько я плачу за AI инструменты и как они у меня взаимосвязаны

Claude — мой основной AI инструмент уже как 9 месяцев — Плачу за него 100$

Состоит из Claude Desktop, Claude Code UI и Claude Code CLI

Если хочу работать в приятном UI с текстом → Claude Desktop
Если работаю локально с кодом → Claude Code CLI
Если хочу поправить код с телефона → Claude Code UI

Коротко что все это такое
• Claude Desktop — как чат GPT, но с поддержкой MCP + Skills и еще всякими штуками
• Claude Code — UI для работы с вашим репозиторием
• Claude Code CLI — Command Line Interface Агент. По сути это микс Claude Desktop + Claude Code по функционалу, но без интерфейса и работает внутри вашего компьютера. Мое любимое развлечение последних двух месяцев

Claude Code CLI — пока что самый прокачанный на рынке CLI агентов

———

OpenAI, который chatGPT — за него плачу 20$

• ChatGPT UI — им почти перестал пользоваться, только ради генерации картинок иногда залетаю. Они после недавнего релиза стали их генерировать на уровне с Nano Banana
• Codex UI(Аналог Claude Code) — UI для работы с вашим репозиторием
• Codex CLI (Аналог Claude Code CLI) — чуть менее прокачанный как Command Line Interface, но зато их модель Codex 5.2 Extra-high уделывает OPUS 4.5 в плане UI дизайна и продумывания/рефакторинга сложных вещей

Но в Codex CLI вроде как отсутствует аналог ESC + ESC из Claude Code CLI для откатки написанного кода, без него тяжко жить 🍌

OpenAI недавно признали то, что их гонка с Claude за тем, чтобы сделать лучший кодинг агент, привела к тому, что 5.2 потеряли человечность в общении и стали сильно более директивными и сухими

Это помогает при работе с кодом, но общаться с ней сложнее

———

Экосистема Google — плачу 8$ за Plus подписку

Google у меня для трёх вещей: картинки через Nano Banana, NotebookLM и Antigravity для просмотра кода. Халява за 8$

• Nano Banana, иногда Veo 3 для генерации картинок / видео — лучшие генераторы картинок / видео на рынке
• NotebookLM — прикольный RAG UI, всем советую потестить
• Antigravity — Fork VS Code по типу Cursor, но с продвинутым Agent Workflow. Есть доступ к Gemini Pro + почему-то Claude моделям. Плюс Antigravity может генерировать картинки сразу вам в код через Nano Banana, такой вот бесшовный воркфлоу

Ни Gemini UI ни Gemini CLI я особо не пользуюсь. Мне они кажутся сильно сырыми по сравнению с Claude Code | GPT

———

Как выглядит мой воркфлоу

Claude Desktop для задач, где мне хочется иметь приятный UI и фичи именно Desktop интерфейса. Например написание постов, создание табличек, графиков и всего такого — те задачи, где CLI сильно проседает по UX

Claude Code UI почти не использую, только когда нужно изменить репозиторий с телефона, например на улице или в поездке

Claude Code CLI — мой day to day tool для работы с кодом. Пишу на Opus 4.5. Для сложных задач прошу создать промпт для Codex.

Antigravity юзаю для просмотра кода и папок, иногда запускаю Gemini 3 pro как третье мнение

Codex, как я уже и говорил, требует особого навыка общения. так как она может думать по 40 минут и перековырять вам весь код, но зато она у меня всегда находит те корнер кейсы, которые не находит ни Opus 4.5 ни Gemini 3 pro. По стилю общения вы будто общаетесь с Сеньёром, который вас презирает, зато резалт пушка

———

Прикольные фишки, которые я постоянно применяю

1. Через Antigravity прошу генерировать изображения со вставкой сразу в код, получается бесшовный воркфлоу Prompt => Generation => Insertion

2. Используй Claude CLI Opus 4.5 для Day to Day задач

3. Используй Codex CLI xhigh для задач на рефакторинг или поиск corner cases, он сильно тщательнее это делает

4. Планируя новую фичу, проси Claude создать локальный MD с планом, а затем Codex xhigh + Gemini 3 pro пусть покритикует этот план и напишет ниже свои комменты

5. Не забывай про кнопку ESC + ESC в Claude Code CLI

6. Claude Code CLI в начале сессии загружает себе CLAUDE.MD, Codex загружает в себя AGENTS.MD, а Gemini — GEMINI.MD.

7. Команда /context покажет контекст текущей сессии, старайся держать его как можно ниже
   Good context engineering means

Однокоренные слова, но...

Класс защиты и класс защищенности – это не одно и то же. Более того, ранжирование у них идёт в разных направлениях. Они лишь звучат похоже.

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

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

МВД требует от информационной системы подтверждения соответствия по шкале класса защищенности на уровне их ГИСа – это К1. При этом обмен данными в СМЭВ идёт по защищенной сети, участники которой используют криптосредства класса защиты КС3.

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

Так в чём разница?

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

Класс защищенности (К1 > К2 > К3) – это шкала, которая применяется к государственным информационным системам (ГИСам). Чем выше число в обозначении, тем слабее. Данный класс относится ко всей информационной системе целиком (процессы, меры, средства защиты информации, сегментация, доступы, аудит, уязвимости, контроль, аттестацию и т.д.).

Определена эта шкала приказом ФСТЭК РФ от 11 апреля 2025 г. N 117 (вступает в силу с 01.03.2026 г.). Цитирую:

Самый низкий класс - третий, самый высокий - первый. Класс защищенности информационной системы (первый класс (далее - К1), второй класс (далее - К2), третий класс (далее - К3)) - определяется в зависимости от уровня значимости информации (далее - УЗ), обрабатываемой в этой информационной системе, и масштаба информационной системы.

Класс защиты (КС1 < КС2 < КС3 < КВ1 < КВ2 < КА) – это классы средств криптографической защиты информации (СКЗИ) – то есть стойкость к атаке и условия применения конкретной криптозащиты (VPN, криптошлюз, криптопровайдер, шифрование канала и т.п.), а не про защищенность всей информационной системы. И тут наоборот: чем больше цифра, тем сильнее.

Градируется класс защиты по модели атак приказами ФСБ РФ от 18 марта 2025 г. N 117 и от 27 декабря 2011 г. N 796:

• КС1 – базовый класс: атаки вне контролируемой зоны, то есть нарушитель не имеет доступа в помещение, где размещены СКЗИ;

• КС2 – сильнее: атаки в пределах контролируемой зоны, но без физического доступа к СКЗИ;

• КС3 – еще сильнее: атаки в пределах контролируемой зоны с физическим доступом нарушителя к СКЗИ;

• КВ – более высокий класс: высококвалифицированный нарушитель использующий недокументированные возможности ПО;

• КА – наивысший класс: высококвалифицированный нарушитель использующий недокументированные возможности как ПО, так и железа.

P.S.: Наличие или отсутствие циферки у "КВ" и "КА" зависит от конкретного документа и упоминаемых в них СКЗИ.

Как запомнить и не перепутать?

Средства криптозащиты это лишь часть информационной системы, тогда как второе более широкое понятие. И чтобы не запутаться, проще всего запомнить разницу по длине слова: "защита" – короткое слово, значит, узкая тематика, относящаяся к классификации СКЗИ, "защищенность" – длинное слово, то есть более широкое понятие, относящееся к классификации информационных систем.

– – –

С вами был Неминущий Никита, ведущий инженер‑программист финансового маркетплейса «Выберу.ру»

🎬 Видео с новогоднего CTF по мультиагентным системам

🎯 Что внутри:
Разбираем создание и применение AI-агентов для узких задач + настройку взаимодействия между ними

📊 Детали:
Автор: Андрей Чуян @Andrey_Chuyan
Направление: AI-инжиниринг
Сложность: 4/10
Формат: CTF (Capture The Flag)

🔗 Где смотреть:
VK - https://vk.com/video-232485571_456239027
YouTube - https://youtu.be/kVnOxzG0zEM?si=SFvBpDGOlMxrEdsf

💬 Есть вопросы?
Обсуждаем в чате → https://t.me/DebugSkills_chat

Межведомственная комиссия (МВК) по 115-ФЗ: как подать жалобу на банк или Банк России?

Межведомственная комиссия (МВК) — это второй уровень реабилитации, куда можно обратиться, если не удалось решить вопрос напрямую с банком или Банком России.

Важное правило: без прохождения первого уровня (см. посты 1 и 2) ваше заявление в МВК не примут.

Что МВК рассматривает? (Основные случаи):

1. Отказ банка в открытии счета или операции (если банк сам оставил свой отказ в силе).
2. Применение банком жестких мер (блокировка операций по п.5 ст.7.7 115-ФЗ). Это обязательный досудебный этап!
3. Отказ Банка России изменить высокий уровень риска.

Что МВК НЕ рассматривает?

Обжалованию в МВК не подлежат:

⦁ Ограничение дистанционного банковского обслуживания (интернет-банка) и блокирование банковской карты.
⦁ Отказ в выпуске или перевыпуске банковской карты.
⦁ Расторжение договора банковского счета по инициативе банка (в случае двух и более отказов в проведении операции в течение года по п. 11 ст. 7 закона № 115-ФЗ).
⦁ Длительное рассмотрение банком заявления о расторжении договора банковского счета.
⦁ Взимаемые банком комиссии и его тарифная политика.
⦁ Решения об отказе от заключения договора банковского счета (вклада) или проведения операции, принятые не по основаниям пунктов 5.2 и 11 статьи 7 закона № 115-ФЗ.
⦁ Решение об отказе в предоставлении кредита.
⦁ Отнесение Банком России клиента к группе средней степени риска.
⦁ Решения об отказе, принятые на основании пунктов 2 и 8 статьи 7.2 закона № 115-ФЗ.
⦁ Решения уполномоченных органов (например, Росфинмониторинга) о приостановлении операций.

Как подать заявление в МВК?

Заявление подается через Банк России одним из способов:
1. Через интернет-приемную ЦБ (выбрать тему «Обращение в МВК»).
2. По почте или лично в экспедицию Банка России в Москве.

Требования к заявлению:

⦁ Должно строго соответствовать Положению Банка России № 842-П.
⦁ Нужно приложить огромный пакет документов (по разным приложениям к Положению 842-П в зависимости от случая): полные данные о компании, финансовая и налоговая отчетность, сведения о контрагентах, копии всех предыдущих обращений и отказов.
⦁ Срок рассмотрения МВК: не более 20 рабочих дней + еще 3 дня на уведомление вас о решении.

Что дальше?

Решение МВК можно обжаловать в суде. Если вы одновременно подадите и в МВК, и в суд, приоритет будет у суда, а МВК откажет в рассмотрении.

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

Привет, Хабр!

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

Сначала главные причины:

• Критичные изменения (смена руководства и т.д.)

• Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени

• Неконтролируемая волна хотелок (НВХ)

• Неготовность к изменениям - внутренним и внешним

• Неправильный выбор подрядчика, чрезмерное доверие или недоверие.

Ещё причины, вытекающие из основных

• Непредоставление информации Заказчиком.

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

• Отсутствие технического планирования (железо)

• Чрезмерно сжатые сроки

• Не хватает денег

• Неотлаженные бизнес-процессы

• Проблемы с данными

Также нашёл и такие "причины", о них в статье планирую специальный комментарий:
Внедрение без обследования
Отсутствие или изменение целей
Неправильно выбранная проектная методология
Незаинтересованность руководства Заказчика

Буду благодарен всем, пополнившим коллекцию.

Еще один способ организовать рабочие чатики

Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.

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

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

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

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

Группировка

Грех номер один при работе с электронными таблицами — ручная группировка данных.

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

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

Как избежать ручной работы? Использовать группировку по столбцам в Google Sheets:

1. Собрать один длинный список сотрудников.

2. Добавить и заполнить столбцы Отдел и Город.

3. Преобразовать список в таблицу.

4. Нажать на стрелку рядом с названием столбца «Отдел» и выбрать «Столбец "Основание группировки"».

5. Сохранить получившийся фильтр под названием «Сотрудники по отделам».

6. Проделать аналогичную операцию для столбца «Город».

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

К сожалению, в Excel такой функции нет.

Что с Релизом ?!

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

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

За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).

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

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

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

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

Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)

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

Всем добра и тихих релизов !

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит, не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, – уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
Модное слово для процесса организации групповой работы
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

Качественное обновление и снижение расходов на ERP: 3 и 5 февраля ICL SOFT проведет вебинары для бизнеса

3 февраля в 11:00 руководитель отдела разработки 1С ICL SOFT Владимир Капитонов проведет вебинар на тему «Технология успеха: качественное обновление сильно доработанных решений ERP/ERPУХ». Спикер разберет пошаговую методологию безопасного перехода на современные версии ERP и ERP УХ, а также расскажет, как превратить сложное обновление в управляемый и технологичный процесс. Участие бесплатное по регистрации.

5 февраля в 11:00 руководитель отдела сопровождения 1С ICL SOFT Мария Ефремова проведет вебинар «Как сократить расходы на ERP на 30%». Участники узнают, почему стоимость владения ERP выходит из-под контроля, какие есть эффективные инструменты для снижения затрат и как спрогнозировать бюджет и повысить качество сервиса. Участие также бесплатное по регистрации.

Импортозамещение по-бразильски.  

Пост из серии «никогда бы не подумал». Если попросить назвать крупных производителей самолётов, то скорее всего (не беря советских/российских конструкторов) услышишь названия Boeing, Airbus и Embraer. И вот про последнего я всегда думал, что это какая-то европейская компания, пока не узнал, что это аббревиатура Empresa Brasileira de Aeronáutica. Стереотипно, но я в жизни бы не подумал, что именно Бразилия всего за несколько десятилетий создала одного из лидеров авиапромки.Немного оправившись от удивления, я, само собой, решил понять, как такое вообще получилось и что стало причиной такого вертикального роста:

1. Embraer начиналась как госкорпорация в 1969 году (что по меркам такой индустрии не то чтобы очень давно), которую запускало правительство и ВВС Бразилии. Там люди поняли, что зависимость от авиагигантов — дело опасное и надеятся на то, что Boeing и Airbus не будут выкручивать руки целой стране - вообще не стоит. Ну и при этом страна гигантская, и её концы надо как-то соединять, чтобы удаленные участки не оказались отрезанными от ключевых хабов и центров. Причём желательно соединять их дёшево и надёжно, так как экономическая ситуация в Бразилии не самая простая.

2. В итоге был быстро создан простой и надёжный турбовинтовой самолёт EMB 110. Модель была настолько крутой, что её начали активно покупать американцы, французы, канадцы. Особенно для того, чтобы перевозить пассажиров из малых городов и связывать хабы с малыми локациями. Самолёт был небольшим, неломким и очень рентабельным по сравнению с монстрами Boeing и Airbus. Сыграло роль правильное ТЗ. Нужно было не чудо на крыльях, а рабочий инструмент, который закроет базовые потребности перевозки. Плюс ко всему у руля проекта стоял Озорио Сильва — инженер, военный лётчик и фанат авиации, собственно, что и позволило сделать крутой продукт.

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

4. Параллельно с этим между Boeing и Airbus была война гигантов. Они как одержимые пытались переплюнуть друг друга в огромных лайнерах, игнорируя небольшие самолёты. Ребята из Embraer быстро поняли, что спрос — вот он, и запустили E-Jets, которые быстро решили головную боль многих авиаперевозчиков, которым вообще не нужны были джеты на 300 мест. Принцип был похожий с первым их проектом: надёжно, дёшево и удобно для пассажиров.

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

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

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

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

Высокий уровень риска ЦБ: как оспорить статус в Банке России самостоятельно?

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

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

ШАГ 1: Проверьте свой статус.

⦁ Узнать, попали ли вы в список высокорисковых, можно через специальный сервис на сайте Банка России.

ШАГ 2: Подайте заявление о пересмотре уровня риска напрямую в Банк России.

⦁ Это можно сделать через интернет-приемную на сайте ЦБ, выбрав тему «Обращение в Банк России о пересмотре высокого уровня риска».

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

⦁ Срок ответа Банка России: 15 рабочих дней с момента получения заявления.

Возможные решения ЦБ:

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

⦁ Оставить свое решение в силе (отказать в изменении статуса).

Что дальше?

Если Банк России отказал, у вас есть право в течение 6 месяцев обжаловать этот отказ в Межведомственную комиссию (МВК) или сразу обратиться в суд.

Рекомендация: Требования к заявлению в ЦБ строго регламентированы (Указание № 6853-У). Неправильно составленное обращение приведут к отказу. Лучше всего обратиться к опытному юристу для подготовки убедительного и технически грамотного пакета документов, чтобы с первого раза добиться снятия статуса.

Количественные и качественные индикаторы достижения Product-Market Fit

Product-Market Fit (PMF) — это качественное состояние продукта, которое невозможно измерить какой-то одной метрикой. Однако его достижение или приближение к нему можно верифицировать с помощью комплекса исследований и ключевых показателей.

1. Качественные исследования или «Тест на сожаление»

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

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

Интерпретация: Если доля респондентов, ответивших «Очень разочарован», составляет 40% и более, это считается ярким сигналом наличия PMF.

2. Индекс лояльности (Net Promoter Score, NPS)

NPS измеряет готовность клиентов рекомендовать ваш продукт другим людям. Методология предполагает оценку по 10-балльной шкале в ответ на вопрос: «Насколько вероятно, что вы порекомендуете наш продукт коллеге или знакомому?»

• Сторонники (Promoters): 9-10 баллов.

• Нейтралы (Passives): 7-8 баллов.

• Критики (Detractors): 0-6 баллов.

Расчёт: NPS = (% Сторонников) – (% Критиков).

Интерпретация: Положительный и растущий NPS указывает на формирование лояльности, что является косвенным признаком PMF. Высокий NPS (>30) часто коррелирует с устойчивым ростом.

3. Коэффициент удержания (Retention Rate)

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

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

4. Операционные и бизнес-метрики роста

Достижение PMF запускает органический рост, который отражается на операционной и финансовой деятельности:

• Устойчивый рост ключевых метрик (выручки, числа клиентов) без пропорционального увеличения маркетинговых затрат (CAC).

• Высокая конверсия на всех этапах воронки, особенно из лида в платящего клиента.

• Превышение жизненной ценности клиента (LTV) над стоимостью его привлечения (CAC) в 3 и более раза.

• Возникновение органических каналов роста: "сарафан", прямые заходы, упоминания в профильных сообществах.

• Операционная масштабируемость: поток заказов/запросов начинает требовать расширения команды и оптимизации процессов. Иными словами, проснулись, и поняли - уже не справляемся с потоком заявок. Это точно "оно!"

Заключение
PMF - это зона, вход в которую подтверждается конвергенцией сразу нескольких сигналов: высокие качественные оценки пользователей, растущая лояльность (NPS), здоровая кривая удержания и, как следствие, — устойчивая и эффективная с точки зрения unit-экономики модель роста. Системный мониторинг этих индикаторов позволяет командам объективно оценивать прогресс на пути к рыночному фитнесу.

Почему IT продукты дорожают но их реальная ценность падает?

Почему так происходит и справедливо ли это по отношению к пользователю?

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

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

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

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

Продают обманом – Бизнес выстраивает маркетинг на псевдоценностях. Для этого он подменяет понятия и запутывает клиента, чтобы он не понял что эта фича несет ценность только для бизнеса, а для него нет. И ведь это не всегда происходит осознано! Иногда бизнес обманывает и сам себя выпуская таки фичи в релиз (.
Не будем упоминать недобросовестное списание денег по причине "потому что мы так решили"

Но самое абсурдное это когда бизнес решает проблему которую сам и создал :(

Пример
В пятёрочке постоянно крутят объявления в аудио формате. Недавно я услышал такую запись – пятерочка заботится о вас, поэтому мы дарим вам пять минут тишины. Сами создали проблему, сами ее решили, а выдают за ценность.

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

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

Вывода в этом посте нет, этот просто открытое рассуждение.

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

Если хотите упаковать ценности вашего продукта качественно, записывайтесь на бесплатную консультацию, тут на Хабре https://career.habr.com/product-unit

Как понять, к чему мы стремимся?

Всегда ли техническая стратегия очевидна с самого начала? Может ли простой инженер с крутой идеей переубедить топ-менеджеров? Стоит ли идти напролом, если уверен в своей правоте? Как «продать» идею внутри компании и где искать вдохновение для неё?

Гость нового выпуска подкаста «Свободный слот» — Анатолий Панов, CTO Яндекс Карт. Вместе с ведущими Пашей Федотовым и Сашей Афёновым обсуждаем, по каким признакам понять, что пора создавать техническую стратегию. Говорим также о смелом решении — смене основного стека технологий в компании — и о том, как его выигрышно провести. А в финале выясняем, кого в первую очередь нужно убедить в стратегии и какие процессы в итоге должны поменяться.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как я планирую неделю за 5 минут с Claude + TickTick на реальном примере 🙃

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

⚠️ Important

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

Вот как выглядит диалог с Claude от голосового до записей в календаре ⤵️

👱 «Закинь эти задачи в TickTick на неделю, можешь еще примерно приоритет важности поставить»
🤖 «Ок, создал 17 задач, распределил по дням, расставил приоритеты»
Дополнительно Claude уточнил у меня: «Для лендинга мне от тебя нужны даты старта. И еще, механика ранней цены — по местам или по дате?»

Т.е. он не тупо поставил задачи, но и еще доспросил по тем вопросам, где нужно уточнение

👱 «Размажь эти задачи по времени дня релевантно»
🤖 Распределил задачи по рабочему дню: утро и день — мелкие задачи, вечер — вдумчивые. Как ты любишь.

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

👱 «Поставь релевантную длительность»
🤖 Проставил start/end для каждой задачи: статья — 3 часа, обновить цены — 30 минут, встреча — 1.5 часа.

Чтобы это были не просто todo в календаре, а именно что занятые тайм слоты

👱 «Распиши по SMART в описании»
🤖 Добавил в каждую задачу S/M/A/R/T — что сделать, как понять что готово, почему реально, зачем нужно, дедлайн.

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

Все работает через Claude Desktop => Tick Tick MCP => Tick Tick

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

Вот в итоге все задачи проставлены, интерфейс календаря не открывал

Clawdbot: Первые впечатления: Страшно Интересно

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

Clawdbot — это AI-ассистент нового поколения, который работает как личный цифровой помощник с глубокой интеграцией в вашу систему. Представьте себе Jarvis из фильмов Marvel, только реальный и доступный прямо сейчас.

Первое впечатление: дофамин зашкаливает

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

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

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

У меня огромный опыт в IT. За годы работы я перестал бояться «Большого Брата» и утечек данных — принял риски, научился жить с компромиссами между удобством и безопасностью.

Но теперь страх вернулся.

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

Цена настоящего Jarvis

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

Google-экосистеме

• Gmail (вся переписка, личная и рабочая)
• Google Docs (документы, таблицы, презентации)
• Google Calendar (весь график, встречи, планы)
• Google Drive (годы накопленных файлов) Тонны конфиденциальной информации: контракты, финансовые данные, личные записи, проекты.

Файловой системе компьютера

Полный доступ к:

• Исходному коду проектов
• SSH-ключам и паролям
• Личным файлам
• Истории браузера
• Всему, что есть на диске
Это не преувеличение — ему нужен такой доступ, чтобы быть полезным. Иначе он просто ещё один чат-бот.

Новая точка атаки: ваш AI — это master key

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

Раньше модель угроз была относительно простой: каждый сервис — отдельная цель для атаки.
Взломали Gmail? Получили доступ к почте.
Взломали GitHub? Получили код.
Взломали соцсеть? Получили аккаунт.

Теперь появляется единая точка отказа.

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

Представьте:

• Взлом через prompt injection — злоумышленник находит способ повлиять на поведение бота через специально сформированный текст в email или документе
• Компрометация конфигурации — если кто-то получит доступ к файлу конфигурации Clawdbot, он получит все ваши API-ключи и токены сразу
• Уязвимость в самом боте
• И этот список можно продолжать.

Вот в чём парадокс:

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

Мои мысли

Я ещё не готов дать ему всё. Но я вижу, куда это идёт. Clawdbot — это не просто инструмент, это предвестник новой эры, где AI-ассистенты станут неотъемлемой частью нашей цифровой жизни. Набрать 20к звезд за сутки, гудеть из каждого утюга, боюсь как бы это не было чем-то, чем был первый СhatGPT, когда он ушел в паблик.

Вопрос не в том, стоит ли давать доступ. Вопрос в том, когда мы будем готовы это сделать — и какие границы установим. И что ещё важнее: как мы будем защищать этот новый master key.

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

Я считаю, что это захватывающе. Это страшно. Это будущее.

Нейроменеджмент: почему IT-компании отстают в продажах

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

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

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

Вот как на самом деле работает покупка IT-решения:

1️⃣ Клиент чувствует эмоцию (облегчение, безопасность, статус)
2️⃣ Только потом мозг включает логику и проверяет факты
3️⃣ В конце проверяет социальное доказательство - "это делают другие?"

Если вы начинаете с фактов, клиент уже отфильтровал вас на первом этапе.

Развитие IT-фирмы через нейроменеджмент:

• Менеджеры закрывают сделки на 40-60% быстрее

• Клиенты становятся лояльными и рекомендуют вас

• Команда работает с меньшим стрессом

• Компания растёт естественным образом

Это не манипуляция - это наука о мозге, применённая к бизнесу.

Нейроменеджмент в IT-продажах - это не опция, это необходимость в 2026 году, когда конкуренция беспощадна.

Готовы трансформировать вашу IT-компанию?

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

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

Данные есть, ясности нет: как принимаются сложные решения в IT

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

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

Когда информации достаточно, но решения всё равно «ломаются»

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

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

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

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

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

Почему опыт и интеллект не всегда спасают

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

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

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

О паузе как инструменте управления

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

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

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

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

Почему это важно в IT (и не только)

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

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

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

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

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

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

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

Как быть, если команда боится просить помощи, даже когда тяжело?

Я сталкивалась с этим в своей команде: каждый видел, что у других завал, и считал, что жаловаться неуместно. Начала проговаривать на общих созвонах, что просить помощи — нормально, это не слабость. Потом попробовала сама писать в личку с конкретными вопросами. До сих пор периодически пишу: «Привет! Вижу, что у тебя много задач. Давай заберу какую-нибудь?» и почти всегда в ответ получаю ссылку на задачу, которую можно передать. Ведь принять помощь гораздо проще, чем просить о ней самому.

Что делать, если в команде очень разные стили работы?

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

Как говорить о повторяющихся ошибках, чтобы не потерять доверие?

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

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

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

→ Подробнее своим опытом Вика поделилась в статье.