Per què la comunicació en equip és més important que la vostra pila Martech

Comunicació i anàlisi de l’equip de màrqueting

El punt de vista atípic de Simo Ahava sobre la qualitat de les dades i les estructures de comunicació va refrescar tot el saló del Aneu a Analytics! conferència. OWOX, el líder de MarTech a la regió de la CEI, va donar la benvinguda a milers d’experts en aquesta trobada per compartir els seus coneixements i idees.

Equip OWOX BI voldria que reflexionéssiu sobre el concepte proposat per Simo Ahava, que sens dubte té potencial per fer créixer el vostre negoci. 

La qualitat de les dades i la qualitat de l’organització

La qualitat de les dades depèn de la persona que les analitzi. Normalment, culparíem tots els defectes de les dades a eines, fluxos de treball i conjunts de dades. Però, és raonable?

Francament, la qualitat de les dades està directament relacionada amb la manera com ens comuniquem a les nostres organitzacions. La qualitat de l’organització ho determina tot, començant per l’enfocament de la mineria, estimació i mesurament de dades, continuant amb el processament i acabant amb la qualitat general del producte i la presa de decisions. 

Empreses i les seves estructures de comunicació

Imaginem que una empresa estigui especialitzada en una eina. La gent d’aquesta empresa és excel·lent en trobar determinats problemes i solucionar-los per al segment B2B. Tot està molt bé i, sens dubte, coneixeu un parell d’empreses com aquesta.

Els efectes secundaris de les activitats d’aquestes empreses s’amaguen en el procés a llarg termini d’augmentar els requisits de qualitat de les dades. Al mateix temps, hem de recordar que les eines creades per analitzar les dades només funcionen amb dades i estan aïllades dels problemes empresarials, fins i tot si es creen per resoldre-les. 

Per això ha aparegut un altre tipus d’empresa. Aquestes empreses estan especialitzades en la depuració de fluxos de treball. Poden trobar un munt de problemes en els processos empresarials, posar-los en una pissarra i dir als executius:

Aquí, aquí i allà! Apliqueu aquesta nova estratègia empresarial i estareu bé.

Però sembla massa bo per ser cert. L’eficiència dels consells que no es basen en la comprensió de les eines és dubtosa. I aquestes consultores tendeixen a no entendre per què van aparèixer aquests problemes, per què cada nou dia comporta noves complexitats i errors i quines eines es van configurar incorrectament.

Per tant, la utilitat d’aquestes empreses per si soles és limitada. 

Hi ha empreses amb experiència empresarial i coneixement d’eines. En aquestes empreses, tothom s’obsessiona contractant persones amb grans qualitats, experts que tinguin certes habilitats i coneixements. Guai. Però normalment aquestes empreses no estan destinades a resoldre problemes de comunicació dins de l’equip, que sovint consideren poc importants. Així, a mesura que apareixen nous problemes, comença la caça de bruixes: de qui és culpa? Potser els especialistes en BI han confós els processos? No, els programadors no van llegir la descripció tècnica. Però, en definitiva, el problema real és que l’equip no pot pensar clarament el problema per resoldre’l junts. 

Això ens demostra que, fins i tot en una empresa plena d’especialistes interessants, tot farà més esforç del necessari si l’organització no ho és madur suficient. La idea que has de ser l’adult i ser responsable, sobretot en una crisi, és l’últim en què la gent està pensant en la majoria de les empreses.

Fins i tot el meu fill de dos anys que va al jardí d’infants sembla més madur que algunes de les organitzacions amb què he treballat.

No podeu crear una empresa eficient només contractant un gran nombre d’especialistes, ja que tots són absorbits per algun grup o departament. Per tant, la direcció continua contractant especialistes, però res no canvia perquè l’estructura i la lògica del flux de treball no canvien gens.

Si no feu res per crear canals de comunicació dins i fora d’aquests grups i departaments, tots els vostres esforços no tindran cap sentit. Per això, l'estratègia de comunicació i la maduresa són els focus d'Ahava.

La llei de Conway s'aplica a les empreses d'Analytics

Dades significatives: la llei de Conway

Fa cinquanta anys, un gran programador anomenat Melvin Conway va fer un suggeriment que més tard es va conèixer popularment com la llei de Conway: 

Organitzacions que dissenyen sistemes. . . es limiten a produir dissenys que siguin còpies de les estructures de comunicació d’aquestes organitzacions.

Melvin Conway, Llei de Conway

Aquests pensaments van aparèixer en un moment en què un ordinador s’adaptava perfectament a una habitació. Imagineu-vos: aquí tenim un equip que treballa en un ordinador i allà tenim un altre equip que treballa en un altre equip. I, a la vida real, la llei de Conway significa que tots els defectes de comunicació que apareixen entre aquests equips es reflectiran en l'estructura i la funcionalitat dels programes que desenvolupen. 

Nota de l'autor:

Aquesta teoria s'ha provat centenars de vegades al món del desenvolupament i s'ha discutit molt. La definició més segura de la llei de Conway va ser creada per Pieter Hintjens, un dels programadors més influents de principis de la dècada de 2000, que va dir que "si esteu en una organització de merda, fabricareu un programari de merda". (Amdahl a Zipf: deu lleis de la física de les persones)

És fàcil veure com funciona aquesta llei al món del màrqueting i l’anàlisi. En aquest món, les empreses treballen amb grans quantitats de dades recopilades de diferents fonts. Tots podem estar d’acord que les dades en si són justes. Però si inspeccioneu de prop els conjunts de dades, veureu totes les imperfeccions de les organitzacions que van recopilar aquestes dades:

  • Falten valors en què els enginyers no han parlat d'un problema 
  • Formats equivocats en què ningú no va fer cas i ningú va discutir el nombre de decimals
  • Retards de comunicació on ningú coneix el format de transferència (batch o stream) i qui ha de rebre les dades

Per això, els sistemes d’intercanvi de dades revelen completament les nostres imperfeccions.

La qualitat de les dades és l’assoliment d’especialistes en eines, experts en fluxos de treball, gestors i la comunicació entre totes aquestes persones.

Les millors i les pitjors estructures de comunicació per a equips multidisciplinaris

Un equip de projecte típic d'una empresa analítica de màrqueting o MarTech està format per especialistes en intel·ligència empresarial (BI), científics de dades, dissenyadors, professionals del màrqueting, analistes i programadors (en qualsevol combinació).

Però, què passarà en un equip que no entengui la importància de la comunicació? A veure. Els programadors escriuran codi durant molt de temps, tot esforçant-se, mentre que una altra part de l’equip només esperarà que passin la batuta. Per fi, es publicarà la versió beta i tothom es murmurarà sobre per què ha trigat tant. I quan aparegui el primer defecte, tothom començarà a buscar algú a qui culpar, però no a maneres d’evitar la situació que els va fer arribar. 

Si mirem més a fons, veurem que els objectius mutus no s’entenien correctament (ni en absolut). I en aquesta situació, obtindrem un producte danyat o defectuós. 

Fomenteu els equips multidisciplinaris

Les pitjors característiques d'aquesta situació:

  • Implicació insuficient
  • Participació insuficient
  • Manca de cooperació
  • Falta de confiança

Com ho podem solucionar? Literalment fent parlar a la gent. 

Fomentar els equips multidisciplinaris

Reunim tothom, fixem temes de discussió i programem reunions setmanals: màrqueting amb BI, programadors amb dissenyadors i especialistes en dades. Després esperem que la gent parli del projecte. Però això encara no és suficient perquè els membres de l’equip encara no parlen de tot el projecte i no parlen amb tot l’equip. És fàcil deixar-se nevar amb desenes de reunions i sense sortida i sense temps per fer la feina. I aquests missatges després de les reunions mataran la resta del temps i la comprensió de què fer després. 

Per això, reunir-se només és el primer pas. Encara tenim alguns problemes:

  • Mala comunicació
  • Manca d’objectius mutus
  • Implicació insuficient

De vegades, la gent intenta transmetre informació important sobre el projecte als seus col·legues. Però en lloc de passar el missatge, la màquina de rumors ho fa tot per ells. Quan la gent no sàpiga compartir els seus pensaments i idees adequadament i en un entorn adequat, la informació es perdrà en el camí cap al destinatari. 

Aquests són els símptomes d’una empresa que té problemes de comunicació. I comença a curar-los amb reunions. Però sempre tenim una altra solució.

Conduir a tothom a comunicar-se sobre el projecte. 

Comunicació multidisciplinària en equips

Les millors característiques d’aquest enfocament:

  • Transparència
  • Implicació
  • Intercanvi de coneixements i habilitats
  • Educació sense parar

Es tracta d’una estructura extremadament complexa i difícil de crear. És possible que conegueu alguns marcs que adopten aquest enfocament: Agile, Lean, Scrum. Tant se val com l’anomenis; tots ells es basen en el principi de "fer-ho tot junt al mateix temps". Tots aquests calendaris, cues de tasques, presentacions de demostracions i reunions stand-up tenen com a objectiu fer que la gent parli del projecte amb freqüència i tots junts.

Per això, Agile m’agrada molt, ja que inclou la importància de la comunicació com a requisit previ per a la supervivència del projecte.

I si creieu que sou un analista a qui no li agrada Agile, mireu-ho d’una altra manera: us ajuda a mostrar els resultats del vostre treball (totes les vostres dades processades, aquests grans taulers, els vostres conjunts de dades) per fer que la gent agraeixo els vostres esforços. Però per fer-ho, heu de conèixer els vostres companys i parlar amb ells a la taula rodona.

Que segueix? Tothom ha començat a parlar del projecte. Ara ho tenim per demostrar la qualitat del projecte. Per fer-ho, les empreses solen contractar un consultor amb les més altes qualificacions professionals. 

El criteri principal d’un bon consultor (us ho puc dir perquè sóc consultor) és disminuir constantment la seva participació en el projecte.

Un consultor no només pot alimentar a una empresa petits trossos de secrets professionals perquè això no farà que l’empresa sigui madura i autosuficient. Si la vostra empresa ja no pot viure sense el vostre assessor, hauríeu de tenir en compte la qualitat del servei que heu rebut. 

Per cert, un consultor no hauria de fer informes ni convertir-se en un parell de mans addicionals. Teniu els vostres companys interns per això.

Contractar venedors per a educació, no delegació

L’objectiu principal de contractar un consultor és l’educació, la fixació d’estructures i processos i facilitar la comunicació. El paper d'un consultor no és la presentació d'informes mensuals, sinó que s'implanta a si mateix en el projecte i està totalment involucrat en la rutina diària de l'equip.

Un bon consultor de màrqueting estratègic omple els buits en el coneixement i la comprensió dels participants del projecte. Però pot ser que ell o ella mai no faci la feina per algú. I un dia, tothom haurà de treballar bé sense el consultor. 

Els resultats d’una comunicació eficaç són l’absència de caça de bruixes i l’assenyalament amb els dits. Abans d’iniciar una tasca, la gent comparteix els seus dubtes i preguntes amb altres membres de l’equip. Per tant, la majoria dels problemes es resolen abans de començar el treball. 

Vegem com tot això influeix en la part més complicada de la feina d’anàlisi de màrqueting: definir els fluxos de dades i combinar les dades.

Com es reflecteix l'estructura de la comunicació en la transferència i processament de dades?

Suposem que tenim tres fonts que ens proporcionen les dades següents: dades de trànsit, dades de productes de comerç electrònic / dades de compra del programa de fidelització i dades d’anàlisi mòbil. Passarem les etapes del processament de dades una per una, des de la transmissió de totes aquestes dades a Google Cloud fins a l’enviament de tot per a la seva visualització Google Data Studio amb l'ajuda de Google BigQuery

Basant-nos en el nostre exemple, quines preguntes s’han de fer les persones per garantir una comunicació clara durant cada etapa del processament de dades?

  • Etapa de recollida de dades. Si oblidem mesurar quelcom important, no podem tornar enrere en el temps i tornar-lo a mesurar. Coses a tenir en compte per endavant:
    • Si no sabem com anomenar els paràmetres i les variables més importants, com podem fer front a tot l’embolic?
    • Com es marcaran els esdeveniments?
    • Quin serà l’identificador únic per als fluxos de dades escollits?
    • Com ens ocuparem de la seguretat i la privadesa? 
    • Com recopilarem dades quan hi hagi limitacions en la recopilació de dades?
  • La fusió de fluxos de dades al flux. Penseu en el següent:
    • Principis principals de l'ETL: és un tipus de transferència de dades per lots o flux? 
    • Com marcarem la conjunció de les transferències de dades de flux i de lots? 
    • Com els ajustarem en el mateix esquema de dades sense pèrdues ni errors?
    • Preguntes sobre temps i cronologia: com comprovarem les marques de temps? 
    • Com podem saber si la renovació i enriquiment de dades funciona correctament dins de les marques de temps?
    • Com validarem les visites? Què passa amb les visites no vàlides?

  • Etapa d’agregació de dades. Coses a tenir en compte:
    • Configuració especialitzada per a processos ETL: què hem de fer amb dades no vàlides?
      Patch o suprimir? 
    • En podem obtenir beneficis? 
    • Com impactarà la qualitat de tot el conjunt de dades?

El primer principi per a totes aquestes etapes és que els errors s’apilen els uns sobre els altres i s’hereten els uns dels altres. Les dades recollides amb un defecte a la primera etapa us faran cremar lleugerament el cap durant totes les etapes posteriors. I el segon principi és que heu de triar punts per garantir la qualitat de les dades. Com que a l’etapa d’agregació, totes les dades es barrejaran i no podreu influir en la qualitat de les dades mixtes. Això és realment important per als projectes d’aprenentatge automàtic, on la qualitat de les dades afectarà la qualitat dels resultats d’aprenentatge automàtic. No es poden obtenir bons resultats amb dades de baixa qualitat.

  • Visualització
    Aquesta és l’etapa del CEO. És possible que hagueu sentit a parlar de la situació quan el conseller delegat mira els números del quadre de comandament i diu: “D’acord, aquest any tenim molts beneficis, fins i tot més que abans, però per què hi ha tots els paràmetres financers a la zona vermella? ? ” I en aquest moment, és massa tard per buscar els errors, ja que s’haurien d’haver agafat fa molt de temps.

Tot es basa en la comunicació. I sobre els temes de conversa. A continuació, es mostra un exemple del que s’hauria de discutir durant la preparació de la transmissió de Yandex:

BI de màrqueting: Snowplow, Google Analytics, Yandex

Les respostes a la majoria d’aquestes preguntes només les trobareu junt amb tot el vostre equip. Perquè quan algú pren una decisió basada en l’endevinalla o l’opinió personal sense provar la idea amb altres persones, poden aparèixer errors.

Les complexitats són a tot arreu, fins i tot als llocs més senzills.

Aquí teniu un exemple més: quan fa un seguiment de les puntuacions d’impressions de les targetes de producte, un analista nota un error. A les dades de petició de fitxer, totes les impressions de tots els bàners i targetes de producte es van enviar just després de carregar la pàgina. Però no podem estar segurs de si l’usuari realment ha mirat tot el que hi ha a la pàgina. L'analista arriba a l'equip per informar-los detalladament sobre això.

El BI diu que no podem deixar la situació així.

Com podem calcular el CPM si ni tan sols podem estar segurs de si es va mostrar el producte? Quin és el CTR qualificat per a les imatges?

Els professionals del màrqueting responen:

Mireu, tothom, podem crear un informe que mostri el millor CTR i el puguem verificar amb una foto o un bàner creatiu similar en altres llocs.

I llavors els desenvolupadors diran:

Sí, podem solucionar aquest problema amb l'ajuda de la nostra nova integració per al seguiment del desplaçament i la comprovació de la visibilitat del tema.

Finalment, els dissenyadors UI / UX diuen:

Sí! Podem triar si finalment necessitem un desplaçament o una paginació mandrosa o eterna.

Aquests són els passos que va passar aquest petit equip:

  1. Definit el problema
  2. Presentar les conseqüències empresarials del problema
  3. Mesurar l'impacte dels canvis
  4. Decisions tècniques presentades
  5. Va descobrir els beneficis no trivials

Per solucionar aquest problema, haurien de comprovar la recopilació de dades de tots els sistemes. Una solució parcial en una part de l’esquema de dades no resoldrà el problema empresarial.

disseny d'ajust d'alineació

Per això hem de treballar junts. Les dades s’han de recollir cada dia amb responsabilitat i fer-ho és molt dur. I la la qualitat de les dades ha de ser assolida per contractar a les persones adequades, comprar les eines adequades i invertir diners, temps i esforç en la construcció d’estructures de comunicació efectives, que són vitals per a l’èxit d’una organització.

Què et sembla?

Aquest lloc utilitza Akismet per reduir el correu no desitjat. Esbrineu com es processa el vostre comentari.