Почему коммуникации в команде важнее используемых технологий?

Нетривиальный взгляд пионера-аналитика, эксперта Google Developers по Google Analytics и Tag Manager Симо Ахавы на связь между качеством данных и коммуникативной структурой любой организации оживил весь зал на конференции Go Analytics!. Раз в год компания OWOX собирает на этой конференции тысячи участников и экспертов, чтобы те поделились своим опытом и свежими идеями. Симо ошарашил всех простым умозаключением, в котором кроется большой смысл. Его выступление записала Марго Бергер, PR-менеджер OWOX BI.

О качестве данных и организации

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

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

Типы компаний и их коммуникационные структуры

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

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

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

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

Вот и получается, что и эти консультационные компании находятся в вакууме собственной ограниченности.

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

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

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

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

Закон Конвея в применении к аналитическим компаниям

Прекрасный программист середины ХХ века, Мелвин Конвей сделал умозаключение, ставшее так званым законом Конвея:

Организации, проектирующие системы, ограниченыдизайном, который копирует структуру коммуникации в этой организации.

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

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

Данные и системы обмена данными выдают нас с головой.

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

Лучшие и худшие структуры коммуникаций

Что произойдет в команде, где будет недостаточное понимание важности коммуникаций? Смоделируем ситуацию. Вот технические специалисты пишут код, долго пишут, пока все остальные безмолвно ждут. Потом, наконец-то (остальные закатывают глаза, мол, чего ж так долго-то), выливают результат своей работы. И тут все как будто просыпаются: нет, это не то, что мы хотели. А дизайнеры с разработчиками пожимают плечами и отсылаются на свое понимание спецификации.

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

Хуже всего в этой ситуации:

• недостаточная вовлеченность,
• недостаточное участие,
• отсутствие сотрудничества,
• недостаточное доверие.

Как это исправить? Буквально заставлять людей общаться.

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

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

Поэтому это только первый шаг:

• улучшение коммуникации,
• непонимание общих целей,
• недостаточная вовлеченность.

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

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

Это коммуникации всех со всеми о проекте.

Характерные особенности этой структуры:

• прозрачность,
• вовлеченность,
• обмен знаниями и навыками,
• постоянное обучение.

Это чертовски сложная структура, которую сложно создавать. Есть знакомые вам фреймворки — Agile, Lean, Scrum — как бы вы их ни называли, все они основаны на принципе «делать все вместе». И все эти календари, заполненные задачами, демо-запуски, презентации, быстрые встречи — все эти усилия направлены на то, чтобы заставить людей говорить о проекте, часто и вместе.

Вот почему я ярый сторонник Agile, потому что в нем присутствует это понимание важности коммуникаций как условия выживания проекта.

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

Единственная черта предоставления услуг хорошего консультанта (а я сам консультант и могу это говорить) состоит в том, чтобы его участие в проекте со временем неизбежно становилось невостребованным. Консультант не должен кормить компанию маленькими кусочками своих секретов, ведь это не сделает компанию самодостаточной. То, что вы подсели «на иглу» консультантов, уже повод усомниться в качестве предоставляемых услуг.

Еще не стоит нанимать эксперта как дополнительную пару рук или инструмент отчетности. Для этого у вас уже есть специалисты.

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

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

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

Как коммуникационная структура отражается на процессе передачи и обработки данных?

Допустим, у нас есть три источника данных: о трафике, о товарах в интернет-магазине и покупках по программе лояльности, и данные мобильной аналитики. И мы собираем эти данные в Google Cloud, с помощью Google BigQuery отправляем все на визуализацию.

Давайте рассмотрим на каких этапах работы с данными возникают проявления коммуникативных проблем?

Сбор данных

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

Объединение в поток данных

• Определение главных принципов ETL.
• Потоковая или пакетная передача данных? Как правильно разметить объединение двух разнотипных потоков? Как правильно согласовать пакеты и потоки в единой схеме данных без потерь и ошибок?
• Вопросы хронологии: убедиться, правильные ли временные метки? Правильно ли запускается процесс по обновлению или обогащению данных по временным маркерам?
• Как проходит валидация на уровне хитов? Что происходит с невалидными хитами?

Агрегация данных

• Настройка специфицированных ETL-процессов.
• Что делать с невалидными данными? Патчить или выбрасывать? Могут ли они пригодиться? Как они повлияют на общее качество данных?

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

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

Визуализация

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

Все это основано на коммуникации. На темах для разговора. Вот, к примеру, что творится на этапе подготовки потока с Yandex:

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

Сложности есть везде, даже там, где, казалось бы, проще некуда.

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

Источник