Kommunikation, kommunikation, kommunikation!

Kommunikation: Den svære kunst at få formidlet sit budskab til folk, med andre evner og erfaringer end én selv. Og måske endda få dem til at forstå, hvad man mener.

Vi ved alle, at det kan være en svær opgave. Selv mellem nære venner, kan man gå fejl af hinanden, og der kan opstå misforståelser.

Så hvad kan man gøre for at skabe den bedst mulige kommunikation i arbejdssammenhænge – mellem folk med teknisk baggrund, og folk uden?

Lad os forsøge at indsnævre det nærmere.

Den klassiske konflikt: Designer vs. Udvikler

Designer har lavet et virkeligt smukt og moderne webdesign i Photoshop eller Sketch. Der er taget højde for alt – der er prototyper til forskellige skærmstørrelser, farverne sidder lige i skabet, og alt burde være tilpasset den ønskede målgruppe.

Designer zipper filerne og sender dem til Udvikler, fuld af forventning om hvor vidunderligt siden kommer til at virke, når den bliver færdig.

2 uger senere modtager han et link i en mail fra Udvikler. Han åbner siden, og er ved at få et hjerteanfald. De smarte asymmetriske bokse er firkantede, og skrifttypen ser helt bizar ud! Alt er ødelagt!

For slet ikke at tale om, at tingene slet ikke står i rigtig rækkefølge på en mobilskærm!

Designer raser, og forbander Udvikler langt væk. Samtidig sidder Udvikler og skumler over den verdensfjerne Designer, som ikke har gidet at sætte sig ind i de tekniske rammer før projektet gik i gang…

Forventningsafstemning, løbende dialog og vilje til at lære nyt

Så kort kan man opsummere løsningen på ovenstående dilemma.

Designere og udviklere skal kunne indgå i et team, fremfor at placere sig selv i hver sin silo. Hver for sig udnytter ingen af dem deres evner til det fulde.

De er nødt til at lære af hinanden, og med hinanden, for at produktet – og dermed kundetilfredsheden – kan blive så godt som muligt.

Hvis nu de havde startet med et møde, hvor de hver især kom med deres vurdering af projektet, og derefter løbende indgik i dialog, så ville Udvikler have kunnet fortælle Designer, at skrifttypen f.eks. ikke fandtes i et format, der kunne bruges til web, og anbefale noget andet.

Samtidig kunne Designer måske være kommet med nogle forslag til hvordan man med baggrundsbilleder kunne “snyde” med formen på boksene, så de kom til at se ud, som de gjorde i hans prototype.

I sidste ende, hvis de to bare havde kunnet arbejde sammen, så ville der være sparet mange frustrationer, en del tid, og produktet kunne være blevet noget bedre og mere helstøbt, end det endte med at blive.

Næste skridt: Designer eller Udvikler vs. Lederen

Lad os gå videre til det næste klassiske scenarie.

Lad os sige at det er i starten af 2015, og Udvikler ved, at browserne snart vil markerer alle sider der ikke benytter https som usikre. Det er derfor blevet bydende nødvendigt at få alle kunder med webshops over på https – for hvis ikke, vil potentielle købere snart blive skræmt væk fra siderne i købs-processen, fordi de får besked på at “siden er usikker”.

Udvikler går hen til Leders kontor og banker på. “Undskyld, men jeg er nødt til at tale med dig om noget vigtigt. Hvis vi ikke får SSL-certifikater installeret på kundernes servere…”

Leder kaster teatralsk hænderne i vejret. “Jeg behøver ikke at vide hvad du laver! Du skal bare lave det!”

Man skyder sig selv i foden ved ikke at lytte

Hvis Leder havde taget sig tid til at høre efter, ville han have forstået at der
1) var tale om noget vitalt for kunderne, der ville kunne skade deres virksomheder, hvis det ikke blev udført – og som hurtigst muligt burde kommunikeres videre til dem, og
2) at der var tale om en potentielt større opgave for virksomheden, der ville tage noget tid og burde koordineres, fremfor at hvile på en enkelt persons skuldre, og
3) at det faktisk også var en oplagt mulighed for mersalg.

Desværre går to ting galt i dette scenarie.

For det første lider Leder af den klassiske tech-blokering, der tit rammer mennesker der ikke selv har en teknisk baggrund. De tror, de ikke forstår teknologien bag – så derfor nægter de at høre efter. Det er en selvopfyldende profeti – for uden viljen til at lytte efter, kommer de aldrig til at opnå forståelsen.

For det andet begår Udvikler den klassiske fejl ikke at tage sit publikum i betragtning. Han taler ud fra sine egne evner og erfaringer, og får ikke lige overvejet, at de fleste af ordene er volapyk for det menneske, han skal kommunikere dem til.
I stedet for at kaste sig ud i den tekniske forklaring kunne han måske med fordel have sagt: “Vores kunder kommer snart til at opleve problemer, hvis vi ikke øger sikkerheden på deres sider. Browserne begynder nemlig snart at vise advarsler på siderne, hvis de ikke benytter en krypteret forbindelse. Ville det være en idé at tage kontakt til kunderne allerede nu, og gøre dem opmærksomme på det, så vi kan få lagt en plan for forløbet?”

Efter denne tale kan Leder (med fordel) spørge ind til hvad der præcis er tale om, og man kan aftale en strategi for hvad kunderne skal informeres om, hvad de evt. skal betale, og hvornår det kan sættes i værk uden at komme i karambolage med de igangværende projekter i virksomheden.

På den måde vinder alle.

Alt det ville kræve var, at Leder var villig til at lytte, og at Udvikler var en bedre sælger, der kunne tale ud fra sit publikums forudsætninger, fremfor ud fra sine egne. Det lyder ikke af meget – men det er det desværre ofte i praksis.

Så, kort og godt…

Man kan let begå den fejl, at tage kommunikation for givet, fordi det er så fundamental en proces, at man glemmer den i forbifarten. Men for at få den til at fungere ordentligt, kræver det en bevidst indsats. Så meget mere, når man taler med nogen, der har et komplet anderledes sæt evner og erfaringer end en selv.

I sidste ende drejer det hele sig om, at respektere hinandens forskelligheder. Du behøver ikke at vide alt. Men du skal være villig til at lytte.

Leder og Designer behøver ikke forstå det tekniske volapyk, der kommer ud af Udviklers mund engang imellem. Men i stedet for at affeje det, kunne de jo overveje at bede om en omformulering – for det kunne jo være noget vigtigt.

Og Udvikler kunne med fordel tage alle de tekniske ord ud af forklaringen, og “oversætte” dem, til noget han ved, de andre vil kunne følge.

Udvikler behøver heller ikke i udgangspunktet forstå hvorfor Designer vælger at levere et design, der ligner en akkrobatisk øvelse. Men han kunne spørge ind til hvad meningen er, og måske kunne svaret give ham en større forståelse for, hvorfor han skal bruge tid på at “flytte pixels” fremfor at tage sig af “væsentligere opgaver”. Meningen var jo nok, at gøre siden så brugervenlig som mulig, når alt kommer til alt.

God intern kommunikation skaber det bedste resultat for virksomheden – fordi det skaber de bedste resultater for kunderne. Derfor er det værd at tilsidesætte sit ego, og gøre en ekstra indsats for.

Er du interesseret i et samarbejde?