Почему командное общение важнее, чем ваш стек Martech

Коммуникация и анализ маркетинговой команды

Нетипичная точка зрения Симо Ахавы на качество данных и структуру связи освежила весь зал ожидания Перейти Аналитика! конференция. OWOX, лидер MarTech в регионе СНГ, пригласил на это собрание тысячи экспертов, чтобы поделиться своими знаниями и идеями.

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

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

Качество данных зависит от человека, который их анализирует. Обычно мы виним во всех недостатках данных инструменты, рабочие процессы и наборы данных. Но разумно ли это?

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

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

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

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

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

Здесь, здесь и там! Примените эту новую бизнес-стратегию, и все будет в порядке!

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

Так что польза от этих компаний как таковая ограничена. 

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

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

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

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

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

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

Значимые данные - закон Конвея

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

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

Мелвин Конвей, Закон Конвея

Эти мысли появились в то время, когда один компьютер идеально подходил для одной комнаты! Только представьте: здесь одна команда работает на одном компьютере, а там другая команда работает на другом компьютере. А в реальной жизни закон Конвея означает, что все недостатки коммуникации, возникающие между этими командами, будут отражены в структуре и функциональности разрабатываемых ими программ. 

Примечание автора:

Эта теория сотни раз проверялась в мире разработчиков и много обсуждалась. Наиболее определенное определение закона Конвея было создано Питером Хинтьенсом, одним из самых влиятельных программистов начала 2000-х годов, который сказал, что «если вы работаете в дерьмовой организации, вы будете делать дерьмовое программное обеспечение». (Амдал - Ципф: Десять законов физики людей)

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

  • Отсутствуют значения, когда инженеры не обсудили проблему 
  • Неправильные форматы, на которые никто не обращал внимания и никто не обсуждал количество десятичных знаков
  • Задержки связи, когда никто не знает формат передачи (пакетный или потоковый) и кто должен получить данные

Поэтому системы обмена данными полностью раскрывают наши недостатки.

Качество данных - это достижение специалистов по инструментам, экспертов по рабочим процессам, менеджеров и общения между всеми этими людьми.

Лучшие и худшие коммуникационные структуры для мультидисциплинарных команд

Типичная проектная группа в компании MarTech или маркетинговой аналитики состоит из специалистов по бизнес-аналитике (BI), специалистов по обработке данных, дизайнеров, маркетологов, аналитиков и программистов (в любом сочетании).

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

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

Поощряйте междисциплинарные команды

Худшие черты этой ситуации:

  • Недостаточная вовлеченность
  • Недостаточное участие
  • Отсутствие сотрудничества
  • Нехватка доверия

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

Поощряйте мультидисциплинарные команды

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

Поэтому встречи - это только первый шаг. У нас все еще есть проблемы:

  • Плохая связь
  • Отсутствие общих целей
  • Недостаточная вовлеченность

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

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

Привести всех к общению по проекту. 

Междисциплинарное общение в командах

Лучшие особенности этого подхода:

  • Прозрачность
  • Участие
  • Обмен знаниями и навыками
  • Непрерывное образование

Это чрезвычайно сложная структура, которую сложно создать. Возможно, вы знаете несколько фреймворков, использующих этот подход: Agile, Lean, Scrum. Неважно, как вы это называете; все они построены по принципу «делать все одновременно». Все эти календари, очереди задач, демонстрационные презентации и фуршетные встречи нацелены на то, чтобы люди часто и все вместе рассказывали о проекте.

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

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

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

Главный критерий хорошего консультанта (могу сказать, потому что я консультант) - постоянное снижение его вовлеченности в проект.

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

Кстати, консультант не должен делать отчеты или становиться для вас дополнительной парой рук. Для этого у вас есть внутренние коллеги.

Нанимайте маркетологов для обучения, а не для делегирования

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

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

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

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

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

Предположим, у нас есть три источника, дающие нам следующие данные: данные о трафике, данные о товарах электронной коммерции / данные о покупках из программы лояльности и данные мобильной аналитики. Мы пройдем этапы обработки данных один за другим, от потоковой передачи всех этих данных в Google Cloud до отправки всего для визуализации в Google Data Studio с помощью Google BigQuery

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

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

  • Этап агрегации данных. Что нужно учитывать:
    • Специализированные настройки для процессов ETL: что нам делать с недействительными данными?
      Патчить или удалить? 
    • Можем ли мы получить от этого прибыль? 
    • Как это повлияет на качество всего набора данных?

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

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

Все основано на общении. И по темам разговора. Вот пример того, что следует обсудить при подготовке стриминга Яндекса:

Marketing BI: Snowplow, Google Analytics, Яндекс

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

Сложности везде, даже в самых простых местах.

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

БИ говорит, что нельзя так выходить из ситуации.

Как мы можем рассчитать цену за тысячу показов, если мы даже не можем быть уверены, был ли товар показан? Каков тогда квалифицированный CTR для изображений?

Маркетологи отвечают:

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

И тогда разработчики скажут:

Да, мы можем решить эту проблему с помощью нашей новой интеграции для отслеживания прокрутки и проверки видимости объекта.

Наконец, дизайнеры UI / UX говорят:

Да уж! Мы можем выбрать, нужен ли нам наконец ленивый или вечный свиток или разбивка на страницы!

Вот шаги, которые прошла эта небольшая команда:

  1. Определил проблему
  2. Представлены бизнес-последствия проблемы.
  3. Измеряли влияние изменений
  4. Представленные технические решения
  5. Обнаружили нетривиальную прибыль

Чтобы решить эту проблему, они должны проверить сбор данных из всех систем. Частичное решение в одной части схемы данных не решит бизнес-проблему.

выровнять настроить дизайн

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

Как вы думаете?

Этот сайт использует Akismet для уменьшения количества спама. Узнайте, как обрабатываются ваши данные комментариев.