Where Collaboration Fails Around Data (And 4 Tips For Fixing It)

Перевидано Платоном

читають: 0

Де не вдається співпраця навколо даних (і 4 поради, як це виправити)
Зображення creativeart на Freepik

Команди обробки даних дедалі частіше працюють як команди розробників програмного забезпечення, використовуючи інструменти розробки та розробки для керування своєю роботою. Вони варіюються від систем контролю версій, таких як Github, до впровадження гнучких практик, таких як Kanban і Scrum, і включають церемонії, такі як щоденний стендап, спринтські зобов’язання та спринтські демонстрації. Цільові рішення (наприклад, dbt для моделювання даних, тестування та інтеграції) вийшли на ринок, підтримуючи мислення програмної інженерії. Ці рішення допомагають великим розподіленим групам даних працювати якнайкраще.

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

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

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

Загальні інструменти для співпраці та традиційні підходи до керування роботою швидко виходять з ладу в цих сценаріях. Команди продуктів і групи підтримки мають спеціально створені інструменти для керування своєю роботою. Хіба групам даних також не потрібне рішення для найкращого керування запитами зацікавлених сторін? Або інструменти для керування документацією підтримки чи навчання кінцевих користувачів? Найкращі групи обробки даних часто стикаються з труднощами з цією частиною свого робочого процесу, і в кінцевому підсумку приймають рішення, розроблені для інших (у цьому випадку команди продуктів і підтримки).

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

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

Взяти, наприклад, Джейн. Вона щойно приєдналася до компанії зі списку Fortune 500 як менеджер з продажу, керуючи розподіленою командою з 15 продавців, розкиданих по всьому південному сходу. На другий день її нової роботи вона пересилає електронний лист від колеги з кількома посиланнями на різні ресурси: електронну таблицю з інформацією про конвеєр, різноманітні звіти в Salesforce і декілька інформаційних панелей про індивідуальну ефективність у рішенні BI компанії. Провівши кілька хвилин на перегляд даних, вона розуміє, що поняття не має, на що вона насправді дивиться і що це означає. Вона надсилає повідомлення своєму менеджеру зі збуту з проханням про допомогу, а той звертається до свого партнера з групи даних, яка створила більшість цих ресурсів. Аналітик даних читає електронний лист, зітхає, а потім витрачає наступну годину на написання відповіді. Вони створюють заявку на своїй дошці JIRA, щоб «переоцінити документацію».

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

На жаль, люди, які найчастіше страждають від цієї динаміки, — це молодші співробітники або керівники середньої ланки на передовій, оскільки вони зазвичай мають менше влади в організації та найменший контекст для розуміння рішень, які приймаються щодо даних. Без інтенсивного навчання ці співробітники вразливі до типів комунікаційних проблем, які є результатом інформаційної асиметрії. Вони також схильні ставати жертвами «синдрому скрипучого колеса», коли голоси керівників і вищого керівництва, природно, найголосніше почуті групами даних (і тому їхні запити та потреби мають пріоритет над запитами та потребами інших).

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

Ось 4 проактивні поради для керівників даних, які хочуть зменшити інформаційну асиметрію та досягти кращої співпраці у своїх організаціях:

Налаштуйте організаційні та командні структури відповідно до потреб бізнесу. Це стосується не лише моделей звітності, але й ролей і функцій групи даних. Ми вже починаємо бачити більше оголошень про вакансії на такі посади, як «менеджер із обробки даних» або «майстер обробки даних». Ці нові функції допоможуть групам обробки даних впоратися з проблемами співпраці, які, зрештою, зазвичай стосуються людей і процесів, а не базових технологічних проблем.
Розгляньте можливість інвестування в матричну модель де члени вашої команди – або, у деяких випадках, цілі групи – підпорядковані певним бізнес-підрозділам. Це дозволить узгодити довгострокові ініціативи щодо даних із нагальними потребами бізнесу, сприяти обміну знаннями, а також тіснішим відносинам співпраці між аналітиками та тими, кого вони щоденно підтримують.
Почніть з малого й розвивайте свій успіх по ходу. сила першого враження неможливо переоцінити. Початкове сприйняття команди обробки даних надзвичайно важливе для того, як буде сприйнята їхня робота, тож заздалегідь подумайте про те, як це відбувається з ключовими членами команди. Зосередьтеся, побудувавши міцні стосунки з 1-2 ключовими лідерами в організації, які можуть допомогти поширити інформацію про те, наскільки ви неймовірні. Розгорніть звідти.
Пам’ятайте про інструменти співпраці можна використовувати протягом життєвого циклу ваших ініціатив і продуктів обробки даних. Наприклад, подумайте, як ви хочете згуртувати своїх людей, процеси та системи для кожної з наведених нижче категорій. Часто те, що спрацює в одній категорії, з тріском провалиться в інших:
- Співпраця в команді даних
- Загальна співпраця з іншими співробітниками за межами вашої команди
- Спеціальні запитання або запити на нові функції
- Постійна підтримка продуктів обробки даних
- Обсяг нових ініціатив або продуктів даних
- Розвиток вашої пропозиції даних на основі того, що є цінним для бізнесу

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

Ніколас Фройнд є досвідченим керівником галузі SaaS з більш ніж десятирічним досвідом ведення стартапів, зосереджених на розвитку продукту. Як засновник і генеральний директор Workstream.io, Нік очолює початковий технологічний стартап, який допомагає командам обробки даних керувати критично важливими даними. До Workstream Нік обіймав посаду віце-президента з операцій BetterCloud, незалежного постачальника програмного забезпечення, який пропонує провідне рішення SaaS Operations Management. Раніше Нік обіймав керівні фінансові посади в Tesla, здобуваючи ступінь MBA в Гарварді.