Por que a comunicación en equipo é máis importante que a súa pila Martech

Comunicación e análise do equipo de marketing

O atípico punto de vista de Simo Ahava sobre a calidade dos datos e as estruturas de comunicación refrescou todo o salón do Go Analytics! conferencia. OWOX, o líder de MarTech na rexión da CEI, deu a benvida a miles de expertos a esta reunión para compartir os seus coñecementos e ideas.

Equipo OWOX BI gustaríache que reflexionases sobre o concepto proposto por Simo Ahava, que definitivamente ten potencial para facer medrar o teu negocio. 

A calidade dos datos e a calidade da organización

A calidade dos datos depende da persoa que os estea a analizar. Normalmente, culparíamos a todos os defectos dos datos en ferramentas, fluxos de traballo e conxuntos de datos. Pero, ¿é razoable?

Francamente falando, a calidade dos datos está directamente ligada a como nos comunicamos dentro das nosas organizacións. A calidade da organización determina todo, comezando polo enfoque de extracción de datos, estimación e medición, continuando co procesamento e rematando coa calidade xeral do produto e a toma de decisións. 

As empresas e as súas estruturas de comunicación

Imaxinemos que unha empresa está especializada nunha ferramenta. A xente desta empresa é excelente ao atopar determinados problemas e resolvelos para o segmento B2B. Todo está moi ben e, sen dúbida, coñeces a un par de empresas coma esta.

Os efectos secundarios das actividades destas empresas están escondidos no proceso a longo prazo de elevar os requisitos de calidade dos datos. Ao mesmo tempo, debemos lembrar que as ferramentas creadas para analizar datos só funcionan con datos e están illadas dos problemas comerciais, aínda que sexan creadas para resolvelos. 

Por iso apareceu outro tipo de empresa. Estas empresas están especializadas na depuración do fluxo de traballo. Poden atopar unha chea de problemas nos procesos comerciais, poñelos nunha pizarra e dicir aos executivos:

Aquí, aquí e alí! Aplica esta nova estratexia empresarial e estarás ben.

Pero parece demasiado bo para ser verdade. É dudosa a eficiencia dun consello que non se basea na comprensión das ferramentas. E esas consultoras tenden a non entender por que apareceron estes problemas, por que cada novo día trae novas complexidades e erros e que ferramentas se configuraron incorrectamente.

Polo tanto, a utilidade destas empresas por conta propia é limitada. 

Hai empresas con coñecementos empresariais e coñecemento de ferramentas. Nestas empresas, todo o mundo está obsesionado por contratar persoas con grandes calidades, expertos seguros nas súas habilidades e coñecementos. Fresco. Pero normalmente, estas empresas non están dirixidas a resolver problemas de comunicación dentro do equipo, que a miúdo ven sen importancia. Así, a medida que aparecen novos problemas, comeza a caza de bruxas: de quen é culpa? Quizais os especialistas en BI confundiron os procesos? Non, os programadores non leron a descrición técnica. Pero, en definitiva, o verdadeiro problema é que o equipo non pode pensar o problema claramente para resolvelo xuntos. 

Isto móstranos que incluso nunha empresa chea de especialistas interesantes, todo levará máis esforzo do necesario se a organización non o é madura suficiente. A idea de que tes que ser o adulto e ser responsable, especialmente nunha crise, é o último no que a xente está a pensar na maioría das empresas.

Ata o meu fillo de dous anos que vai ao xardín de infancia parece máis maduro que algunhas das organizacións coas que traballei.

Non podes crear unha empresa eficiente só contratando un gran número de especialistas, xa que todos están absorbidos por algún grupo ou departamento. Así, a dirección segue contratando especialistas, pero nada cambia porque a estrutura e a lóxica do fluxo de traballo non cambian en absoluto.

Se non fas nada para crear canles de comunicación dentro e fóra destes grupos e departamentos, todos os teus esforzos non terán sentido. É por iso que Ahava é o foco da estratexia e madurez de comunicación.

A lei de Conway aplicouse ás empresas analíticas

Datos significativos: lei de Conway

Hai cincuenta anos, un gran programador chamado Melvin Conway fixo unha suxestión que máis tarde se coñeceu popularmente como lei de Conway: 

Organizacións que deseñan sistemas. . . están obrigados a producir deseños que sexan copias das estruturas de comunicación destas organizacións.

Melvin Conway, a lei de Conway

Estes pensamentos apareceron nun momento no que un ordenador encaixaba perfectamente nunha habitación. Imaxina: aquí temos un equipo traballando nun ordenador e alí temos outro equipo traballando noutro ordenador. E na vida real, a lei de Conway significa que todos os fallos de comunicación que aparecen entre eses equipos se reflectirán na estrutura e funcionalidade dos programas que desenvolven. 

Nota do autor:

Esta teoría probouse centos de veces no mundo do desenvolvemento e falouse moito. A definición máis certa da lei de Conway creouna Pieter Hintjens, un dos programadores máis influentes de principios dos anos 2000, que dixo que "se estás nunha organización de merda, farás un software de merda". (Amdahl a Zipf: dez leis da física das persoas)

É doado ver como funciona esta lei no mundo da mercadotecnia e a analítica. Neste mundo, as empresas están a traballar con cantidades xigantes de datos recollidos de diferentes fontes. Todos podemos estar de acordo en que os datos en si son xustos. Pero se inspecciona de cerca os conxuntos de datos, verá todas as imperfeccións das organizacións que recompilaron estes datos:

  • Faltan valores nos que os enxeñeiros non falaron dun problema 
  • Formatos erróneos onde ninguén prestou atención e ninguén discutiu o número de decimais
  • Atrasos na comunicación se ninguén coñece o formato de transferencia (lote ou fluxo) e quen debe recibir os datos

É por iso que os sistemas de intercambio de datos revelan completamente as nosas imperfeccións.

A calidade dos datos é o logro de especialistas en ferramentas, expertos en fluxos de traballo, xestores e a comunicación entre todas estas persoas.

As mellores e as peores estruturas de comunicación para equipos multidisciplinares

Un equipo de proxecto típico nunha empresa de análise de mercadotecnia ou MarTech está composto por especialistas en intelixencia de negocio (BI), científicos de datos, deseñadores, comerciantes, analistas e programadores (en calquera combinación).

Pero que pasará nun equipo que non entende a importancia da comunicación? Vexamos. Os programadores escribirán código durante moito tempo, esforzándose moito, mentres que outra parte do equipo só agardará a que pasen a batuta. Por fin, a versión beta lanzarase e todo o mundo murmurará por que tardou tanto. E cando apareza o primeiro defecto, todos comezarán a buscar a outra persoa á que culpar, pero non a formas de evitar a situación que os levou alí. 

Se miramos máis profundamente, veremos que os obxectivos mutuos non se entendían correctamente (nin en absoluto). E nesa situación, obteremos un produto danado ou defectuoso. 

Animar aos equipos multidisciplinares

As peores características desta situación:

  • Implicación insuficiente
  • Participación insuficiente
  • Falta de cooperación
  • Falta de confianza

Como podemos solucionalo? Literalmente facendo falar á xente. 

Fomentar os equipos multidisciplinares

Reunamos a todos, fixemos temas de discusión e programemos reunións semanais: mercadotecnia con BI, programadores con deseñadores e especialistas en datos. Logo esperamos que a xente fale do proxecto. Pero iso aínda non é suficiente porque os membros do equipo aínda non falan de todo o proxecto e non falan con todo o equipo. É doado estar nevado con decenas de reunións e sen saída e sen tempo para facer o traballo. E esas mensaxes despois das reunións matarán o resto do tempo e comprenderán que facer despois. 

É por iso que reunirse son só o primeiro paso. Aínda temos algúns problemas:

  • Mala comunicación
  • Falta de obxectivos mutuos
  • Implicación insuficiente

Ás veces, a xente tenta transmitir información importante sobre o proxecto aos seus colegas. Pero en vez de pasar a mensaxe, a máquina de rumores fai de todo por eles. Cando as persoas non saben compartir os seus pensamentos e ideas correctamente e no ambiente adecuado, a información perderase no camiño cara ao destinatario. 

Estes son síntomas dunha empresa que loita con problemas de comunicación. E comeza a curalos con reunións. Pero sempre temos outra solución.

Leva a todos a comunicarse sobre o proxecto. 

Comunicación multidisciplinar en equipos

As mellores características deste enfoque:

  • Transparencia
  • Implicación
  • Intercambio de coñecementos e habilidades
  • Educación sen parar

Esta é unha estrutura extremadamente complexa que é difícil de crear. Pode que coñezas algúns marcos que adoptan este enfoque: Áxil, Lean, Scrum. Non importa como o nomees; todos eles están construídos sobre o principio de "facer todo xuntos ao mesmo tempo". Todos eses calendarios, colas de tarefas, presentacións de demostracións e reunións de stand-up están dirixidos a facer falar á xente do proxecto con frecuencia e todos xuntos.

É por iso que me gusta moito Agile, porque inclúe a importancia da comunicación como requisito previo para a supervivencia do proxecto.

E se cres que es un analista ao que non lle gusta Agile, fíxate doutro xeito: axúdache a amosar os resultados do teu traballo (todos os teus datos procesados, eses estupendos cadros de mandos, os teus conxuntos de datos) para facer que a xente agradece os teus esforzos. Pero para iso tes que coñecer aos teus colegas e falar con eles na mesa redonda.

Que é o seguinte? Todo o mundo comezou a falar do proxecto. Agora temos para demostrar a calidade do proxecto. Para iso, as empresas adoitan contratar a un consultor coas máis altas cualificacións profesionais. 

O criterio principal dun bo consultor (podo dicirlle porque son consultor) é diminuír constantemente a súa participación no proxecto.

Un consultor non pode alimentar a unha empresa pequenos anacos de segredos profesionais porque iso non fará que a empresa sexa madura e autosuficiente. Se a súa empresa xa non pode vivir sen o seu consultor, debería considerar a calidade do servizo que recibiu. 

Por certo, un consultor non debería facer informes nin converterse nun par de mans adicional para vostede. Para iso tes aos teus colegas internos.

Contrata comerciantes para a educación, non delegación

O obxectivo principal da contratación dun consultor é a educación, arranxar estruturas e procesos e facilitar a comunicación. O papel dun consultor non é a elaboración de informes mensuais, senón que se implanta no proxecto e está totalmente implicado na rutina diaria do equipo.

Unha boa consultor de mercadotecnia estratéxica enche lagoas no coñecemento e comprensión dos participantes no proxecto. Pero pode que el ou ela nunca faga o traballo por alguén. E un día, todos terán que traballar ben sen o consultor. 

Os resultados dunha comunicación eficaz son a ausencia de caza de bruxas e o sinalamento dos dedos. Antes de comezar unha tarefa, a xente comparte as súas dúbidas e preguntas con outros membros do equipo. Así, a maioría dos problemas resólvense antes de comezar o traballo. 

Vexamos como todo iso inflúe na parte máis complicada do traballo de análise de mercadotecnia: a definición de fluxos de datos e a fusión de datos.

Como se reflicte a estrutura de comunicación na transferencia e procesamento de datos?

Supoñamos que temos tres fontes que nos proporcionan os seguintes datos: datos de tráfico, datos de produtos de comercio electrónico / datos de compra do programa de fidelización e datos de análise móbil. Pasaremos as etapas de procesamento de datos unha por unha, desde a transmisión de todos eses datos a Google Cloud ata o envío de todo para a súa visualización Google Data Studio coa axuda de Google BigQuery

Baseado no noso exemplo, que preguntas deberían facerse as persoas para garantir unha comunicación clara durante cada etapa do procesamento de datos?

  • Etapa de recollida de datos. Se esquecemos medir algo importante, non podemos retroceder no tempo e volver medilo. Cousas a ter en conta de antemán:
    • Se non sabemos como nomear os parámetros e variables máis importantes, como podemos tratar con todos os desordes?
    • Como se marcarán os eventos?
    • Cal será o identificador único para os fluxos de datos escollidos?
    • Como coidaremos a seguridade e privacidade? 
    • Como recompilaremos datos onde hai limitacións na recollida de datos?
  • A fusión de fluxos de datos ao fluxo. Considere o seguinte:
    • Principios principais de ETL: é un tipo de transferencia de datos por lotes ou fluxos? 
    • Como marcaremos a conxunción das transmisións de fluxos e de lotes? 
    • Como os axustaremos no mesmo esquema de datos sen perdas e erros?
    • Preguntas sobre tempo e cronoloxía: como comprobaremos as marcas de tempo? 
    • Como podemos saber se a renovación e enriquecemento de datos funciona correctamente dentro das marcas de tempo?
    • Como validaremos os accesos? Que ocorre cos accesos non válidos?

  • Etapa de agregación de datos. Cousas a ter en conta:
    • Configuración especializada para procesos ETL: que temos que facer con datos non válidos?
      Parche ou elimina? 
    • ¿Podemos obter beneficios del? 
    • Como repercutirá na calidade de todo o conxunto de datos?

O primeiro principio para todas estas etapas é que os erros se acumulan uns sobre outros e se herdan uns dos outros. Os datos recollidos cun fallo na primeira etapa farán que a cabeza arda lixeiramente durante todas as etapas posteriores. E o segundo principio é que debes escoller puntos para garantir a calidade dos datos. Porque na fase de agregación, todos os datos mesturaranse e non poderás influír na calidade dos datos mesturados. Isto é realmente importante para proxectos de aprendizaxe automática, onde a calidade dos datos afectará á calidade dos resultados de aprendizaxe automática. Os bos resultados son inalcanzables con datos de baixa calidade.

  • Visualización
    Esta é a etapa do CEO. Quizais escoitaches falar da situación cando o CEO mira os números do panel e di: "Está ben, temos moitos beneficios este ano, incluso máis que antes, pero por que están todos os parámetros financeiros na zona vermella? ? ” E neste momento, é demasiado tarde para buscar os erros, xa que deberían ser atrapados hai moito tempo.

Todo está baseado na comunicación. E sobre os temas da conversa. Aquí tes un exemplo do que se debería discutir ao preparar a transmisión de Yandex:

Marketing BI: quitaneves, Google Analytics, Yandex

As respostas á maioría destas preguntas só as atoparás xunto con todo o teu equipo. Porque cando alguén toma unha decisión baseada en adiviñas ou na opinión persoal sen probar a idea con outros, poden aparecer erros.

As complexidades están en todas partes, incluso nos lugares máis sinxelos.

Aquí tes un exemplo máis: ao rastrexar as puntuacións de impresións das tarxetas de produto, un analista nota un erro. Nos datos de éxito, todas as impresións de todas as pancartas e tarxetas de produto enviáronse xusto despois de cargar a páxina. Pero non podemos estar seguros de se o usuario realmente mirou todo o que hai na páxina. O analista chega ao equipo para informarlles sobre isto en detalle.

A BI di que non podemos deixar a situación así.

Como podemos calcular o CPM se nin sequera podemos estar seguros de se se amosou o produto? Cal é entón o CTR cualificado para as imaxes?

Os comerciantes responden:

Mira, todos podemos crear un informe que mostre o mellor CTR e verificalo noutro lugar cunha foto ou unha pancarta creativa similar.

E entón os desenvolvedores dirán:

Si, podemos solucionar este problema coa axuda da nosa nova integración para o seguimento do desprazamento e a comprobación da visibilidade do asunto.

Finalmente, os deseñadores de UI / UX din:

¡Si! Podemos escoller se precisamos por fin o rolo ou a paxinación preguiceiros ou eternos.

Aquí están os pasos polos que pasou este pequeno equipo:

  1. Definiu o problema
  2. Presentou as consecuencias empresariais do problema
  3. Mediu o impacto dos cambios
  4. Decisións técnicas presentadas
  5. Descubrín o beneficio non trivial

Para solucionar este problema, deberían comprobar a recollida de datos de todos os sistemas. Unha solución parcial nunha parte do esquema de datos non resolverá o problema comercial.

aliñar deseño de axuste

Por iso temos que traballar xuntos. Os datos deben recollerse de forma responsable cada día e é un traballo duro facelo. E o a calidade dos datos debe ser alcanzada por contratar ás persoas axeitadas, mercar as ferramentas adecuadas e investir cartos, tempo e esforzo na construción de estruturas de comunicación eficaces, que son vitais para o éxito dunha organización.

¿Que pensas?

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.