Менеджмент

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

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

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

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

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

Я почти не пишу код руками. Вообще. Наговариваю мысли в транскрибатор, кидаю сырой поток в сессию агента и иду дальше. Весь день в терминале Claude Code и Codex: проекты, фриланс, какие‑то побочки, всё туда. Три подписки по $200 в месяц плюс пара китайских по мелочи. Да, я понимаю, как это звучит, но речь не про деньги, к деньгам ещё вернёмся, и не в мою пользу.

И вот на этом фоне история про слепую веру модели читается не как чужая. Это просто моя обычная среда, доведённая до абсурда.

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

Ни фига она не освобождает. Наоборот.

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

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

Привет! Меня зовут Янина. В ИТ у меня 5+ лет коммерческого опыта в Delivery, Discovery, Growth, Data Analytics и я постоянно улучшаю свои харды и смотрю, что делают коллеги из других компаний. Хочу поделиться своим мнением и практическими инсайтами с онлайн-конференции Podlodka Product Crew с теми, у кого не было возможности присоединиться.

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

Ну хорошо, не совсем сам. Ему помогут Product Manager, разработчики, пара постов в Telegram, лендинг, где написано «инновационное решение для оптимизации бизнес-процессов», и релиз-ноутс на языке, который без подготовки читают только автор задачи, техлид и человек, который слишком долго сидел в Jira.

А потом происходит странное.

Фича есть. Код работает. Продакт не спал три недели. Разработчики сделали сложную штуку, которую реально было непросто сделать. Внутри команды все понимают: «Вот оно. Это важно. Это должно выстрелить».

Но рынок почему-то не падает на колени. Пользователи не понимают, что изменилось. Продажи не понимают, как это объяснять. Маркетинг пытается собрать коммуникацию из того, что есть: технического описания, пары комментариев в задаче и общего ощущения команды, что «это важная штука». Клиент смотрит на всё это и думает: «Очень интересно, но мне-то что с этого?»

И вот где-то в этот момент в комнате появляется Product Marketing Manager.

Не чтобы рассказать разработчикам, как писать код. Не чтобы заменить Product Manager. И не чтобы «добавить маркетингового глянца» поверх инженерной мысли.

PMM нужен, чтобы сложная техническая ценность стала понятной рынку.

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

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

Несколько человек отписались: «Если говорить о нашем отделе — результат высокий. Но если выйти за пределы отдела — там для меня начинается настоящий ад».

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

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

Как-то я прочитала морально-этический кодекс самураев и где-то к середине поняла, что речь в нём идёт про мою работу — управление проектами и продуктами в IT.

Привет! Меня зовут Карина Хабибуллина, я продакт-менеджер в диджитал-агентстве Атвинта. Веду два проекта в экосистеме крупного промышленного холдинга — фабрику идей и корпоративный таск-трекер.

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

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

В конце 2025 года в нашей региональной девелоперской компании мы запустили Кайдзен‑офис.

Это такой формат, когда любой сотрудник может предложить идею, как улучшить работу. От «давайте перестанем дублировать отчёты в Excel и Power BI» до «давайте перестроим маршрут согласования заявок». Уже за сам факт того, что сотрудник озвучил потенциально полезную идею (то есть экспертная группа её положительно оценила), мы платим небольшое, но приятное денежное вознаграждение. А уж если идея доходит до внедрения и начинает приносить измеримый эффект, цифры уже другого, ещё более приятного порядка.

По моему мнению, Кайдзен сам по себе — просто потрясающая вещь для развития кадров, вовлечения сотрудников в процессное управление и тому подобное. Но это не основная тема данной истории. Эта история о том, как оценить все эти идеи не субъективно, а по‑настоящему. Что действительно является оптимизацией, которая принесёт деньги, а что — просто галлюцинация, с которой согласились эксперты.

К моменту запуска Кайдзен‑офиса компания за пару лет выросла с 50 до 300+ человек. Это девелопер, который занимается региональной экспансией: новые объекты, новые регионы, новые команды от месяца к месяцу. Процессы выстраивались на ходу и при этом обязаны были масштабироваться. Что‑то закреплялось в регламентах, что‑то существовало в режиме «у нас принято так». Процессный офис — это я и трое моих коллег‑аналитиков.

Идеи пошли на удивление быстро, по 10–15 в месяц. Часть из них вообще не про процессы: «нужно меньше совещаний», «давайте сделаем меньше урн для мусора в офисах». Часть про автоматизацию: «эту задачу можно полностью забрать в RPA». А часть, как мы и хотели, про реальную перестройку процессов: маршруты согласования, разделение зон ответственности, временные окна обработки заявок.

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

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

В апреле этого года «Открытой мобильной платформе» исполнилось 10 лет. За это время мы прошли путь от запуска первой версии ОС до зрелой экосистемы, в которой партнёры-разработчики играют важную роль, ведь они являются соавторами продукта. И как подтверждение успеха данного подхода, в мае в Омске мы получили награду «За лучшую поддержку разработчика среди российских ОС» на «ДевФест 26».

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

Недавно я завершил программу COO в Stratoplan.

Пол года назад, когда я принимал решение идти на обучение, у меня уже был опыт разработчика, Team Lead, CTO и Program Manager. За плечами были десятки проектов, процессы, организационные изменения, инциденты, трансформации команд и продуктовых направлений.

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

Во многом именно ради этого и стоило пройти этот путь.

Среда, 11 утра. Стоишь перед советом директоров. Два месяца подготовки: данные, воронки, когорты удержания, три сценария развития на 17 слайдах. К восьмому слайду CEO проверяет телефон. CTO делает заметки, которые похожи на каракули.

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

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

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

Содержание

• О проекте
• Почему Stripe
• Как устроена оплата в сервисе
◦ Получение события об оплате
◦ Учет дохода преподавателей
◦ Выплаты преподавателям
◦ Прозрачность для всех участников
◦ Тестирование
• Что в итоге

В 2026 году российский LegalTech выходит за рамки «умных шаблонов» и превращается в слой автономной правовой инфраструктуры на базе мультиагентного ИИ. 

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

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

Содержание
• Решения на рынке LegalTech 
• Архитектурный подход и требования корпоративного рынка 
• Мультиагентные архитектуры в LegalTech
• RAG, семантический поиск и корпоративная память
• Суверенная архитектура и соответствие регулированию
• От конструктора договоров к автономному юридическому контуру
• Короткий пилот и экономика внедрения
• Архитектура как конкурентное преимущество
• От юриста-исполнителя к юристу-архитектору

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

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

Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery.

Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.

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

Сейчас 11 утра, я пишу эту статью — и у меня открыта 31 вкладка, в трее маячат Телеграм, Макс и Яндекс.Почта. 

Так что систему, о которой пойдёт речь, мы будем разбирать вместе — я чуть впереди, вы следом. Никаких мотивационных призывов «просто сосредоточься» — только конкретные шаги, после которых 4 часа глубокой работы перестанут быть несбыточной мечтой.