Kial Teama Komunikado Pli Gravas Ol Via Marteca Stako

Komunikado kaj Analizo pri Merkata Teamo

La maltipa vidpunkto de Simo Ahava pri kvalito de datumoj kaj komunikaj strukturoj refreŝigis la tutan salonon ĉe la Iru Analitiko! konferenco. OWOX, la MarTech-gvidanto en la regiono CEI, bonvenigis milojn da spertuloj al ĉi tiu kunveno por dividi siajn sciojn kaj ideojn.

OWOX-BI-teamo ŝatus, ke vi pripensu la koncepton proponitan de Simo Ahava, kiu sendube havas eblon kreskigi vian kompanion. 

La Kvalito de Datumoj kaj Kvalito de la Organizo

La kvalito de datumoj dependas de la persono, kiu analizas ĝin. Tipe ni kulpigus ĉiujn mankojn en la datumoj pri iloj, laborfluoj kaj datumaroj. Sed ĉu tio estas racia?

Sincere dirante, la kvalito de datumoj estas rekte ligita al kiel ni komunikas ene de niaj organizoj. La kvalito de la organizo determinas ĉion, komencante per la aliro al datuma minado, takso kaj mezurado, daŭrigante per prilaborado, kaj finante per la ĝenerala kvalito de la produkto kaj decidado. 

Kompanioj kaj Iliaj Komunikadaj Strukturoj

Ni imagu, ke kompanio specialiĝas pri unu ilo. La homoj en ĉi tiu kompanio bonege trovas iujn problemojn kaj solvas ilin por la B2B-segmento. Ĉio bonas, kaj sendube vi konas kelkajn kompaniojn kiel ĉi tio.

La kromefikoj de la agadoj de ĉi tiuj kompanioj kaŝiĝas en la longtempa procezo levi la postulojn pri datuma kvalito. Samtempe ni devas memori, ke iloj kreitaj por analizi datumojn funkcias nur kun datumoj kaj estas izolitaj de la komercaj problemoj - eĉ se ili estas kreitaj por solvi ilin. 

Tial aperis alia speco de firmao. Ĉi tiuj kompanioj estas specialigitaj pri laborfluo-elpurigado. Ili povas trovi multajn problemojn en komercaj procezoj, meti ilin sur blankan tabulon kaj diri al la ekzekutivoj:

Jen, jen kaj jen! Apliku ĉi tiun novan komercan strategion kaj vi fartos bone!

Sed ĝi sonas tro bone por esti vera. La efikeco de konsiloj, kiuj ne baziĝas sur kompreno de la iloj, estas dubinda. Kaj tiuj konsilantaj firmaoj emas ne kompreni kial tiaj problemoj aperis, kial ĉiu nova tago alportas novajn kompleksecojn kaj erarojn, kaj kiuj iloj estis malĝuste instalitaj.

Do la utileco de ĉi tiuj kompanioj mem estas limigita. 

Estas kompanioj kun kaj komerca kompetenteco kaj scio pri iloj. En ĉi tiuj kompanioj, ĉiuj obsedas dungi homojn kun grandaj kvalitoj, spertuloj certaj pri siaj kapabloj kaj scioj. Malvarmeta. Sed kutime ĉi tiuj kompanioj ne celas solvi komunikajn problemojn ene de la teamo, kiujn ili ofte konsideras malgravaj. Do kiam novaj problemoj aperas, la sorĉistino ĉasas - kies kulpo estas ĝi? Eble la BI-specialistoj konfuzis la procezojn? Ne, la programistoj ne legis la teknikan priskribon. Sed entute la vera problemo estas, ke la teamo ne povas klare pripensi la problemon por solvi ĝin kune. 

Ĉi tio montras al ni, ke eĉ en kompanio plenigita de bonaj specialistoj, ĉio bezonos pli da peno ol necese se la organizo ne estas maturaj sufiĉe. La ideo, ke vi devas esti plenkreskulo kaj esti respondeca, precipe en krizo, estas la lasta afero, kiun homoj pensas en plej multaj kompanioj.

Eĉ mia dujara infano, kiu iras al infanĝardeno, ŝajnas pli matura ol iuj el la organizoj kun kiuj mi laboris.

Vi ne povas krei efikan kompanion nur per dungado de multaj specialistoj, ĉar ĉiuj estas absorbitaj de iu grupo aŭ fako. Do administrado daŭre dungas specialistojn, sed nenio ŝanĝiĝas ĉar la strukturo kaj logiko de la laborfluo tute ne ŝanĝiĝas.

Se vi faras nenion por krei komunikajn kanalojn ene kaj ekstere de ĉi tiuj grupoj kaj fakoj, ĉiuj viaj klopodoj estos sensencaj. Tial komunika strategio kaj matureco estas la fokuso de Ahava.

Leĝo de Conway Aplikita al Analizaj Kompanioj

Signifaj Datumoj - Leĝo de Conway

Antaŭ kvindek jaroj, granda programisto nomata Melvin Conway faris sugeston, kiu poste populare nomiĝis leĝo de Conway: 

Organizoj, kiuj projektas sistemojn. . . estas devigitaj produkti projektojn, kiuj estas kopioj de la komunikaj strukturoj de ĉi tiuj organizoj.

Melvin Conway, Leĝo de Conway

Ĉi tiuj pensoj aperis en tempo, kiam unu komputilo perfekte kongruis kun unu ĉambro! Imagu nur: Ĉi tie ni havas unu teamon laborantan sur unu komputilo, kaj tie ni havas alian teamon laborantan sur alia komputilo. Kaj en la reala vivo, la leĝo de Conway signifas, ke ĉiuj komunikaj mankoj, kiuj aperas inter tiuj teamoj, speguliĝos en la strukturo kaj funkcieco de la programoj, kiujn ili disvolvas. 

Noto de la aŭtoro:

Ĉi tiu teorio estis provita centfoje en la disvolva mondo kaj multe diskutiĝis. La plej certa difino de la leĝo de Conway estis kreita de Pieter Hintjens, unu el la plej influaj programistoj de la fruaj 2000-aj jaroj, kiu diris, ke "se vi estas en aĉa organizo, vi faros aĉan programaron." (Amdahl al Zipf: Dek Leĝoj de la Fiziko de Homoj)

Estas facile vidi kiel funkcias ĉi tiu leĝo en la merkatada kaj analiza mondo. En ĉi tiu mondo, kompanioj laboras kun gigantaj kvantoj da datumoj kolektitaj de malsamaj fontoj. Ni ĉiuj povas konsenti, ke datumoj mem estas justaj. Sed se vi zorge inspektas datumojn, vi vidos ĉiujn neperfektaĵojn de la organizoj, kiuj kolektis tiujn datumojn:

  • Mankas valoroj, kie inĝenieroj ne priparolis aferon 
  • Malĝustaj formatoj, kie neniu atentis kaj neniu diskutis pri la nombro de dekumaj lokoj
  • Komunikado prokrastas, kie neniu scias la formaton de transdono (bato aŭ rivereto) kaj kiu devas ricevi la datumojn

Tial datumŝanĝaj sistemoj malkaŝas niajn neperfektaĵojn tute.

Datuma kvalito estas la atingo de ilaj specialistoj, spertuloj pri laborfluo, administrantoj, kaj la komunikado inter ĉiuj ĉi tiuj homoj.

La Plej Bonaj kaj Plej Malbonaj Komunikadaj Strukturoj por Multfakaj Teamoj

Tipa projektteamo en MarTech aŭ merkatika analiza kompanio konsistas el specialistoj pri komerca inteligenteco (BI), sciencistoj pri datumoj, projektistoj, komercistoj, analizistoj kaj programistoj (en iu ajn kombinaĵo).

Sed kio okazos en teamo, kiu ne komprenas la gravecon de komunikado? Ni vidu. La programistoj longe verkos kodon, penante, dum alia parto de la teamo nur atendos, ke ili transdonu la baton. Finfine la beta-versio estos publikigita, kaj ĉiuj murmuros pri tio, kial ĝi daŭris tiel longe. Kaj kiam aperos la unua difekto, ĉiuj ekoserĉos iun kulpan sed ne manierojn eviti la situacion, kiu alvenigis ilin tien. 

Se ni rigardas pli profunde, ni vidos, ke reciprokaj celoj ne estis ĝuste komprenitaj (aŭ entute). Kaj en tia situacio, ni ricevos difektitan aŭ difektitan produkton. 

Kuraĝigi Plurdisciplinajn Teamojn

La plej malbonaj trajtoj de ĉi tiu situacio:

  • Nesufiĉa partopreno
  • Nesufiĉa partopreno
  • Manko de kunlaboro
  • Manko de fido

Kiel ni povas ripari ĝin? Laŭvorte paroligante homojn. 

Kuraĝigi Plurfakajn Teamojn

Ni kolektu ĉiujn, starigu diskutajn temojn, kaj planu semajnajn kunvenojn: merkatado kun BI, programistoj kun projektistoj kaj specialistoj pri datumoj. Tiam ni esperos, ke homoj parolos pri la projekto. Sed tio ankoraŭ ne sufiĉas, ĉar teamanoj ankoraŭ ne parolas pri la tuta projekto kaj ne parolas kun la tuta teamo. Estas facile neĝi sub dekoj da kunvenoj kaj sen eliro kaj sen tempo por fari la laboron. Kaj tiuj mesaĝoj post kunvenoj mortigos la reston de la tempo kaj komprenon, kion fari poste. 

Tial renkontiĝo estas nur la unua paŝo. Ni ankoraŭ havas iujn problemojn:

  • Malbona komunikado
  • Manko de reciprokaj celoj
  • Nesufiĉa partopreno

Foje homoj provas transdoni gravajn informojn pri la projekto al siaj kolegoj. Sed anstataŭ la mesaĝo trapasas, la onidira maŝino faras ĉion por ili. Kiam homoj ne scias kiel dividi siajn pensojn kaj ideojn ĝuste kaj en la taŭga medio, informoj perdiĝos survoje al la ricevanto. 

Ĉi tiuj estas simptomoj de kompanio luktanta kun komunikaj problemoj. Kaj ĝi komencas kuraci ilin per kunvenoj. Sed ni ĉiam havas alian solvon.

Gvidu ĉiujn komuniki pri la projekto. 

Plurdisciplina komunikado en teamoj

La plej bonaj trajtoj de ĉi tiu aliro:

  • Travidebleco
  • Implikiĝo
  • Interŝanĝo de scioj kaj kapabloj
  • Senĉesa edukado

Ĉi tio estas ekstreme kompleksa strukturo malfacile kreebla. Vi eble konas kelkajn kadrojn, kiuj sekvas ĉi tiun aliron: Agile, Lean, Scrum. Ne gravas kiel vi nomas ĝin; ĉiuj estas konstruitaj laŭ la principo "kunigi ĉion samtempe". Ĉiuj tiuj kalendaroj, taskaj atendovicoj, demonstraĵaj prezentoj kaj staraj renkontiĝoj celas igi homojn paroli pri la projekto ofte kaj kune.

Tial mi multe ŝatas Agile, ĉar ĝi inkluzivas la gravecon de komunikado kiel antaŭkondiĉo por projekta postvivado.

Kaj se vi pensas, ke vi estas analizisto, kiu ne ŝatas Agile, rigardu ĝin alimaniere: Ĝi helpas vin montri la rezultojn de via laboro - ĉiuj viaj prilaboritaj datumoj, tiuj bonegaj instrumentpaneloj, viaj datumaroj - por krei homojn danku viajn penojn. Sed por fari tion, vi devas renkonti viajn kolegojn kaj paroli kun ili ĉe la ronda tablo.

Kio sekvas? Ĉiuj ekparolis pri la projekto. Nun ni havas pruvi la kvaliton de la projekto. Por fari tion, kompanioj kutime dungas konsultiston kun la plej altaj profesiaj kvalifikoj. 

La ĉefa kriterio de bona konsultisto (mi povas diri al vi, ĉar mi estas konsultisto) konstante malpliigas sian partoprenon en la projekto.

Konsultisto ne povas nur nutri kompanion malgrandajn pecojn da profesiaj sekretoj, ĉar tio ne igos la kompanion matura kaj memsubtena. Se via kompanio ne povas vivi sen via konsultisto, vi devas konsideri la kvaliton de la servo, kiun vi ricevis. 

Parenteze, konsultisto ne faru raportojn aŭ fariĝu plia manplato por vi. Vi havas viajn internajn kolegojn por tio.

Dungi Komercistojn por Edukado, Ne Delegacio

La ĉefa celo dungi konsultiston estas edukado, riparado de strukturoj kaj procezoj, kaj faciligado de komunikado. La rolo de konsultisto ne estas ĉiumonata raportado, sed prefere enigi sin aŭ sin en la projekton kaj esti komplete implikita en la ĉiutaga rutino de la teamo.

Bona strategia merkatada konsultisto plenigas mankojn en la scio kaj kompreno de projektaj partoprenantoj. Sed eble li aŭ ŝi neniam faros la laboron por iu. Kaj iam, ĉiuj bezonos labori bone sen la konsultisto. 

La rezultoj de efika komunikado estas foresto de sorĉistina ĉasado kaj fingromontrado. Antaŭ ol tasko komenciĝas, homoj dividas siajn dubojn kaj demandojn kun aliaj teamanoj. Tiel, plej multaj problemoj estas solvitaj antaŭ ol la laboro komenciĝas. 

Ni vidu, kiel ĉio tio influas la plej komplikan parton de la merkatika analiza laboro: difini datumajn fluojn kaj kunfandi datumojn.

Kiel la Komunikada Strukturo Speguliĝas en Datumtransigo kaj Prilaborado?

Ni supozu, ke ni havas tri fontojn, kiuj donas al ni la jenajn datumojn: trafikaj datumoj, retkomercaj produktaj datumoj / aĉetaj datumoj de la lojala programo kaj moveblaj analizaj datumoj. Ni trairos la etapojn de prilaborado de datumoj unu post la alia, de elsendado de ĉiuj tiuj datumoj al Google Cloud ĝis sendado de ĉio por videbligo Google Data Studio kun helpo de Google BigQuery

Surbaze de nia ekzemplo, kiajn demandojn homoj devas fari por certigi klaran komunikadon dum ĉiu etapo de datuma prilaborado?

  • Datuma kolekto-stadio. Se ni forgesas mezuri ion gravan, ni ne povas retroiri en la tempo kaj mezuri ĝin. Konsiderindaj aferoj antaŭe:
    • Se ni ne scias, kiel nomi la plej gravajn parametrojn kaj variablojn, kiel ni povas trakti la tutan malordon?
    • Kiel estos markitaj eventoj?
    • Kio estos la unika identigilo por elektitaj datumfluoj?
    • Kiel ni prizorgos sekurecon kaj privatecon? 
    • Kiel ni kolektos datumojn, kie estas limigoj pri datumkolektado?
  • Kunfandaj datumoj fluas en la rivereton. Konsideru la jenon:
    • La ĉefaj ETL-principoj: Ĉu ĝi estas aro aŭ rivereta speco de datumtransigo? 
    • Kiel ni markos la konjunkcion de riveraj kaj bataj datumaj translokigoj? 
    • Kiel ni ĝustigos ilin en la sama datuma skemo sen perdoj kaj eraroj?
    • Demandoj pri tempo kaj kronologio: Kiel ni kontrolos la tempostampojn? 
    • Kiel ni povas scii, ĉu renovigo kaj riĉigo de datumoj funkcias ĝuste ene de tempostampoj?
    • Kiel ni validigos sukcesojn? Kio okazas kun nevalidaj sukcesoj?

  • Datuma agrega etapo. Konsiderindaj aferoj:
    • Specialaj agordoj por ETL-procezoj: Kion ni devas fari kun malvalidaj datumoj?
      Ĉu fliki aŭ forigi? 
    • Ĉu ni povas akiri profiton de ĝi? 
    • Kiel ĝi influos la kvaliton de la tuta datuma aro?

La unua principo por ĉiuj ĉi tiuj stadioj estas, ke la eraroj stakiĝas unu sur la alia kaj heredas unu de la alia. Datumoj kolektitaj kun difekto en la unua etapo iomete bruligos vian kapon dum ĉiuj postaj etapoj. Kaj la dua principo estas, ke vi elektu punktojn por certigo de datumoj. Ĉar ĉe la agregacia stadio, ĉiuj datumoj miksiĝos, kaj vi ne povos influi la kvaliton de la miksitaj datumoj. Ĉi tio vere gravas por maŝinlernaj projektoj, kie la kvalito de datumoj influos la kvaliton de la maŝinlernaj rezultoj. Bonaj rezultoj estas neatingeblaj kun malaltkvalitaj datumoj.

  • videbligo
    Jen la ĉefoficista stadio. Eble vi aŭdis pri la situacio, kiam la ĉefoficisto rigardas la nombrojn sur la panelo kaj diras: "Bone, ni havas multan profiton ĉi-jare, eĉ pli ol antaŭe, sed kial ĉiuj financaj parametroj en la ruĝa zono estas ? ” Kaj en ĉi tiu momento, estas tro malfrue serĉi la erarojn, ĉar ili devus esti kaptitaj antaŭ longa tempo.

Ĉio baziĝas sur komunikado. Kaj pri la konversaciaj temoj. Jen ekzemplo pri tio, kion oni devas diskuti dum preparado de Yandex-streaming:

Merkatado BI: Neĝoplugilo, Google Analytics, Yandex

Vi respondos al la plej multaj el ĉi tiuj demandoj nur kune kun via tuta teamo. Ĉar kiam iu decidas surbaze de diveno aŭ persona opinio sen testi la ideon kun aliaj, eraroj povas aperi.

Kompleksecoj estas ĉie, eĉ en la plej simplaj lokoj.

Jen plia ekzemplo: Spurante la impresajn poentarojn de produktokartoj, analizisto rimarkas eraron. En la sukcesaj datumoj, ĉiuj impresoj de ĉiuj standardoj kaj produktokartoj estis senditaj tuj post paĝoŝarĝo. Sed ni ne povas esti certaj, ĉu la uzanto vere rigardis ĉion sur la paĝo. La analizisto venas al la teamo por informi ilin pri tio detale.

La BI diras, ke ni ne povas forlasi la situacion tiel.

Kiel ni povas kalkuli la CPM se ni eĉ ne povas esti certaj, ĉu la produkto montriĝis? Kio estas la kvalifikita CTR por la bildoj tiam?

La merkatistoj respondas:

Rigardu, ĉiuj, ni povas krei raporton montrantan la plej bonan CTR kaj kontroli ĝin kontraŭ simila kreiva standardo aŭ foto aliloke.

Kaj tiam la programistoj diros:

Jes, ni povas solvi ĉi tiun problemon helpe de nia nova integriĝo por rulumado kaj kontrolado de subjektaj videblecoj.

Fine, la projektistoj de UI / UX diras:

Jes! Ni povas elekti ĉu ni bezonas la maldiligentan aŭ eternan volvlibron aŭ paĝadon finfine!

Jen la paŝoj tra ĉi tiu malgranda teamo:

  1. Difinis la problemon
  2. Prezentis la komercajn konsekvencojn de la problemo
  3. Mezuris la efikon de ŝanĝoj
  4. Prezentitaj teknikaj decidoj
  5. Malkovris la sensignifan profiton

Por solvi ĉi tiun problemon, ili devas kontroli la datuman kolekton de ĉiuj sistemoj. Parta solvo en unu parto de la datuma skemo ne solvos la komercan problemon.

vicigi ĝustigi dezajnon

Tial ni devas labori kune. La datumoj devas esti kolektitaj respondece ĉiutage, kaj estas malfacile fari tion. Kaj la kvalito de datumoj devas esti atingita de dungi la taŭgajn homojn, aĉeti la taŭgajn ilojn kaj investi monon, tempon kaj penon por konstrui efikajn komunikajn strukturojn, kiuj estas nemalhaveblaj por sukceso de organizo.

Kion vi pensas?

Ĉi tiu retejo uzas Akismeton por redukti spamon. Lernu, kiel via komento datiĝas.