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

Начну с проблемы: мой опыт работы в разных отраслях, от небольших геймдев компаний до крупных IT-гигантов, показал, что продуктовые аналитики (далее - аналитик(и)), работая в команде, подвержены когнитивному искажению, когда хотят выдать желаемое за действительное. В таком случае статистика превращается в одну из форм лжи. Особенно это усугубляется, если премия (или карьерный рост) завязаны на KR команды. И вот вопрос: как защититься от этого «натягивания совы на глобус»? Можно поставить над аналитиком валидатора в виде лида, но, по сути, это выглядит так, будто одну и ту же работу выполняют два человека, причем тот, кто валидирует, обычно делает это поверхностно - из-за нехватки времени и тому подобного.

От подобного, как будто, защищает модель, когда аналитики объединяются в функциональную команду и выступают в роли консультантов для бизнеса. Но и здесь есть проблемы: если отвязать аналитика от KR команды, то какой будет его мотивация? Есть риск, что аналитика таких команд будет представлять собой кучу «воды» без четких предложений бизнесу.

Далее затрону тему эксклюзивных знаний о конкретной части продукта, в которой работает аналитик. Или, как еще говорят, что аналитик обладает глубокими доменными знаниями. На самом деле это очень похоже на создание информационной асимметрии (bus factor). В таком случае я задаю встречный вопрос: «Если нюансы твоей работы задокументировать, останется ли актуальным утверждение о глубоких доменных знаниях?» К чему я это веду? SQL и Python (или любой другой ЯП) ведь останутся прежними; скорее всего, поменяется лишь метрика. А что такое метрика? Это некая математическая формула, зная которую, любой аналитик (почти любой) сможет ее рассчитать. От подобного, опять же, защищает концепция консультантов для бизнеса, которые для удобства своей работы будут создавать и поддерживать подробную документацию. Дополнительный плюс такого подхода - это отказ от изобретения велосипедов, а также обмен экспертизой между аналитиками.

Итак, опишем плюсы включения аналитика в продуктовую команду:

Аналитик работает над одними KR с командой. Легко отследить его влияние.
Глубокие знания определенной части продукта.
Возможность реализации концепции Data Mesh (звучит как утопия, я ни разу не видел рабочей модели).

Минусы:

Склонность к манипуляции данными для подтверждения достижения результатов.
Отсутствие документации или создание информационной асимметрии (bus factor).
Сложность налаживания процессов обмена информацией, особенно при большом количестве аналитиков. То есть переизобретение велосипедов и отсутствие обмена знаниями между аналитиками.

Плюсы функционального подхода (консультанты для бизнеса/команд):

Отсутствует когнитивное искажение, так как аналитик не зависит от KR команды.
Формируется центр экспертизы.
Подробная документация и отсутствие информационной асимметрии.
Не переизобретение велосипедов и происходит обмен экспертизой между аналитиками.

Минусы:

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

Как же быть?

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

Буду рад услышать ваше мнение в комментариях.

Должен ли продуктовый аналитик быть частью продуктовой команды?