Как команды данных могут извлечь выгоду из работы как продуктовая команда

27 октября 2022 г.

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

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

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

Две основные идеи: ориентация на пользователя и проактивность

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

Ориентированность на пользователя

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

Команды данных должны работать одинаково. Мы были слишком очарованы тем, насколько технически интересной может быть наша работа, и мы забыли, что мы не являемся обособленными убежищами для научных/инженерных занятий  — мы бизнес-подразделение, нанятое для обеспечения ценности для бизнеса. И если мы, как команды разработчиков, не решаем бизнес-задачи с помощью данных, наш метафорический «продукт данных» (вся работа с данными, которую мы делаем) терпит неудачу.

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

Проактивность

Во-вторых, в лучших продуктовых командах настроены упреждающие процессы для поддержки процесса создания продукта. Они преднамеренно предоставляют себе пространство для формулирования видения, мозгового штурма, реализации увлеченных проектов, которые выходят за рамки непосредственного удовлетворения запросов клиентов.

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

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

Но с чего начать?

В оригинальной статье LO есть несколько отличных предложений на уровне организации, чтобы сделать все это возможным: иметь достаточную численность персонала, чтобы у вас была достаточная пропускная способность, чтобы действовать стратегически; собрать мультидисциплинарную команду, чтобы черпать вдохновение. Чтобы добавить к этому, вот несколько конкретных изменений на уровне процесса, которые вы можете сделать немедленно:‍

1. Установите процесс консолидации знаний‍

.

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

Это будет вашим самым большим препятствием, потому что несоблюдение — огромная проблема. Люди стремятся придерживаться статус-кво, и слишком часто я видел, как инициативы по документированию/обмену знаниями терпят неудачу. Публикация работы в рабочей вики-области, такой как Notion, Confluence или Dropbox paper (а для решения, специфичного для аналитики, в гиперзапросе), может преодолеть этот барьер.

Вот ключевые компоненты, обеспечивающие широкое распространение:

• Меньше проблем с использованием. Как бы ни было заманчиво использовать git и настроить процесс экспертной оценки, многоуровневый процесс не обеспечит строгости  — он снизит внедрение. Сделайте что-нибудь простое, легкое и сосредоточьтесь на том, чтобы ваша команда могла работать с этим инструментом.
• Настройте организационную структуру. Опять же, используйте такой инструмент, как гиперзапрос, Notion или Confluence, с вики-структурой, которая позволит вашей команде установить методы не только централизации, но и организации. Согласуйте разумные, функциональные категории и создайте центральный документ «Начните здесь», который будет знакомить новых аналитиков с вашей практикой.

2. Тщательно изучите потребности бизнеса.

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

Мы гордимся своим техническим мастерством, но мы эффективны только в том случае, если знаем, зачем делаем свою работу. Без деловой хватки мы будем писать бессмысленный анализ за анализом, пока нас не переместят в Хранилище B, наше взаимодействия относятся к извлечению данных.

Как это выглядит на практике:

• Всегда спрашивайте, почему. Перед тем, как погрузитесь в SQL, убедитесь, что вы согласны с вашими заинтересованными сторонами в отношении бизнес-целей. Запишите это, договоритесь о подходе и только потом приступайте к делу. Это создает прецедент того, что ваше участие в процессе принятия решений не ограничивается технической работой  – как минимум вас будут воспринимать как переводчика, а в лучшем случае – как идейного вдохновителя.
• Забота о бизнесе. Звучит очевидно, но слишком часто я видел, как аналитики и специалисты по данным закрывают глаза на бизнес и погружаются в технические аспекты своей работы. Такое поведение является предвестником действительно нефункциональной, малоэффективной аналитической организации. Как правило, больший эффект достигается не за счет лучшего анализа, а за счет влияния данных на более высоких уровнях стратегического исполнения.

Заключение

Характер анализа данных сильно изменился за последнее десятилетие. У нас есть доступ к большему количеству данных, большей вычислительной мощности и большему количеству инструментов, чем когда-либо прежде. Но мы еще не поняли, что должны действовать внутри организации с нашими новообретенными способностями. Здесь может быть полезно перенести успешные практики из других областей. В частности, в продуктовых командах акцент на ориентированность на пользователя и проактивность может означать разницу между командой аналитиков службы поддержки и командой, которая действительно управляет стратегией. А ориентированность на пользователя и проактивность обусловлены четким пониманием потребностей бизнеса и лучшими методами обмена знаниями.

Исходная запись в блоге опубликована на гиперзапрос.

---

Оригинал