Всем привет!
Хочу поговорить о той звенящей тишине, которая повисает в воздухе, когда на общем собрании объявляют имя вашего нового TGM. Молодой, энергичный, уверенный и с блеском в глазах:
- "Предыдущий опыт? Консалтинг: запустил 100500 проектов в космос! Ну... почти 100500... почти запустил..."
Топ-менеджмент хлопает в ладоши: "Наконец-то! Стратег! Визионер! Сейчас он всё разрулит! По-быренькому проект затащит!"
А вы, продакт, чувствуете, как по спине пробегает холодок и тихий внутренний голос шепчет: “Ну, началось...”
Это не статья о том, что все консультанты плохие. Это статья о том, почему операционная система в голове гениального консультанта на 99% несовместима с живым, дышащим, ошибающимся организмом продуктовой разработки. И почему для вас это, скорее всего, закончится выгоранием и/или уходом из компании.
Конфликт цивилизаций: проектный рай vs продуктовый хаос
Чтобы понять всю глубину пропасти, нужно принять: вы и ваш новый босс - существа из разных вселенных.
Его мир - это мир Проектов. Это спринт в стерильных условиях. У него есть клиент, контракт, четкое ТЗ (пусть и завуалированное под «scope») и дедлайн, после которого он получает бонус и переходит на следующий проект. Его главный скилл - создать у клиента полную иллюзию контроля над будущим. Его артефакт - безупречная презентация на 100 слайдов, доказывающая, что единственно верный путь найден. Он продает уверенность.
Ваш мир - это мир Продукта. Это марафон по минному полю в тумане. У вас нет конечной точки, есть только вектор. Ваш главный скилл - быстро и дешево ошибаться, признавать это и менять курс, опираясь на хрупкую обратную связь от реального мира. Ваш главный артефакт - работающий код, который приносит пользу здесь и сейчас, пусть он и обвешан местами костылями и техдолгом. Вы продаете ценность.
И вот он, продавец уверенности, приходит управлять теми, чья работа - жить в неопределенности. Он попытается истребить хаос. А хаос, как известно, - это питательная среда для инноваций.
Пять смертных грехов TGM экс-консультанта
Все начинается красиво. Со стратегических сессий, тимбилдингов и обещаний «дать вам всё для успеха». Но очень скоро вы начнете замечать симптомы, которые перерастут в смертельную болезнь для вашего продукта и команды.
1. Грех первый: Иконостас из слайдов (Презентация вместо продукта). Первое, что вы заметите, - количество совещаний для "синхронизации" и "alignement" вырастет в разы. А результатом каждой встречи будет… новая презентация. Дорожные карты, отчеты, стратегии, анализы рынков. Всё это будет выглядеть невероятно профессионально, логично и красиво. Команда будет тратить 20-30% времени не на код и дизайн, а на подготовку материалов для этих ритуалов. Ваш TGM будет показывать эти слайды своему руководству и получать похвалу. Вот только к реальности и пользователям эти мертвые документы не будут иметь никакого отношения.
2. Грех второй: Диктатура Output'а (Фабрика фич). Консультант не мыслит категориями «повысить удержание» (Outcome). Он мыслит категориями "выкатить 5 фич из списка" (Output). Ваш бэклог превратится из списка проверенных гипотез в список поручений. Начнутся вопросы: "Почему так долго? Давайте упростим. Давайте без A/B-теста, я и так знаю, что это сработает. Рынок не ждет!" Команда превратится в галеру, где вы - надсмотрщик, а TGM - тот, кто бьет в барабан, требуя ускорить темп. Куда плывем? Неважно. Главное - махать веслами с нужной скоростью.
3. Грех третий: Кастрация продакта (Превращение в секретаря с Jira-доступом). Это самое болезненное. Ваша главная роль - исследовать, искать боль пользователя, быть его голосом - атрофируется за ненадобностью. Зачем проводить кастдев, если стратегия уже спущена сверху? Зачем A/B-тест, если решение принято на основе "лучших практик" и анализа конкурентов? Ваша работа сведется к декомпозиции чужих идей, заведению тикетов, контролю сроков и подготовке отчетов. Из владельца продукта вы превратитесь в project-менеджера. А потом и вовсе в личного ассистента руководителя. Это прямой путь к профессиональному выгоранию.
4. Грех четвертый: Стратегический туман (Отрыв от реальности). Стратегия, рожденная в кабинетах и PowerPoint, почти всегда разбивается о скалы технической реальности. TGM может наобещать руководству золотые горы, не посоветовавшись с командой. А потом вы окажетесь в ситуации, когда вам нужно за два спринта построить космолет силами трех разработчиков, у которых половина времени уходит на поддержку легаси. Вы окажетесь между молотом (требования босса) и наковальней (реальность команды). И виноватым в срыве сроков, конечно, будете вы.
5. Грех пятый: Смерть от недоверия (Микроменеджмент). Консультант привык, что он - самый умный человек в комнате. Он не доверяет экспертизе других по умолчанию. Он будет лезть в дизайн («а почему кнопка не красная?»), в технические решения («а вы уверены, что этот фреймворк оптимален?») и в ваши аналитические выкладки. Он будет требовать обоснования каждого шага. Это убивает в команде последнее желание брать на себя ответственность и проявлять инициативу. Зачем, если босс все равно придет и сделает по-своему?
Партизанская война: инструкция по выживанию
Если вы еще не пишете заявление, есть шанс побороться. Но это будет война. Война за здравый смысл, команду и продукт.
1. Говорите на языке врага. Забудьте слова «эмпатия», «пользовательский опыт», «гибкость». Это для него пустой звук. Переводите всё на язык денег, рисков и KPI.
Не: «Нам нужно провести исследование, чтобы лучше понять пользователей».
А: «Я предлагаю инвестировать 2% бюджета квартала в исследование, чтобы снизить риск провала фичи X на 40% и не сжечь 5 лямов на ненужную разработку».
2. Затащите его в окопы. Лучшее лекарство от отчетов - это реальность. Пригласите его на проблемное интервью с пользователем. Не пересказывайте, а дайте послушать вживую, как пользователь материт ваш интерфейс. Покажите ему не красивые графики, а сырые логи сессий, где 10 из 10 пользователей не могут найти нужную кнопку. Столкновение с реальностью бывает болезненным, но отрезвляющим.
3. Установите демаркационную линию. Это сложный дипломатический маневр. Инициируйте разговор о ролях. Признайте его силу в стратегии и работе со стейкхолдерами. Но жестко отстаивайте свою территорию: тактику и исполнение. «Ты определяешь ЧТО и ПОЧЕМУ на уровне бизнес-целей (Outcome). Я и команда определяем КАК и ЧТО КОНКРЕТНО мы будем делать для их достижения (Output)». Это ваш Рубикон. Не всегда, но иногда заходит.
4. Станьте брандмауэром для команды. Защищайте команду от корпоративного безумия. Фильтруйте запросы. Превращайте расплывчатые идеи босса в проверяемые гипотезы. Будьте щитом, который принимает на себя удары бюрократии, чтобы команда могла спокойно работать. Да, это тяжело. Да, за это не благодарят. Но иначе система сожрет всех.
Вместо заключения
Иногда в этой войне вы будете побеждать. Чаще - проигрывать. Самое главное - понимать, что это не ваша вина. Вы столкнулись с системной проблемой - попыткой применить чужеродную культуру к вашей продуктовой среде.
И если вы чувствуете, что битва проиграна, что продукт летит в пропасть под аплодисменты топ-менеджмента, а ваша работа превратилась в симуляцию бурной деятельности - уходите. Рынок большой. Есть места, где все еще создают продукты для людей, а не презентации для начальников.
А у вас был подобный опыт? Расскажите в комментариях, как вы выживали. Ваши истории могут спасти чью-то карьеру. И продукт.
Комментарии (8)
grfree
14.10.2025 06:24ППКС
раза три в моей практике было ровно то, что описано в статье.
Приходит к руководству пиздабол-задушевник, льет в уши правильные слова и получает карт-бланш на реорганизацию.
Тратит х5 к существующему бюджету и в итоге, года через два получает сопоставимый с имевшимся результат.
ASenchenko
Начало Вашего конфликта лежит вот здесь:
Ключевое выделил "BI". Что ж такого произошло, что руководству пришлось брать человека из консанлтинга ? Что от него требовалось разрулить ? Вы, к сожалению, этого не раскрыли.
Ваша реальная боль - в пункте 3 "Грехов"
Допускаю, что это и основной триггер к написанию статьи.
Самое интересное, что в "решениях" наиболее рабочий - тоже пункт "3"
Вы не поверите, но реально хорошему консу этот подход также будет наиболее комфортен :)
Если бы не излишняя эмоциональность, можно было бы даже плюсануть статью. Ибо действительно стыковать подходы непросто.
Непрошенный совет - зло, но рискнут дать. Разберитесь с самым началом - почему к вашей команде приставили проектника ? Даже не так. Почему руководить вашей командой поставили именно проектника ? Я не имею в виду, что Вы и Ваша команда совсем плохо работали, скорее всего это не так, вас бы просто поменяли. Но вероятно был конфликт ожиданий?
AnLushch Автор
Да, возможно вы и правы. Но, разве убийство продукта и разрушение команды принесёт успех проекту?
ASenchenko
Сначала отвечу коротко на Ваш вопрос. Иногда - да. В зависимости от контекста.
Однако контекста Вы снова не дали и предлагаете мне сыграть в угадайку :)
Ключик к угадайке у меня только один, Ваше:
Ну ок. Наливайте кофе. Сейчас лонгрид будет.
Спойлер. Это взгляд на происходящее корпоративного бизнес-аналитика (архитектора), для которого что проектный, что продуктовый, что любой другой подходы - "сила ночи, сила дня - одинаково фигня". Я вас всех люблю абсолютно одинаково. Вы мне фичи внедряете :))
Часть 1
Начнём наверное с того, что продуктовый подход - это во-первых, не новость, а во-вторых, не единственно верная стратегия (что бы Вы не прочитали здесь, на Хабре, или в иных источниках). Она отлично работает там и только там, где наибольшую ценность приносит удовлетворение потребностей пользователя.
В случае корпоративной системы, продуктовый подход применять можно и нужно, но с включенной и холодной головой. Потому для любой Корпорации ценностью являются не только удовлетворённые пользователи, но и счастливые акционеры. И их интересы не обязательно сходятся. А там ещё ценностей наберётся. Заметьте, я не говорю, что удовлетворение пользователя не является ценностью. Я говорю, что она не одна. Это ключ.
И да, нужно упомянуть, что лет 10–15 назад о Продуктовом управлении вообще мало кто говорил, все носились с Процессным и чертили BPM схемы на всё что приходило в голову. Это модно было. Однако же когда обвешали все сортиры BPMками использования туалетной бумаги, заскучали и начали искать чего еще. Вот к примеру про Продуктовый вспомнили. Лет через 10 ещё чего из учебников по истории вытащат.
Часть 2.
Корпоративная система - это по сути набор относительно изолированных юнитов, обеспечивающих работу нескольких типов подразделений - бизнесо-(или деньго)-образующих (закупки, продажи, маркетинг), поддерживающих (логистика, HR, GR, юристы, бухгалтерия, финансы) и технических (ИТ, недвига). Где у нас лучше всего приживётся продукт ? Верно, в бизнесо-образующих юнитах. Там в общем и формируется та самая основная ценность - удовлетворённость клиента. Где похуже ? В технических юнитах, где контакт ещё есть, но он опосредованный. Где хуже ? Юристы, GR, логистика (ну только если она не нацелена выйти на внешний рынок).
Это была первая часть ответа на Ваш вопрос. Если к примеру в погоне за модой руководство Корпорации решило перевести на продуктовую модель бухгалтерский учёт ... ну флаг им в руки в достижении MAO DAO и прочих метрик. Рано или поздно эта затея просто выдохнется и продукт закроется (возможно вместе с командой)
Часть 3
Есть ещё один момент. Уже выше написал, что поставка ценностей в Корпорате отнюдь не линейна. И иногда возникают задачи, которые реально нужно сделать "под срок" - к защите бюджета, собранию акционеров, публикации отчётности, НДС вот поменять с 1 января. Здесь не только упомянутые Вами квартальные KPI, хотя куда ж без них, но это не единственное :)
И вот здесь возникает конфликт. Юниты, которые до этого успешно жили в своих продуктах и давали стране удовлетворённых пользователей, вдруг должны всё бросить, нет, не всё, а совсем всё, и вместе со всей Корпорацией сдать фичу к дате. Причём зачастую в определённой последовательности - чтобы не сбойнула ВСЯ СИСТЕМА. И здесь дело не ограничивается "заведением зависимостей в JIRA друг на друга". Здесь каждый владелец продукта должен переключиться, чётко понять свою роль в изменении ВСЕЙ СИСТЕМЫ и со своей командой чётко отработать свою часть.
Лирическое отступление
Почему ещё бухучёт на продуктовый подход сложно переводить ? Да потому что основная часть их задач - как раз апдейты под новые фичи в рамках всей Системы.
Финал
Вступаем на хрупкую дорожку моих угадаек :)
Если вдруг не очень опытный владелец продукта не до конца понимает (или не принимает) правила феодального общежития, когда каждый вассал пашет своих крестьян ровно до тех пор пока феодал на войну не свистнет, то его судьба незавидна.
Сначала его будут пытаться уговорить. Но недолго
После пары-тройки срывов сроков или объёмов общекоролевских задач, к нему пришлют внешнего управляющего.
Сработается, найдёт понимание - хорошо. Встроится и будет жить долго и счастливо.
А вот если начнёт партизанить (что и было похоже по Вашему описанию) - ну тут как говорится ... отторжение произойдёт.
Продукт он ведь чем хорош ? Тем, что изолирован )))) У любой медали две стороны. Та, которая тёмная - изолированную систему недолго поменять на аналог.
Все возможные совпадения - чисто случайны.
ASenchenko
Вы в целом то написали верные вещи.
Но по всей статье сквозит конфликт. По некоторым признакам Вы переиграли в независимость и слили несколько реально важных общесистемных задач.
Ну не вводят просто так внешнее управление
Еще раз. Это не вывод, а предположение на основе прочитанного.
AnLushch Автор
Спасибо за такой обстоятельный комментарий!
Очень понравилось, как вы разложили всё по уровням - особенно про корпоративные юниты и разные типы ценности. Прямо чувствуется опыт человека, который много лет наблюдает за системой "изнутри матрицы".
Полностью согласен, что продуктовый подход - не серебряная пуля, и в корпоративной среде он нередко буксует, когда сталкивается с реальностью "общесистемных задач" и календарных дедлайнов.
Мой текст скорее был не манифестом "продуктового превосходства", а криком души человека, который оказался между PowerPoint - реальностью и пользователями - и пытался выжить, не потеряв здравый смысл.
То, что вы называете "переиграли в независимость", - очень точное замечание.
Думаю, для многих продактов это естественная стадия взросления: сначала - бунт против внешнего контроля, потом - поиск баланса между автономией и системой.
И если мой текст показался “партизанским”, значит, возможно, я ещё где-то внутри на этой стадии )
Ещё раз спасибо за комментарий. Такие ответы и делают обсуждение на Хабре живым - когда сталкиваются разные миры и мнения, но с уважением к опыту друг друга.
ASenchenko
Хорошо.
Ловите пасхалочку :)))
На картинке дал иллюстрацию своего текста выше.
Ещё раз, это взгляд не управленца, а бизнес-аналитка.
Чем больше задач, фичей, чего угодно команда может делать вне общесистемных сквозных процессов, тем проще ей жить как продуктовой.
Ну и наоборот. Постоянное участие в общесистемных задачах делают именно продуктовый подход всё менее применимым.
Важный момент. Решать "сквозные" задачи часто проще с применением именно проектных методов. А в некоторых случаях (ну вот ещё раз пример - изменение НДС с 2026 года) - это в принципе исключительно проект, потому что сроки, метрики и функции известны и их не изменить.
Смотрите сами где находится Ваша команда и стройте стратегию и тактику именно из этого. Возможно, просто по сути функциональности, Вам реально необходим периодически "нырять" вот в ту серую область на картинке и принимать участие в проектных инициативах.
Страшного в этом ничего. Вот прямо сейчас у меня в работе несколько задач, в которых мы согласуем работу нескольких чисто продуктовых и пары проектных команд. Это сложно. Но мы справляемся.
Главное в этом деле - понимать, принимать и использовать достоинства соседей. Ну и поменьше партизанить против их недостатков :))) Конструктивно друг к другу подходить короче
Удачи Вам и терпения :)