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

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

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

Самый точный инструмент для диагностики — модель HEXACO. Она объясняет, почему один тимлид безупречно работает в финансах, а другой — в секьюрити, и оба чувствуют себя в своей тарелке.

Когда живешь в такой команде, твой базовый вопрос — какие проекты делать, чтобы метрики выросли. Нам тогда рассказали, что есть такие ICE/WSJF/… Потом мы поняли, что на нашем уровне энтропии такие штуки — полная чушь (и дальше расскажу, почему). Встал вопрос, как иначе выбирать, какие проекты брать в работу.

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

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

Внедрение ERP-систем подразумевает изменение бизнес-процессов компании. Организация вынуждена принять такой способ выполнения операций, как это изначально задумано и реализовано вендором в программном решении. Особенность состоит в том, что процессы в информационной системе уже оптимизированы и унифицированы, тем самым имплементация решений класса ERP является одним из наиболее распространенных способов усовершенствования бизнес-процессов. В данном случае мы говорим о реинжиниринге бизнес-процессов [1].

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

Можно попытаться разобраться в крайностях реинжиниринга, используя свод знаний по корпоративной архитектуре, представленный методологией TOGAF [2], который говорит о том, что во главе всего должна стоять прежде всего бизнес-архитектура. Именно через ее призму необходимо рассматривать все происходящее в компании и ИТ-архитектуре, в частности. Более детальное погружение в тематику бизнес-процессов обратит нас к набору знаний BPM CBoK [3].

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

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

Ребята из ViralMaxing прошли этот путь на предыдущем проекте — привлекли у инвест-фонда 30 миллионов, успели влить пару миллионов в платный трафик, экономика не сошлась, проект заморозили. А потом сделали новый сервис и раскрутили его через закрытые телеграм-клубы. Вход — 5000 рублей.

Передаю слово основателю — Илье Дрозду.

В ноябре наш сервис ViralMaxing закрыл 6000 долларов ежемесячной выручки. К марту вышли на 15 000. Нас двое плюс помощница: я занимаюсь клиентами и маркетингом, мой партнёр Лёша пишет весь код. Инвестиций нет, рекламу не покупали. Расходы на инфраструктуру — около 1200 долларов в месяц.

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

В этой статье разберём, как считать ROI AI/ML‑проекта без самообмана: от baseline и полного TCO до adoption rate, value drivers и риск‑поправок, которые быстро превращают красивую экономику пилота в куда более приземлённую модель.

Карьерный консультант сказал «сфокусируйся».

Я сфокусировался: через 22 методики стратегического анализа, 31 экспертное интервью, финмодель, 64 сценария и год работы в Executive Master in Management ВШЭ.

Получил:

— Прогнозную NPV +8,7 млн ₽ на горизонте 24 месяцев
— Стратегию из трёх измерений (где играем, чем играем, через какой канал)
— Защиту выпускной работы на 10/10

Работы пока нет.

Метод — да. Гарантий — нет. Уверенность — да.

Это статья о том, как корпоративный стратегический инструментарий (PESTEL, Porter, VRIN, финансовое моделирование) работает применительно к карьере. И почему уверенность в методе и неуверенность в результате прекрасно живут вместе.

Внутри: 22 методики, 5 промоделированных сценариев, разбор «проблемы периметра» для интровертов‑управленцев, и одна неудобная мысль про то, что в 2026 году поиск работы перестал быть операционной задачей.

Теги: product management, risk management, marketplace, telecom, customer experience, pre-mortem

Коротко о главном

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

В этой части (1 из 2) — продуктовый и аналитический разбор без технических деталей. Я покажу, как сервис отработал на 3 реальных кейсах из недавней истории российского рынка: тарифы у мобильных операторов, штрафы для партнёров маркетплейса и одновременный ребрендинг с запуском премиального направления. Два из трёх кейсов в реальности закончились публичным конфликтом, действиями ФАС, забастовкой партнёров или их сочетанием. Третий — на бумаге выглядел как идеальный кандидат на скандал и был так помечен сравнительным baseline-прогнозом обычной языковой модели — но в реальности прошёл без материального ущерба. Сервис правильно отранжировал материальные кейсы в верхней части риска, а спорный «двойной» — в нижней, и всё это до того, как ему сообщили исход.

Сервис проверяли на двух последовательных ретроспективных слепых прогонах: первый — 6 кейсов, расширенный — 20, всего 26 кейсов российского рынка. Cуммарно когортный слой правильно классифицировал 26 из 26 исходов; обычный сравнительный baseline-прогноз большой языковой моделью — 22 из 26, в остальных 4 случаях принял громкий, но переносимый негатив за материальный провал. На последнем 20-кейсовом расширении ранжирование разделило набор без ошибок: верхние 10 — все материальные кейсы, нижние 10 — все без материального ущерба. Это пилотный сигнал, а не финальное доказательство.

### Cursor как общая среда для заказчика и разработчика

Google влил в Anthropic сорок миллиардов, Cursor "собрали" браузер на GPT-5.2, а я начал писать код совместно с заказчиком.

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

А что если показать заказчику как работать с Cursor и использовать ИИ-агентов?

Есть клиент. Он предприниматель и у него бизнес в недвижимости, при этом он не программист, - он не пишет backend, не проектирует схемы БД, но он очень хорошо знает своё дело и это важнее, чем кажется.

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

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

Небольшой мысленный эксперимент на стыке машинного обучения и продуктового менеджмента. О том, почему одна и та же задача «определить, что нужно клиенту» может выглядеть по-разному со стороны product'а и data scientist'а. Разбор на примере корпоративного ДМС, где у одного контракта сразу три стейкхолдера с разными работами.

Вводная: почему эта тема вообще возникла

Я много лет проработала начальником управления аналитики в страховой компании, а сейчас прохожу курс Ивана Замесина по Advanced JTBD. В какой-то момент на воркшопе меня зацепила структура, которую он назвал «графом работ» — и я поймала себя на мысли, что она похожа на знакомую мне из Data Science модель. Только с противоположным назначением.

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

Эван Шпигель, сооснователь и CEO Snapchat, редко даёт интервью. Недавно он подробно рассказал, как его компания с миллиардом пользователей пережила 15 лет копирования их новых фичей конкурентами. Snapchat не просто выжили, они изобрели Stories, свайп-навигацию и AR-фильтры, которые клонировали все остальные соцсети. Шпигель объясняет, как ИИ меняет правила игры в продуктовой разработке и почему важно фокусироваться на дистрибуции продукта.

Кен Гриффин, основатель Citadel (по состоянию на начало 2026 года, Citadel признан самым прибыльным хедж-фондом за всю историю, и управляет больше чем 60 миллиардами долларов) рассказал о том, как компания формирует культуру победителей и как не задохнуться от бюрократии, когда у тебя тысячи сотрудников.

С конца 2025 года РКН подал не менее 8 исков против крупных разработчиков игр. Но эта статья — не про игры. Точнее, не только про них.

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

Четвёртая статья из серии. Предыдущие: манифест, итерация 0, итерация 4 убита.

В прошлом посте я закончил так:

> Эту работу агент не сделает. Реализовать — сделает. Придумать — моя задача.

С того поста — 20 часов и 20 коммитов. На код пришлась небольшая часть. Основная — на методику.

Что не сработало в первой версии

Схема была такая: пользователь отвечает → маленькая LLM классифицирует «вопрос + ответ» в массив сигналов с весами → сигналы накапливаются → детерминированный код назначает карту по порогу.

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

Что такое методика в моём случае

Разобрал доклад Anthropic «Prompting 101» и собрал из него рабочую схему сборки промптов. С веб-сервисом и готовым Project для Claude.ai

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

Тогда, стоит напомнить, что магия вне Хогвардса запрещена 🙃

Я регулярно вижу одно и то же: в компанию вливаются бюджеты, заходят дорогие и не очень консультанты, рисуются красивые схемы (но, чаще некрасивые). Процессы переписываются. Люди — нет.

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

Раньше можно было приписать «Agile», и добавить x100 к стоимости, сейчас лучше выбрать «AI». Хе‑хе.

Штат раздувается. Роли множатся. Ответственность размывается. Это как поменять море на океан, но продолжать плыть с дыркой в лодке.

Самое неприятное: вы ещё и платите за это 🙂

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

За две статьи меня успели оклеветать: копирайтером, который вылез из тени своего спеца и ИИшкой:

Как победить хаос изменений в 1C, SAP и микросервисах? Авторская модель управления изменениями через Задания на разработку (ЗНР) и Релизные контейнеры, которая синхронизирует бизнес-процессы и код, предотвращая сбои в сложном ИТ-ландшафте.

Моя рабочая практика сложилась таким образом, что почти всю жизнь я проработал в стартапах самых разных отраслей, и моей задачей было вывести компанию на приемлемый зрелый уровень. Здесь следует сразу обозначить, что именно я подразумеваю под стартапом, поскольку различных определений много. Итак, стартап - это организация, которая не понимает, что именно она делает, на чём она зарабатывает. Стартап - не обязательно молодой бизнес. Бывают компании, которые не выходят из состояния стартапа и 5 лет, и 10 лет.

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

Таблица 1. Стадии развития организации

Если погуглить «payment hierarchy», найдёте десяток исследований TransUnion за 15 лет. Они отслеживают одну вещь: в какой последовательности заёмщик с несколькими долгами уходит в просрочку, когда денег на всё не хватает.

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

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

У нас всё ровно наоборот.