Чому командне спілкування важливіше за ваш стек Martech

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

Нетипова точка зору Сімо Ахави щодо якості даних та структур зв'язку освіжила весь зал у Зайдіть в Analytics! конференції. OWOX, лідер MarTech в регіоні СНД, привітав тисячі експертів на цій зустрічі, щоб поділитися своїми знаннями та ідеями.

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

Якість даних та якість організації

Якість даних залежить від людини, яка їх аналізує. Як правило, ми звинувачуємо в усіх недоліках даних інструменти, робочі процеси та набори даних. Але чи це розумно?

Чесно кажучи, якість даних безпосередньо пов’язана з тим, як ми спілкуємося в наших організаціях. Якість організації визначає все, починаючи від підходу до аналізу даних, оцінки та вимірювання, продовжуючи обробку і закінчуючи загальною якістю продукту та прийняттям рішень. 

Компанії та їх комунікаційні структури

Уявімо, що компанія спеціалізується на одному інструменті. Люди в цій компанії чудово знаходять певні проблеми та вирішують їх для сегменту B2B. Все чудово, і, без сумніву, ви знаєте пару таких компаній.

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

Тому з’явився інший вид фірми. Ці компанії спеціалізуються на налагодженні робочого циклу. Вони можуть знайти цілу купу проблем у бізнес-процесах, поставити їх на дошку та сказати керівникам:

Тут, тут і там! Застосуйте цю нову бізнес-стратегію, і все буде добре!

Але це звучить занадто добре, щоб бути правдою. Ефективність поради, яка не ґрунтується на розумінні інструментів, сумнівна. І ті консалтингові фірми, як правило, не розуміють, чому виникли такі проблеми, чому кожен новий день приносить нові складності та помилки та які інструменти були налаштовані неправильно.

Тож корисність цих компаній самостійно обмежена. 

Є компанії, що мають як діловий досвід, так і знання інструментів. У цих компаніях всі одержимі наймом людей з чудовими якостями, експертів, які впевнені у своїх навичках та знаннях. Класно. Але, як правило, ці компанії не спрямовані на вирішення комунікаційних проблем усередині команди, які вони часто вважають неважливими. Тож, коли з’являються нові проблеми, починається полювання на відьом - чия це вина? Можливо, фахівці з БІ переплутали процеси? Ні, програмісти не прочитали технічний опис. Але загалом справжня проблема полягає в тому, що команда не може чітко продумати проблему, щоб вирішити її разом. 

Це показує нам, що навіть у компанії, наповненій крутими фахівцями, на все потрібно більше зусиль, ніж потрібно, якщо організація цього не робить зрілий достатньо. Думка про те, що ви повинні бути дорослим і бути відповідальним, особливо в умовах кризи, - це останнє, про що люди думають у більшості компаній.

Навіть моя дворічна дитина, яка ходить в садок, здається зрілішою за деякі організації, з якими я працював.

Ви не можете створити ефективну компанію, лише найнявши велику кількість фахівців, оскільки всі вони поглинені якоюсь групою або відділом. Тому керівництво продовжує наймати фахівців, але нічого не змінюється, оскільки структура та логіка робочого процесу взагалі не змінюються.

Якщо ви нічого не зробите для створення каналів зв'язку всередині та поза цими групами та відділами, усі ваші зусилля будуть безглуздими. Ось чому стратегія спілкування та зрілість є центром уваги Ahava.

Закон Конвея, що застосовується до аналітичних компаній

Значущі дані - закон Конвея

П'ятдесят років тому великий програміст на ім'я Мелвін Конвей зробив пропозицію, яка пізніше стала широко відомою як закон Конвея: 

Організації, які проектують системи. . . змушені виготовляти конструкції, які є копіями комунікаційних структур цих організацій.

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

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

Примітка автора:

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

Неважко зрозуміти, як цей закон працює у світі маркетингу та аналітики. У цьому світі компанії працюють з величезними обсягами даних, зібраних з різних джерел. Ми всі можемо погодитись, що дані самі по собі є справедливими. Але якщо ви уважно оглянете набори даних, ви побачите всі недоліки організацій, які збирали ці дані:

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

Ось чому системи обміну даними повністю розкривають наші недоліки.

Якість даних - це досягнення спеціалістів з інструментів, експертів з робочого циклу, менеджерів та спілкування між усіма цими людьми.

Найкращі та найгірші комунікаційні структури для мультидисциплінарних команд

Типова команда проектів у компанії MarTech або компанії з маркетингової аналітики складається з фахівців з бізнес-аналітики (BI), науковців з даних, дизайнерів, маркетологів, аналітиків та програмістів (у будь-якій комбінації).

Але що буде з командою, яка не розуміє важливості спілкування? Подивимось. Програмісти довго писатимуть код, стараючись, а інша частина команди буде просто чекати, поки вони передадуть естафету. Нарешті, вийде бета-версія, і всі будуть бурмотати про те, чому це зайняло так багато часу. І коли з’явиться перша вада, усі почнуть шукати когось іншого, кого винуватитимуть, але не способів уникнути ситуації, яка їх там завела. 

Якщо ми заглянемо глибше, то побачимо, що взаємні цілі були зрозумілі неправильно (або взагалі). І в такій ситуації ми отримаємо пошкоджений або дефектний продукт. 

Заохочуйте мультидисциплінарні команди

Найгірші особливості цієї ситуації:

  • Недостатня участь
  • Недостатня участь
  • Відсутність співпраці
  • Відсутність довіри

Як ми можемо це виправити? Буквально, змусивши людей говорити. 

Заохочуйте багатопрофільні команди

Давайте зберемо всіх разом, встановимо теми обговорень та призначимо щотижневі зустрічі: маркетинг з BI, програмісти з дизайнерами та спеціалістами з обробки даних. Тоді ми будемо сподіватися, що люди говорять про проект. Але цього все ще недостатньо, оскільки члени команди все ще не говорять про весь проект і не говорять з усією командою. Легко потрапити під сніг з десятками зустрічей, і немає виходу і немає часу, щоб зробити роботу. І ці повідомлення після зустрічей вб’ють решту часу та розуміння того, що робити далі. 

Тому зустріч - це лише перший крок. У нас все ще є деякі проблеми:

  • Погане спілкування
  • Відсутність спільних цілей
  • Недостатня участь

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

Це симптоми компанії, яка бореться з проблемами спілкування. І це починає їх виліковувати зустрічами. Але ми завжди маємо інше рішення.

Наведіть всіх на спілкування над проектом. 

Багатопрофільне спілкування в командах

Найкращі особливості цього підходу:

  • прозорість
  • Залучення
  • Обмін знаннями та навичками
  • Безперервна освіта

Це надзвичайно складна структура, яку важко створити. Можливо, ви знаєте кілька основ, які використовують такий підхід: Agile, Lean, Scrum. Неважливо, як ви його назвете; всі вони побудовані за принципом «робити все разом одночасно». Усі ці календарі, черги завдань, демонстраційні презентації та стендові зустрічі спрямовані на те, щоб люди часто і всі разом говорили про проект.

Ось чому Agile мені дуже подобається, оскільки він включає важливість спілкування як передумови виживання проекту.

І якщо ви вважаєте, що ви аналітик, який не любить Agile, подивіться на це по-іншому: це допоможе вам показати результати своєї роботи - всі ваші оброблені дані, ці чудові інформаційні панелі, ваші набори даних - щоб зробити людей оцініть ваші зусилля. Але для цього вам доведеться зустрітися зі своїми колегами та поговорити з ними за круглим столом.

Що далі? Усі почали говорити про проект. Тепер ми маємо довести якість проекту. Для цього компанії зазвичай наймають консультанта з найвищою професійною кваліфікацією. 

Основним критерієм хорошого консультанта (я можу вам сказати, тому що я консультант) є постійне зменшення його участі у проекті.

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

До речі, консультант не повинен складати звіти або стати для вас додатковою парою рук. Для цього у вас є свої внутрішні колеги.

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

Головною метою найму консультанта є освіта, виправлення структур та процесів та полегшення спілкування. Роль консультанта полягає не в щомісячній звітності, а в тому, щоб імплантувати себе в проект і бути повністю залученим до повсякденного розпорядку команди.

Добрий консультант зі стратегічного маркетингу заповнює прогалини в знаннях та розумінні учасників проекту. Але він або вона може ніколи не виконувати роботу за когось. І одного дня, всім потрібно буде добре працювати без консультанта. 

Результатами ефективного спілкування є відсутність полювання на відьом та вказівки пальцем. Перш ніж розпочати завдання, люди діляться своїми сумнівами та запитаннями з іншими членами команди. Таким чином, більшість проблем вирішуються до початку роботи. 

Давайте подивимося, як все це впливає на найскладнішу частину роботи з маркетингового аналізу: визначення потоків даних та об’єднання даних.

Як відображається структура комунікації при передачі та обробці даних?

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

На основі нашого прикладу, які запитання повинні задавати люди, щоб забезпечити чітке спілкування на кожному етапі обробки даних?

  • Етап збору даних. Якщо ми забули виміряти щось важливе, ми не можемо повернутися у минуле і переоцінити це. Що слід врахувати заздалегідь:
    • Якщо ми не знаємо, як назвати найважливіші параметри та змінні, як ми можемо боротися з усім безладом?
    • Як буде позначено події?
    • Яким буде унікальний ідентифікатор для обраних потоків даних?
    • Як ми будемо дбати про безпеку та конфіденційність? 
    • Як ми будемо збирати дані там, де існують обмеження щодо збору даних?
  • Злиття даних надходить у потік. Розглянемо наступне:
    • Основні принципи ETL: це пакетний або потоковий тип передачі даних? 
    • Як ми позначимо поєднання потокової та пакетної передачі даних? 
    • Як ми будемо коригувати їх в одній схемі даних без втрат і помилок?
    • Запитання щодо часу та хронології: Як ми перевіримо позначки часу? 
    • Як ми можемо дізнатись, чи оновлення та збагачення даних працює належним чином у межах позначок часу?
    • Як ми будемо перевіряти хіти? Що відбувається з недійсними зверненнями?

  • Етап агрегування даних. Що слід врахувати:
    • Спеціалізовані налаштування для процесів ETL: яке відношення ми маємо до недійсних даних?
      Виправити чи видалити? 
    • Чи можемо ми отримати від цього прибуток? 
    • Як це вплине на якість усього набору даних?

Перший принцип на всіх цих етапах полягає в тому, що помилки складаються одна на одну і успадковуються одна від одної. Дані, зібрані з недоліком на першому етапі, змусять голову злегка опікати на всіх наступних етапах. І другий принцип полягає в тому, що ви повинні вибирати пункти для забезпечення якості даних. Оскільки на етапі агрегування всі дані будуть змішані разом, і ви не зможете впливати на якість змішаних даних. Це дійсно важливо для проектів машинного навчання, де якість даних впливатиме на якість результатів машинного навчання. Хороші результати недосяжні за низькоякісних даних.

  • Візуалізація
    Це етап генерального директора. Можливо, ви вже чули про ситуацію, коли генеральний директор дивиться на цифри на інформаційній панелі і каже: «Добре, цього року ми отримали великий прибуток, навіть більший, ніж раніше, але чому всі фінансові параметри в червоній зоні ? " І в цей момент занадто пізно шукати помилки, оскільки їх треба було вловити давно.

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

Маркетинг BI: Snowplow, Google Analytics, Яндекс

Відповіді на більшість цих питань ви знайдете лише разом із усією командою. Тому що коли хтось приймає рішення на основі здогадок чи особистої думки, не перевіряючи ідею з іншими, можуть з’явитися помилки.

Складності є скрізь, навіть у найпростіших місцях.

Ось ще один приклад: під час відстеження показників показів товарних карток аналітик помічає помилку. У даних звернень усі покази з усіх банерів та карток продуктів були надіслані відразу після завантаження сторінки. Але ми не можемо бути впевнені, чи користувач дійсно переглянув усе на сторінці. Аналітик приходить до команди, щоб детально повідомити їх про це.

БІ каже, що ми не можемо так залишити ситуацію.

Як ми можемо розрахувати CPM, якщо ми навіть не можемо бути впевнені, чи був показаний товар? Який тоді кваліфікований рейтинг кліків для фотографій?

Маркетологи відповідають:

Дивіться, усі, ми можемо створити звіт, що показує найкращий рейтинг кліків, і перевірити його на подібному рекламному банері чи фотографії в інших місцях.

І тоді розробники скажуть:

Так, ми можемо вирішити цю проблему за допомогою нової інтеграції для відстеження прокрутки та перевірки видимості теми.

Нарешті, дизайнери UI / UX кажуть:

Ага! Ми можемо вибрати, чи потрібен нам нарешті лінивий чи вічний прокрутка чи пагінація!

Ось кроки, які пройшла ця невеличка команда:

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

Щоб вирішити цю проблему, їм слід перевірити збір даних з усіх систем. Часткове рішення в одній частині схеми даних не вирішить ділову проблему.

вирівняти налаштувати дизайн

Тому нам доводиться працювати разом. Дані потрібно збирати відповідально щодня, і це важка робота. І якість даних повинна бути досягнута наймання потрібних людей, придбання потрібних інструментів та вкладення грошей, часу та зусиль у побудову ефективних комунікаційних структур, які життєво необхідні для успіху організації.

Що ви думаєте?

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.