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

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

Мы ИТ-компания, создающая собственные продукты с высоким уровнем инженерной сложности, без зависимости от вендоров и системных интеграторов. В этой статье — честный рассказ о том, над чем мы работаем прямо сейчас и куда движемся в 2026 году.

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

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

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

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

Какие книги помогли мне перестать «тушить пожары» и начать управлять командой?

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

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

На первый взгляд идея выглядит пугающе банальной. В мире уже существуют Apple Health, Google Fit, Fitbit, сотни, если не тысячи шагомеров и фитнес-приложений. Кажется, что придумать что-то новое в этой нише уже невозможно.

Тем не менее за первый год работы проект получил около 300 000 регистраций, привлек пользователей из 104 стран и сделал примерно $930 000 оборота.

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

Привет!

Я Саша Гордеева, руковожу процессным офисом в ПСБ.

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

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

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

Проектирование систем противопожарной защиты за последние три года изменилось до неузнаваемости.Обновленные своды правил – СП 484.1311500.2020, СП 6.13130.2025, СП 3.13130 кардинально усложнили требования к зонированию объектов, расчетам резервированного электропитания и формированию огнестойких кабельных линий. Параллельно нарастает давление со стороны ТИМ: технология информационного моделирования становится обязательной для государственных объектов и все более востребованной в коммерческом секторе.

Мне кажется, у каждого управленца есть любимый дашборд. Лично мой внешне совсем не похож на “красивую BI-аналитику”.

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

— аварии в очереди;
— юридические лица в очереди;
— заявки, по которым не было звонка клиенту;
— незаполненные слоты на 9:00;
— количество техников, загруженных менее чем на 80% сегодня;
— количество техников, загруженных менее чем на 80% завтра.

Это дашборд по координации заявок, в котором можно увидеть актуальную картину по процессу прямо сейчас. Например, сегодня в одном из наших филиалов утром можно было увидеть: 12 аварии в очереди, 151 заявок без звонка, 28 незаполненных слотов на 9:00 и 9 техников, загруженных менее чем на 80% на сегодня. 

С точки зрения “красивого BI” это выглядит очень просто. С точки зрения управления — это один из самых полезных инструментов.

Готовы рискнуть вашими... проектами?

Привет, Хабр! Я Лена, аналитик Directum Projects. Риск — не мое второе имя, но в работе мне приходится сталкиваться с ним каждый день. Чего еще я хотела на ИТ-проектах :) Главное здесь — грамотный менеджмент, чтобы процесс не превратился в вождение на велосипеде без тормозов: едет быстро, падает громко.

И вот, когда мы в очередной раз летим с обрыва с оптимистичной записью «Проблем на проекте не предвидится», нам предлагают парашют — ГОСТ Р 72160-2025. Это первый в России стандарт, который на государственном уровне закрепляет количественный подход к управлению рисками.

О том, как система управления проектами поможет соответствовать новому стандарту и что делать, если риски проекта — это все еще три строки в Excel, поговорим в статье.

Когда бизнес обсуждает внедрение ИИ-бота, разговор часто быстро уходит в технологии.

Какая модель? Голос или текст? RAG или сценарий?
Как отреагирует потребитель? Сколько будет стоить разработка?
Насколько похожим на человека будет бот, или все догадаются сразу?

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

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

Звучит очевидно, но при внедрении большинство теряют главный вопрос:

Где именно в техподдержке прячется экономический эффект от ИИ-бота?

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

У большинства контакт-центров уже есть базовая отчетность.

На что обычно смотрят руководители?

— количество обращений;
— время ответа оператора;
— среднее время обработки обращения;
— время ожидания на линии;
— количество потерянных звонков;
— SLA;
— загрузку операторов;
— количество обращений по каналам.

Эти метрики действительно показывают, справляется ли команда с текущей нагрузкой. Но есть нюанс. Какой вывод делает руководитель, работая с таким дашбордом?

Например, мы видим, что:

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

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

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

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

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

Я задумал амбициозный проект, который, уверен, решит проблему взаимодействия клиентов с разработчиками, — систему управления проектами «Черный ящик» для веб-студий и разработчиков.

Суть идеи кратко: Это онлайн-система с задачами и встроенным чатом под каждый проект. Мы уходим от зоопарка из Trello, Telegram и Google Диска. Всё в одном месте. Представители заказчика приглашаются в проект бесплатно, разработчики — как свои, так и внешние — подключаются под конкретные задачи.

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

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

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

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

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

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

Меня зовут Александр Козуб, я двадцать лет в финтехе, последние несколько из них CPO. В симптомах вижу систему, об этом и пишу.

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

Запретить не можете, но управлять потоком, не запрещая, можете и, более того, должны.

В 1993 году три человека в кожанках и с распечатками бизнес-плана оккупировали задний столик закусочной Denny's в Сан-Хосе. Вокруг полицейские заполняли отчёты, а через дорогу из стены Taco Bell виднелись пулевые отверстия. Один из троих, тридцатилетний эмигрант с Тайваня, в прошлом посудомойщик, только что вытряхнул из кошелька 200 долларов на регистрацию компании, которую назвал Nvidia. Звали его Дженсен Хуанг. Стивен Витт, журналист The New Yorker, написал не биографию и не историю успеха. Он написал триллер о том, как скромный производитель игровых видеокарт захватил мир искусственного интеллекта, а его гендиректор превратился в самого влиятельного человека, о котором вы почти ничего не слышали.

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

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

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

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

Как README превращается в PR-актив: структура, нарратив, quickstart

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

Хороший продукт — это необходимое условие. Не достаточное.

Можно сделать понятный интерфейс, добавить нужные фичи, поставить конкурентную цену — и всё равно смотреть на конверсию 1,3% без понимания, что идёт не так.

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

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

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

Их несколько сотен. Пять из них убивают конверсию чаще всего.

Будущее возникает не только из технологий или новых ограничений в цифровом пространстве.

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

Например VPN, саморедактура для снижения рисков, лайки вместо ответов, mute вместо постоянной доступности. Это помогает пройти, говорить, оставаться на связи, в общем помогает продолжать движение там, где прямое и живое прохождение стало труднее.

Но со временем, то что было временной адаптацией может начать восприниматься как естественный порядок вещей, как новая Nорма.

Это первая из трёх статей про сайты под управлением ИИ. В этой части — концепции и экономика без маркетинговой пыли: что такое нейросайт на самом деле, чем он принципиально не является, и почему дешёвый VDS за пару тысяч рублей тут вообще ни при чём с точки зрения железа под нейросеть. Во второй части будет внутрянка (MCP‑брокер, пайплайн деплоя, безопасность), в третьей — прод‑механика на тысячах страниц (SSG/ISR, индексация, массовые операции). Здесь сознательно держусь на уровне архитектурных решений, не уходя в реализацию — она дальше.