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

Представьте себе классическую ситуацию: финансовый директор смотрит на два отчета по выручке за прошлый год. Один отчет, построенный в старой системе, показывает 150 миллионов рублей, другой — в новой корпоративной CRM — демонстрирует 145 миллионов. Разница в 5 миллионов, а вместе с ней и ощущение, что новая система «врет» и вводит всех в заблуждение. Начинается поиск виноватых, и, как это часто бывает, крайними оказываются ИТ-специалисты, якобы «неправильно настроившие миграцию».

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

Современные методологии управления данными, в частности Slowly Changing Dimensions (SCD) или «Медленно меняющиеся измерения», предлагают элегантный и проверенный способ справиться с этой иллюзией, превратив хаос непрерывных изменений в стройную, аналитически ценную картину.

Недавно мне попался комментарий к этой статье, который задаёт правильный вопрос точнее многих академических работ по типологии. Его позиция такова: типологии — это инструменты, которые люди конструируют, чтобы договориться о единой системе координат. Их сходство не говорит о том, что они открывают одну реальность — оно говорит о том, что они решают одну задачу. И строить их, по его мнению, надо на объективном фундаменте — законах физики, конкретно термодинамики. Это смелый ход. И в нескольких ключевых точках — неверный.

Вот сам тезис, который меня зацепил:

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

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

В интернете можно найти кучу рекомендаций по продвижению, но это все теория. А я сейчас расскажу вам про реальность. Разнесу все площадки по фактам: что работает, а на что можно даже не тратить время.

Быстро собрать прототип страницы, чтобы использовать его для постановки задачи команде. AI не вместо разработчиков, а в помощь Product Owner.

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

Анатолий Панченко пришёл на конгресс с одним вопросом: «Какой у меня тип?». Тринадцать специалистов посмотрели на одного и того же человека. Тринадцать дали разные ответы. Никто не ошибался умышленно. Все были квалифицированы.

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

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

ИИ не устранил необходимость в менеджменте. Он устранил часть оправданий.

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

В статье разбираем, как подойти к запуску AI/ML-продукта без иллюзии «сейчас прикрутим LLM и всё взлетит»: от проверки боли и выбора use case до MVP, первых метрик и типичных ошибок, которые хоронят проекты ещё до выхода в прод.

Когда команда запускает витрину продукта — каталог, рекомендации или подборки, —  почти сразу возникают вопросы: «Будут ли пользователи что-то из неё скачивать или покупать и какая будет конверсия?»

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

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

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

«Изучи конкурентов» и «eat your dog's food» — это само собой. Но что делать дальше, когда база пройдена, а понимание домена всё равно не складывается в рабочую картину?

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

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

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

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

Если склонности (модель HEXACO) отвечают на вопрос «как вы работаете?» - быстро или вдумчиво, индивидуально или в команде, с готовностью к риску или по инструкции, - то ценности дают ответ на вопрос «зачем?». Ради чего специалист встаёт утром и открывает пул-реквест.

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

Если вы прямо сейчас думаете, внедрять вам ИИ или нет, то сначала ответьте себе: а вы уже посчитали ROI?

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

С каждым погружением мы видим, что практически все исследуемые матрицы похожи на одну из 8 метафор:

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

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

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

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

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

В моей старой статье про устройство BNPL (сентябрь 2022, «Оплата долями или при чём здесь исламский банкинг») основной тезис был такой: BNPL — это обходной путь регулирования. Сервис рассрочки делает ООО, не подпадающее под 353-ФЗ, не передающее данные в БКИ, и зарабатывает на комиссии магазина. Государство закрывало глаза на существование схемы, пока сегмент не перестал быть маленьким.

В 2025 году рынок BNPL в России дорос до 940 млрд рублей (данные «Долями» от Т-Банка), за первое полугодие удвоился. Так появился 283-ФЗ от 31.07.2025 «О деятельности по предоставлению сервиса рассрочки», вступивший в силу 1 апреля 2026. Что в законе: реестр операторов, лимит 50 000 ₽, срок до 6 месяцев (с 2028 — до 4), запрет скрытых комиссий, передача в БКИ при долге свыше лимита, неустойка не более 20% годовых (потолок — оператор может взять и ноль).

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

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

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

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

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

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

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

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

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

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

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