Я — Сергей Трутненко, автор книги «Product Management. Исследования, которые работают» и практик, прошедший путь от продакта в банке до архитектора продуктовых систем с миллионными MAU. За годы я видел, как рушатся проекты, построенные на догмах, и как выживают те, кто чувствует рынок, а не следует инструкциям.
Сейчас время новой волны мышления — FLUX. Это не просто аббревиатура или очередной модный фреймворк. Это состояние продуктового мира, где всё постоянно меняется, и выживает не тот, кто знает больше, а тот, кто умеет адаптироваться быстрее.
FLUX — это про гибкость, скорость и контекст. Про умение не цепляться за процесс, а видеть суть. В мире, где гипотезы устаревают за неделю, а метрики превращаются в шум, продакт должен мыслить не как менеджер, а как полевой исследователь, действующий в условиях хаоса.
Эта статья — мой взгляд на FLUX как на эволюцию продакт-менеджмента. Мы разберём, почему классические подходы больше не работают, как новые принципы меняют саму суть продуктового мышления и что нужно, чтобы оставаться на плаву, когда рынок рушится под ногами.
Если вы чувствуете, что старые инструменты буксуют, а решения перестали давать результат — добро пожаловать в FLUX. Это не теория. Это новая реальность, в которой мы уже живём.
Flux
Скрам, появившийся в начале 1990-х, стал ответом на усложняющиеся процессы разработки программного обеспечения. Его создатели, Джефф Сазерленд и Кен Швабер, вдохновленные бережливым производством и японскими подходами к управлению, разработали фреймворк, который радикально изменил индустрию.
Скрам появился как альтернатива традиционным методологиям, таким как Waterfall и PMBOK. Их ориентация на долгосрочные роадмапы, расписанные на годы, часто оказывалась пустой тратой времени. Скрам выделялся гибкостью и ориентацией на краткосрочные итерации, позволяя адаптироваться к меняющимся требованиям.
Темная сторона Скрама
Изначально Scrum был предложен как набор рекомендаций, а его смысл заключался в том, чтобы команды могли выбрать те элементы, которые действительно необходимы для их работы. Однако в реалиях, многие восприняли это как обязательные элементы, и в итоге внедрили Scrum на максималках — со всеми церемониями, короткими спринтами по 2 недели и обязательными встречами. При этом, изначальная версия Scrum предлагала гибкость, включая возможность спринтов длительностью до месяца, а также выбор определённых практик в зависимости от потребностей команды.
В результате многие команды оказались перегружены церемониями, которые не всегда приносили реальную ценность, и пришлось искать способы оптимизации процессов, что в итоге привело нас к Flux.
А в дополнение ко всему, продакты в большинстве компаний часто воспринимались как просто администраторы процессов, а не как бизнес-лидеры, которые могли бы активно влиять на стратегию и структуру работы. Из-за этого они не имели достаточной власти или возможности для изменения процессов, внедрённых по рекомендации Scrum. Вместо того чтобы формировать подходы, соответствующие реальным потребностям команды и бизнеса, продакты были вынуждены следовать существующим ограничениям и процедурам. Это привело к ещё большему застреванию в рутине и низкому уровню вовлечённости в процессы, что также требовало изменений и адаптации подхода.
Скрам создает вызовы, особенно для продактов. Двухнедельные спринты становятся источником стресса. Такие спринты требуют частых взаимодействий с топ-менеджментом, создавая давление. Продакт тратит время на подготовку к демо и отчетам, что отнимает ресурсы от работы над продуктом. Демо — источник стресса. За две недели нужно разработать функционал и подготовить шоу.
Проблемы в демо:
1. Временные затраты: Подготовка отнимает дни. Стресс. Ошибки вредят репутации;
2. Уменьшение статуса: Публичная критика снижает авторитет продакта;
3. Дополнительные риски: Избыточные ритуалы (груминг и ретроспективы и другое). Фокус на процессе (зацикленность теряет ценность). Риск выгорания (коммуникации и демо усиливают усталость).
Оценка временных потерь в двухнедельном спринте
Двухнедельный спринт включает ритуалы, отнимающие время. Перегрузка контекста (время на возвращение в поток) увеличивает потери еще больше. Для команды из нескольких человек затраты масштабируются.
Ритуалы в двухнедельном спринте отнимают порядка 20-30% от общего времени команды и это 2-3 рабочих дня. Два-три рабочих дня команда тратит только на встречи, включая встречи, подготовку к встречам, перегрузку контекста, подготовку к демо и другое. Мы не учитывали эмоциональную перегрузку продакта, связанную с проведением демо, репетиции к демо и другое. Считать расходы в рублях даже страшно, но это те же 20-30% от общего ФОТ команды.
Flux
Сначала мы проводили все традиционные церемонии, такие как ретро, дейли и планирование спринта, думая, что они необходимы для поддержания процесса. Однако со временем мы заметили, что, несмотря на эти встречи, значительная часть обсуждений происходила в тишине — между отдельными членами команды, когда нужно было разобраться в деталях работы.
В итоге мы поняли, что на самом деле мы уже интуитивно использовали принципы Flux, где акцент на индивидуальных обсуждениях, минимизации встреч и защите потока ценной работы. Мы просто убрали лишние церемонии и оставили те элементы, которые реально помогают двигаться вперёд, а не тратим время на общие собрания.
Мы разработали фреймворк Flux, потому что не нашли подходящего решения, которое бы сочетало гибкость, защиту потока работы и эффективность. Название Flux происходит от латинского слова, которое означает поток, течение или перемещение.
Это идеально отражает суть фреймворка: поддержание непрерывного и гибкого потока работы, где задачи двигаются по канбан-доске, а отвлекающие факторы минимизируются. Flux позволяет команде работать в едином ритме, защищая их потоки и устраняя все, что может прервать естественный рабочий процесс.
Основные принципы Flux:
1. Защита потока работы: Flux акцентирует внимание на защите потока работы каждого члена команды. Важнейшая цель — не прерывать людей встречами, не создавать преград. Когда человек погружён в задачу, его потоку работы не должно быть ничего мешать. Если возникает проблема, её решают только те участники, которые непосредственно в ней задействованы, не отвлекая всю команду;
2. 4-недельные итерации: В Flux нет чётких и жёстких целей для каждой итерации. Вместо этого задачи двигаются по канбан-доске, и команда фокусируется на том, что важно сейчас;
3. Релизы по готовности: В Flux нет привязки к расписаниям релизов. Задачи могут быть релизнуты, как только они готовы, что позволяет минимизировать ожидание и повышать скорость выхода продуктов на рынок;
4. Минимум встреч: Flux исключает почти все скрам-встречи. Вместо ежедневных синков или ретроспектив, команда не общается целиком, а общается только по конкретным вопросам и с участием тех людей, которые прямо сейчас задействованы в решении конкретной проблемы. Основное внимание уделяется решению актуальных задач, когда они возникают. Это помогает избежать перегрузки и позволяет участникам оставаться в своём потоке работы;
5. Демо и обратная Связь: Одной из редких синхронных встреч в Flux является демонстрация результатов работы в конце каждой итерации. Демо проходит раз в месяц и служит для того, чтобы показать результаты работы и получить обратную связь от заинтересованных сторон. Это помогает поддерживать высокий уровень прозрачности и вовлечённости без лишних встреч.
Особенность Flux заключается в том, что помимо демонстрации результатов работы, необходимо обеспечить безопасность внутри демо. Это особенно важно для поддержания репутации продакта среди стейкхолдеров. Важно, чтобы встреча не превращалась в критическую, а наоборот, служила площадкой для конструктивной обратной связи. Защита репутации продакта и команды на таких встречах является важным элементом работы в Flux, поскольку позволяет избежать давления и помогает концентрироваться на реальных улучшениях.
Кому подойдёт Flux?
Flux подойдёт опытным, сработавшимся командам, которые умеют работать автономно, осознанно и эффективно или командам с очень опытным продактом. Это не фреймворк для начинающих — он требует зрелости, высокой ответственности и доверия внутри коллектива.
Управляемость и вовлечённость топ-менеджмента
В Flux управление командой и процессом со стороны топ-менеджмента происходит без микроменеджмента и постоянных встреч. Вместо этого используется:
1. Просмотр канбан-доски — даёт полную прозрачность по тому, какие задачи выполняются, в каком они статусе и кто ими занимается;
2. Прямое взаимодействие с продактом — топ-менеджеры могут подключаться к обсуждению конкретной задачи, без необходимости созывать всю команду;
3. Дашборды и метрики — используются для отслеживания прогресса, финансовых показателей и бизнес-метрик, без вмешательства в рабочий поток команды.
Такой подход сохраняет контроль, но не разрушает поток. Руководство остаётся в курсе происходящего, не мешая работе.
Оценка производительности
Flux исключает оценку по баллам, часам и прогнозам. Производительность команды оценивается постфактум — по результатам:
1. Продакт или тимлид могут анализировать, где возникли задержки;
2. Обсуждение проводится по конкретной задаче, а не в общем ключе;
3. Важный принцип: никаких общих теорий и гипотез про “почему мы замедлились” — только конкретные факты и ситуации, каждая из которых обсуждается по отдельности.
Такой подход позволяет разбираться с проблемами по существу, без обобщений и домыслов. Это снижает напряжение, упрощает обратную связь и помогает реально улучшать процессы, не мешая работе.
Зачем вообще нужно демо?
Демо нужно не для контроля — оно нужно, чтобы команда ощутила реальность. Когда работа идёт глубоко в потоке, легко потерять связь с тем, что на самом деле происходит с продуктом, пользователями и бизнесом. Продакт в контексте почти всегда. А вот команда — нет.
Демо помогает выйти из технической капсулы и почувствовать, куда мы движемся. Увидеть, как задачи превращаются в результат, а результат — в реакцию. Получить обратную связь, не как давление, а как поддержку и понимание.
И давайте честно: даже топ-менеджеры бывают вне контекста. У них совещания, стратегия, сто встреч в день — и продукт иногда просто выпадает из поля зрения. Демо — это напоминание, что продукт живой, и момент задать вопросы, которые раньше не успели.
----
Product Management. Исследования, которые работают
Сергей Трутненко
🧩 Что это за книга
Это книга не про глянцевые стартапы, миллионы инвестиций и фотки основателей на фоне MacBook. Это книга про реальную жизнь продакта — ту, где рынок не прощает ошибок, бюджеты ограничены, пользователи не читают инструкции, а стейкхолдеры хотят результаты «ещё вчера».
Product Management. Исследования, которые работают — это рабочая система мышления, созданная из практики, боли и множества провалов, которые научили, что важно не то, что пишут в книгах, а то, что реально работает в бою.
⚙️ Что ты получишь
- Фреймворки нового поколения, которые можно применять сразу, без теоретического мусора.
- Понимание контекста — почему одни методы проваливаются в России и СНГ, а другие становятся оружием роста.
- Систему исследований, которая заменяет хаос на предсказуемый процесс принятия решений.
- Реальные кейсы — не из Кремниевой долины, а из российских финтехов, стартапов и b2b-компаний, где всё решает смекалка, а не гранты.
- Философию продакта-практика — как не утонуть в данных, а научиться видеть реальность такой, какая она есть.
🔍 Чем книга отличается от других
Большинство книг про продуктовый менеджмент — это перелицованные инструкции с запада:
«Сделай кастдев, проведи A/B-тест, посчитай метрики».
Звучит просто, но не работает в реальных условиях. У нас нет бесконечного бюджета, доверчивых пользователей и венчурного запаса на ошибки. Здесь — другие правила. Моя книга не обещает волшебных инструментов. Она даёт честный взгляд и рабочие механики, адаптированные под суровую реальность. Это не «ещё один гайд», а набор инструментов выживания продакта в мире, где на каждое решение влияет десяток непредсказуемых факторов.
🚀 Для кого эта книга
- Для продактов, которые устали от теории и хотят реальных подходов.
- Для основателей стартапов, которым важно быстро проверять гипотезы без бюджета.
- Для руководителей, которые строят команды и процессы вокруг реальных данных, а не иллюзий.
- Для всех, кто чувствует, что продуктовый менеджмент меняется — и хочет понимать, что будет дальше.
🧭 Почему она важна сейчас
Мир продуктов вошёл в эпоху FLUX — постоянных изменений, неопределённости и мгновенных сдвигов. Твоя стратегия может устареть за неделю. Старая методология — уже вчерашний день. Эта книга — не просто про исследования. Это про то, как выжить и побеждать в мире, где правил больше нет.
✍️ Об авторе
Сергей Трутненко — магистр робототехники ИТМО, специалист по комплексному продакт-менеджменту и автор более десятка успешных интеграционных и финтех-проектов. Опыт — продакт в банках, консалтинге и стартапах. Системный практик, который превращает хаос продуктовых команд в управляемые процессы и создаёт новые фреймворки под реалии поственчурного мира.