Giv dine kolleger bedre feedback (med Ryan Schaefer fra Viget)

Læs transskriptionen:

Vi er i gang med at afprøve transskription af vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til DPM-podcasten, hvor vi går videre end teorien for at give råd, der virker, når man skal lede bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager.

Så hvordan håndterer du at give feedback til personerne på dit team? Omfavner du det, fordi du jo ved, at du har ret – du er projektleder – eller undgår du det, fordi du er bekymret for, at du ikke bliver taget alvorligt? Måske får du feedback og tænker, at ingen rigtig forstår eller måske overhovedet har hørt, hvad du sagde. Men som projektledere er vi ansvarlige for at levere succes, og det er svært, når vores teams så ofte ser ud til at være på afveje.

Find derfor ud af i dagens podcast, hvordan du på enkle måder kan give feedback, der hjælper dine teams med at levere bedre arbejde og holde dine projekter på sporet.

I dag har jeg selskab af Ryan Schaefer. Ryan er gået fra at designe og bygge websites til nu at lede deres udvikling, og han arbejder i Washington D.C. hos et bureau, der hedder Viget. Hej Ryan.

Ryan Schaefer:

Hej Ben. Tak fordi du inviterede mig.

Ben Aston:

Fedt. Ryan, fortæl os lidt om din rolle lige nu. Det, jeg især er interesseret i, er, hvordan du foretog overgangen fra design og udvikling til projektledelse. Det er et spørgsmål, vi ofte får. Hvad laver du lige nu? Er det ren projektledelse, eller kommer du også lidt ned i detaljerne?

Ryan Schaefer:

Jeg vil sige, at det hælder mest til ren projektledelse, men jeg tror bestemt, at noget af det, der gjorde det lettere for mig at gå fra at være nede i detaljerne og udføre design og udvikling til at blive projektleder, var, at jeg havde en forståelse af alle de overvejelser og processer, der lå bag design- og udviklingsarbejdet.

Det gør det muligt for mig at tale med de meget dygtige designere og udviklere, vi har her, på nogenlunde lige vilkår. Jeg behøver ikke spørge, hvad forkortelserne betyder, eller hvilke værktøjer der er tale om, og den slags.

Jeg tror også, at min baggrund hos et tidligere PR-bureau, hvor jeg havde en dobbeltrolle inden for både kunderelationer og udførelse, hjalp mig med at tænke over, hvordan jeg skulle formidle ting til en kunde, og hvordan vi skulle samarbejde med andre teammedlemmer. Så det var heldigvis en ret naturlig overgang til projektledelse på fuld tid.

Ben Aston:

Men hvordan skete det? Hvad var det udløsende øjeblik, hvor du sagde: “Okay, det er det. Jeg bliver projektleder”?

Ryan Schaefer:

Det havde lidt at gøre med, at jeg gerne ville lede ting fra et helikopterperspektiv i stedet for at arbejde mere isoleret. Men den primære grund var, at jeg gerne ville være en del af et bureau, hvor alle brændte for digitale løsninger, og hvor man tænkte fremadrettet. Det ændrer naturligvis den måde, vi lever på som civilisation og bestemt også som land. At være omgivet af mennesker, der så det og værdsatte det, og som samtidig var meget dygtige inden for deres respektive digitale fagområder, var noget, jeg gerne ville være en del af. I sidste ende ville det hjælpe mig med at udvikle mig professionelt.

Ben Aston:

Fedt. Fortæl os lidt om, hvad du laver lige nu. Hvordan ser projektlederrollen ud hos Viget?

Ryan Schaefer:

Ja, først og fremmest hedder det Viget. Det får vi ofte at vide.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, ja.

Ben Aston:

Jeg gik faktisk ind på websitet og klikkede på en kat, hvor der stod, at det udtales Viget.

Ryan Schaefer:

Ja, der er sådan en “sig hej”-knap. Det er Viget.

Ben Aston:

Det får man, når man har et sjovt navn. Hvad betyder det egentlig?

Ryan Schaefer:

“Vi blomstrer sammen” på latin.

Ben Aston:

Nå, selvfølgelig.

Ryan Schaefer:

Noget i den stil.

Ben Aston:

Min mor ville skamme sig over mig. Mor, det må du undskylde. Hun er latinlærer. Jeg burde vide sådan noget.

Ryan Schaefer:

Latin var mit mindst yndlingsfag i gymnasiet. Vi var nødt til at have det. Jeg kan ikke tro, at vi skulle have det, men sådan var det.

Ben Aston:

Det har jo forberedt dig rigtig godt på alle de sprog, du taler nu, ikke?

Ryan Schaefer:

Jo, lige præcis. Men min rolle som projektleder hos Viget omfatter mange forskellige ting. Der er selvfølgelig de centrale projektlederansvarsområder, såsom tidsplan, budget, planlægning, bemanding og ressourceallokering. Derudover har vi også opgaver, der er mere specifikke for produktledelse. Vi har ikke specifikke produktledere her, så projektlederne er ansvarlige for mange brugerrejser, funktionsdefinition, kvalitetssikringstest samt for virkelig at forstå de virksomheder, man arbejder med, og de produkter, man bygger, fra ende til anden.

Ben Aston:

Fedt. Så det er både projekt- og produktledelse?

Ryan Schaefer:

Ja, det er-

Ben Aston:

En blanding af begge dele.

Ryan Schaefer:

Ja. De hænger på en måde sammen, og det er en fordel at arbejde med dem samtidig. Men jeg synes også, at de er tilstrækkeligt forskellige til, at det er rart at skifte gear og arbejde på projektet i stedet for at lede projektet.

Ben Aston:

Ja, fedt. Kan du fortælle os lidt om nogle af de projekter, du arbejder på lige nu?

Ryan Schaefer:

Ja. Jeg skiftede faktisk for et par uger siden til fuld tid på ét enkelt projekt. Det er første gang, det er sket for mig. Det handler om et stort marketingwebsite og derefter en form for portal til forskellige målgrupper, som kan logge ind, hvorefter forskellige data hentes for hver målgruppe.

Vi gentænker grundlæggende hele økosystemet, opdaterer designet for alle deres udadvendte digitale materialer og arbejder derefter på en køreplan for fremtidige produkter, måske en app eller noget i den stil. Det er meget omfattende, og jeg glæder mig til at fordybe mig i ét projekt, lære det rigtig godt at kende og forstå det bedre.

Ben Aston:

Når vi taler om udvikling af en native app, ved jeg, at du skal holde et Lightning Talk på DPM Summit, hvor du vil give råd om styring af udviklingen af en native app. Kan du give os kortversionen af dit oplæg? Hvad opdager du om udvikling af native apps?

Ryan Schaefer:

Mit oplæg tager udgangspunkt i det, jeg lærte under det største projekt, jeg har arbejdet på her. Det var et design- og udviklingsprojekt for en Android-app.

Jeg vil tale om det, jeg har lært, og især om forskellene mellem at lede udviklingen af en native app og en mere almindelig webapp samt bedste praksis for dette. Jeg vil også tale om de specifikke tekniske krav, man som projektleder skal være opmærksom på.

Der er et par eksempler. Omkostningen ved fejl er meget høj for en app, fordi appen går ned. Hvis et website har en fejl, er det normalt bare at trykke Kommando-R eller genindlæse siden. De sprog, man bruger til at skrive native apps i, fungerer heller ikke som JavaScript, der bruges til webapps. Man skal selv finde frem til 90 % af løsningen på et problem i stedet for 30-40 % i webapps, hvor JavaScript udfylder forskellen.

Der er også systemkontroller og andre begrænsninger, f.eks. offlinebegrænsninger, som man skal være opmærksom på. Hvordan fungerer en app, når den er offline? Hvordan interagerer menuknapperne på telefonen med appen, og hvor fører de brugeren hen? Den slags.

Ben Aston:

Du har arbejdet med webapps og naturligvis native apps. Jeg har tidligere sagt, at alle laver webapps, fordi de er lettere og hurtigere at bygge. Hvad er din holdning til webapps kontra native apps, og hvilken retning bevæger det sig i?

Ryan Schaefer:

En interessant udvikling, som vi ser og navigerer i som virksomhed, er fremkomsten af tjenester som Squarespace, Beams i WordPress, Weebly og den slags. Det er meget funktionelle tjenester, der gør det muligt for mennesker med begrænset teknisk viden at oprette et rigtig flot website.

På grund af den lave pris og tilgængeligheden af den slags løsninger er det sværere at finde traditionelle marketingwebsites. Native apps er endnu ikke blevet åbnet på samme måde, og derfor ser vi et stort potentiale på det område. Og så er det jo også lidt sejt at kunne sige, at man har en app, ikke?

Ben Aston:

Jo.

Ryan Schaefer:

Men jeg tror også, at der stadig findes meget software og mange produkter, som endnu ikke er blevet opdaget. Det, jeg arbejder på nu, er for eksempel en portal til brugere eller et område bag et login, hvor man kan se noget andet end det, man kan bygge i Squarespace eller lignende.

Der er mange muligheder for tilpasning, hvilket er spændende for designere og udviklere. Samtidig er der mange ting, vi kan være med til at forme på dette område, så det bliver et mere spændende felt, når man skaber produkter til virksomheder.

Ben Aston:

Fedt. Du arbejder altså med appudvikling og store marketingwebsites. Hvad har du i din projektlederværktøjskasse? Hvordan styrer du de produkter og projekter, du arbejder på? Hvad sørger du altid for at få sat op i begyndelsen af et projekt?

Ryan Schaefer:

Det er naturligvis vigtigt at komme godt fra start, så jeg kan godt lide at facilitere en diskussion med fokus på kundens projektopstart. Et visionsmøde er en rigtig god idé, hvor man taler om, hvad organisationen laver nu, hvad deres produkt gør og ikke gør, og hvor de gerne vil være. Jeg kan også godt lide at afholde workshops om problemer, mål og målsætninger samt interviews med interessenter og den slags.

Det er mange ting, man ikke kan afdække i salgsprocessen, uanset hvor detaljeret man forsøger at være. Når man først virkelig forstår alle disse ting – hvilket er en vigtig fase at afsætte tid til, fordi den kan tage et par uger eller endnu længere – går man ind i projektet med al denne viden. Det gør det muligt at komme hurtigere i gang, bygge mere effektivt og i sidste ende levere et bedre slutprodukt.

Værktøjerne til at holde styr på det hele kan være mange. Airtable er rigtig godt, og det samme gælder naturligvis GitHub Projects. Zen Hub er et andet værktøj, man kan bruge sammen med GitHub, og så er der Trello. Vi har brugt alle disse værktøjer afhængigt af kundernes præferencer og vores egne anbefalinger.

Ben Aston:

Er der nogle bestemte projektlederværktøjer, du for nylig har fundet, som gør dit liv fantastisk? Gode tricks eller genveje – noget, du lige har opdaget?

Ryan Schaefer:

Ja, to ting. For det første har jeg brugt noget tid på at se på genvejene på min computer, fordi der er så mange flere, og det har virkelig sparet mig tid. Det er måske kun sekunder, men sekunder hundredvis af gange om dagen.

Den anden ting er-

Ben Aston:

Hvad er din yndlingsgenvej, som du har opdaget for nylig?

Ryan Schaefer:

Kommando-Skift-T, som åbner den senest lukkede fane.

Ben Aston:

God en.

Ryan Schaefer:

Ja, den er god.

Ben Aston:

Min yndlingsgenvej for nylig – jeg plejede at have en app til det – men jeg bruger Windows. Windows-V i Windows 10 viser nu din historik for kopiering og indsættelse.

Ryan Schaefer:

Wow.

Ben Aston:

For altid, tror jeg. Jeg ved det ikke, jeg har ikke tjekket igen. Jeg er den type, der gerne vil spille det højrisikospil, hvor man skriver noget i Notesblok, kopierer det, begynder på noget andet og derefter glemmer at indsætte det. Derfor synes jeg, at min historik for kopiering og indsættelse, som også indeholder billeder, er virkelig nyttig. Så Windows-V og Kommando-Skift-T – var det det, du sagde? Sådan. Her er ugens genveje.

Ryan Schaefer:

Det er virkelig en god en.

Ben Aston:

Er der andet?

Ryan Schaefer:

Det nye værktøj, jeg bruger, og som virkelig har åbnet tingene for mig, er Notion. Har du hørt om det?

Ben Aston:

Ja.

Ryan Schaefer:

Det er lidt som en arbejdsplatform. Man kan bruge det til noter og samarbejde, det fungerer offline, og brugerfladen er meget ren. Man kan indlejre indhold, oprette udfoldninger og placere sider indlejret i undersider i undersider i undersider i det uendelige. Der findes også web- og mobilapps, så man kan bruge det overalt, og det kan tilpasses meget.

Det gør, at jeg hurtigt kan åbne det, hvis jeg er i et møde, skrive noget, jeg har brug for, og bagefter eller undervejs nemt få det til at se pænt ud.

Ben Aston:

Ryan, med alle de projekter, du arbejder på, og selv med de værktøjer, vi netop har talt om, hvad synes du så er svært? Hvilke udfordringer møder du i hverdagen i din rolle? Hvad er det vanskeligste ved det, du laver lige nu?

Ryan Schaefer:

Mange ting. En af dem er ikke at have tid nok. Men jeg tror, at det vanskeligste – eller i hvert fald en af de svære ting – er at skifte kontekst.

Som projektleder har man normalt kapacitet til flere projekter, og kalenderen er ofte fyldt med møder. Derfor springer man hele tiden fra det ene møde til det næste og skal nærmest cache alt om projektet på vej til det næste mødelokale. Det synes jeg er meget vanskeligt. Den måde, jeg håndterer det på, er ved at tage meget grundige noter, som jeg kan slå op i med det samme. Jeg laver også gerne en dagsorden til hvert møde. Derudover bruger jeg lidt tid i begyndelsen af dagen på bare at sidde med en kop kaffe og tænke over status for hvert projekt, jeg arbejder på, hvor det står ved dagens begyndelse, og hvor det bør være ved dagens slutning. Det er noget, jeg hele tiden forsøger at blive bedre til.

Den anden ting er at finde en god måde at fremme samarbejde og projektopstart på, især i overgangen fra designere til udviklere. Man får ofte denne meget flotte mockup, som designeren har lavet sammen med en UX-designer, og alt ser fantastisk ud. Derefter vil man gerne have en periode, hvor en udvikler gennemgår den og godkender den, før man viser den til kunden. Det er ofte ikke indlysende, hvordan man dokumenterer og definerer alle de forskellige frontendfunktioner, og hvordan alting styres i administrationsdelen, ud fra en statisk komposition.

Derfor undersøger vi nogle metoder med Airtable og lignende til at strukturere indhold på en måde, der krydsrefererer hvert element i kompositionerne. Det hjælper udvikleren med at sige: “Okay, sådan kommer dette til at fungere, og sådan kommer det andet til at fungere. Derfor tager det en uge eller noget i den stil, så vi kan nå det inden for tid og budget.”

Det kan være en ret besværlig proces, og det er noget, der stadig er under udvikling, men forhåbentlig vil det give gode resultater.

Ben Aston:

Fortæl mig lidt mere om det, for Airtable var grundlæggende et regneark kombineret med en database.

Ryan Schaefer:

Ja.

Ben Aston:

Er der en integration med InVision, Sketch eller det værktøj, I bruger til jeres mockup, og Airtable? Er det sådan, det fungerer?

Ryan Schaefer:

Det har integrationer, men vi bruger primært Figma. Jeg tror ikke, det har integrationer til det.

Vi har prøvet et par forskellige ting, blandt andet et Google-regneark med links. Jeg ved ikke, om vi helt er nået dertil, hvor vi kan integrere det på en måde, der giver mening med et værktøj, vi ville bruge – eller om vi ligefrem ville vælge et værktøj, fordi det integrerer med Airtable. Den største fordel er efter min mening, at det er en relationsdatabase. Derfor er det meget nemt at krydslinke ting i databasen, og den kan skaleres. Den er også let at læse, og brugerfladen er ren.

Ben Aston:

Hvis man aldrig har brugt Airtable, og man grundlæggende har et andet ark for hver ting, hvordan strukturerer man så Airtable? Kan du give os lidt indsigt i det?

Ryan Schaefer:

Jeg kan godt give et lille eksempel. Hvis vi starter med undersøgelser af brugerfladen, dokumenterer vi, hvor hvert navigationselement fører hen, ved hjælp af et sitemap eller noget lignende. Derefter kan man oprette endnu en – de hedder ikke faner, jeg kan ikke lige huske det rigtige ord – men de ligner grundlæggende faner. Så kan man afstemme det, man har i øjeblikket, ved at linke til det på den anden fane og derefter tilføje nye områder. Man kan skelne mellem de nye områder på flere måder, for eksempel ved at tilføje tags og kategorier eller bruge forskellige blokke, som hver har bestemte overskrifter, farver eller lignende.

Det giver alle et rent og letforståeligt overblik, som de kan se på gennem hele projektet, og som kan fungere som den fælles sandhedskilde for alt.

Ben Aston:

Det er smart. Jeg tror, at det ofte er en stor udfordring: Hvordan går man fra UX-design til udvikling og bevarer kravene?

Ryan Schaefer:

Netop.

Ben Aston:

Hvordan kodificerer man det? Jeg synes, at Airtable er en rigtig interessant løsning. Jeg har ikke hørt om den tilgang før, men jeg kan godt lide, at man kan referere til ting som: “Det er den samme menu, som du bruger derovre.” Hvis man gør det i Word eller Google Sheets, gentager, kopierer og indsætter man bare, og så ændrer man det ét sted og glemmer at ændre det et andet sted. Men når man gør det som en database, kan man bare referere til menupunktet eller hvad som helst fra databasen. Det er en rigtig god idé.

Fedt. Lad os tale om dit indlæg. For dem, der endnu ikke har læst det, handler det om at give feedback på en måde, der gavner projektet og fører til et bedre produkt eller projekt i sidste ende.

Kan du give os dit syn på at give feedback – som et værktøj? Det er noget, vi som projektledere ofte kan være bange for at gøre. Jeg er nysgerrig efter at høre, hvorfor du tror, vi holder os tilbage, og hvad det måske er, vi er bange for.

Ryan Schaefer:

Der er et par grunde til, at vi holder os tilbage.

Den første er menneskelig: Vi vil ikke fornærme vores kolleger eller træde på det arbejde, de har lavet. Den anden er, at vi måske ikke føler os tilstrækkeligt sikre på vores egen mening, når vi giver feedback til fageksperterne, designerne og udviklerne.

Det er bestemt rimelige bekymringer, men i sidste ende er du som projektleder tættest på kunden, og du ser tingene med friskere øjne end en person, der har arbejdet i detaljerne hele vejen igennem. Du kan bedst simulere slutbrugerens perspektiv. Derfor bidrager du med et andet perspektiv på arbejdet end den person, der faktisk skaber det.

Du bør derfor føle dig tryg ved at bruge den ekspertise og det perspektiv til at give feedback. Du kan sige: “Jeg ser det her for første gang som projektleder. Brugeren ser det også for første gang. Formidler det tydeligt, hvad organisationen laver? Tiltaler det målgrupperne? Er det tydeligt, at det er en rullemenu?” Den reaktion, du har, hjælper folk med at træde et skridt tilbage og sammenholde tingene med den forventede brugeradfærd eller forretningsmålene og vurdere, om vi opfylder dem.

Ben Aston:

Jeg kan godt lide det perspektiv, hvor vi kan være vogtere af succes og brugeroplevelsen, fordi vi kommer med et frisk sæt øjne.

I indlægget giver du ti råd om at give god feedback. Det første handler om at placere sig selv i en informeret position ud fra et forretningsmæssigt succes­perspektiv. Du taler om at lave en dybdegående gennemgang af kundeprojektet. Du nævnte, at du starter et nyt projekt og laver denne gennemgang. Hvordan ved du, om du er tilstrækkeligt informeret? Hvad er din proces for at få den dybdegående forståelse, så du virkelig forstår tingene og ikke bare tror, du ved noget, du faktisk ikke ved?

Ryan Schaefer:

Et godt spørgsmål. Jeg tror aldrig rigtig, man ved, om man er fuldt informeret, og det er okay.

Ben Aston:

Ja.

Ryan Schaefer:

Jeg nævnte visionsmøder, som jeg synes er et godt udgangspunkt, fordi man kan lære, hvordan virksomheden ser sig selv, og hvor den gerne vil hen. Det kan være: “Det her er noget, vores administrerende direktør beslutter. Skal vi opkøbe denne virksomhed? Skal vi fusionere? Skal vi børsnoteres?” Hvad end det måtte være.

Hvis man derefter taler med ledende interessenter, får man en idé om, hvordan de planlægger at gennemføre det. Det giver igen et indblik fra et højere perspektiv. Når man så starter en diskussionsbaseret projektopstart med de mennesker, der skal være direkte involveret i projektet, får man en fornemmelse af, hvordan projektet hænger sammen med det, de øverste ledere vil gøre, og hvordan det hænger sammen med virksomhedens overordnede mål. Alt dette bør kommunikeres og i sidste ende afspejles i det, man forsøger at opnå.

Man bør få tilstrækkelig og specifik information fra alle disse samtaler til at forstå, hvad de vil. Når man forstår, hvad de vil, er man det mellemled, der hjælper dem med at nå dertil – uanset om det handler om at forbedre deres kommunikation, formidle deres brand ved at gentænke deres visuelle udtryk, forbedre deres budskaber eller anbefale, at vi udvider produktet og bygger en app med bestemte funktioner.

Det er en løbende proces, som kræver en stor investering i begyndelsen. Vi har fokuseret meget på disse opdagelsesfaser, der skal besvare de spørgsmål, du lige stillede. Som sagt er det meget nyttigt, det effektiviserer processen betydeligt og fører i sidste ende til et bedre slutprodukt.

Ben Aston:

En del af det handler altså om at være informeret ved at forstå kunderne, forstå hvordan succes ser ud for dem fra et forretningsmæssigt perspektiv og forstå brugerne, deres behov og hvad der vil fungere for dem, så det skaber forretningsmæssig succes. Men du nævnte også, at man skal være informeret om bedste praksis, og du beskrev det som at læne sig ind i nogle forskellige fagområder.

Du kommer naturligvis fra udvikling og design og har erfaring på de områder. Hvordan ser det ud for dig at læne dig ind i forskellige fagområder? Hvordan sætter du dig ind i kvalitetssikring eller UX – ting, du ikke er helt fortrolig med – så et grundlæggende kendskab hjælper dig med at give god feedback?

Ryan Schaefer:

Når man bliver mere fortrolig med disse ting, så man føler, at man kan give mere detaljeret feedback til sine teammedlemmer, bør det forhåbentlig ske på en diplomatisk og objektiv måde, ikke på en subjektiv måde.

For at blive fortrolig med områderne skal man tale med så mange personer på teamet som muligt og være åben om hullerne i sin viden. Hvis jeg kom fra et udviklingsperspektiv og ikke var så fortrolig med brugeroplevelsen, skulle jeg ikke være bange for at følge en UX-person eller kigge med over skulderen, mens vedkommende gennemførte en større analyse.

Man skal også bare gøre tingene. Der findes et væld af ressourcer, hvis man vil begynde at kode eller designe. Man kan hente masser af inspiration fra projekter, som teamet har lavet, begynde at lægge mærke til tendenser og læse nogle artikler. Jeg forsøger at bruge fem timer om ugen på at kæmpe mig gennem design af et eller andet, holde mine kodefærdigheder ved lige og læse artikler. Jo flere møder man deltager i, og jo længere man arbejder digitalt, desto mere optager man den slags helt naturligt.

Ben Aston:

Hvilke kilder bruger du for at holde dig ajour med det, der sker?

Ryan Schaefer:

Thedigitalprojectmanager.com. Det er en god en.

Girl’s Guide to Project Management er også god. Adweek er god til at se, hvor det kreative område bevæger sig hen. Inden for udvikling er W3Schools ikke et nyhedswebsite, men det har ressourcer til at prøve næsten enhver effekt, man ønsker, uanset om det er CSS, JavaScript eller mere backend-relaterede ting. Det er gode steder at begynde.

Ben Aston:

Du talte om at udvikle dine egne færdigheder, og det tror jeg meget på – egne eksperimenter og sideprojekter for at blive fortrolig med området. Man kan føre en langt mere informeret samtale med en udvikler, hvis man bare har en grundlæggende forståelse af, hvordan tingene hænger sammen og fungerer.

Så ja, begynd at skabe noget. Lav dit eget portfoliosite eller hvad det nu måtte være. Det er én ting at læse om det, og noget andet faktisk selv at gøre det og se, hvad der sker. Hvis man beder designeren om bare at gøre noget, hjælper det at prøve at gøre det selv, fordi man så forstår, hvor meget eller hvor lidt arbejde det kræver. Det kan virkelig hjælpe, når man giver folk feedback.

Men har du nogle historier om, hvordan det eventuelt er gået galt for dig? Når vi giver feedback, kan vi tro, at vi er informerede, men det er deres arbejde, og de er professionelle. Jeg ved ikke, om du nogensinde har oplevet, at nogen sagde: “Hold op, Ryan. Du er ikke designeren. Det er jeg. Det er det, jeg bliver betalt for at gøre. Jeg værdsætter ikke din feedback.”

Hvordan håndterer du, at folk ikke tager din mening alvorligt, fordi du bare er projektlederen?

Ryan Schaefer:

Det er heldigvis ikke sket for mig endnu. En del af forklaringen er de fantastiske mennesker, jeg arbejder sammen med. Men en anden del er, at hvis man virkelig tager udgangspunkt i kundens perspektiv, er det et synspunkt, som teamet er nødt til og vil respektere. Især når man ser på, hvordan de beslutninger, de har truffet, den logik, de har skabt, og de systemer, de har etableret, hænger direkte sammen med de mål, vi definerede og blev enige om i begyndelsen af fasen.

Det handler altså mindre om: “Jeg kan ikke lide den farve,” og mere om: “Vi ved, at deres brandretningslinjer bruger denne farve som en tertiær farve. Den fylder meget. Kan det virke frastødende på dem?” Designeren har sandsynligvis allerede overvejet det og vil have en begrundelse. Hvis det giver mening for dig, vil det også give mening for kunden. Hvis designeren ikke har tænkt over det, er det godt, at vedkommende ved det. Så kan personen enten gennemgå processen frem mod beslutningen eller foretage de nødvendige justeringer.

Ben Aston:

Jeg synes, det er meget nyttigt, at du nævner, at det ikke kun er op til dig. Vi kan bidrage med kundens perspektiv, men du nævnte også, at man skal involvere de rigtige personer i nogle af de vanskelige samtaler. Hvis designeren bruger den forkerte farve, så husk, at det ikke kun er dit ansvar. Du kan tage den kreative direktør med og spørge: “Synes du, det er okay at bruge denne anden farve?” På den måde får man også andres perspektiver og bærer ikke alene byrden af at være vogter for alt, der er rigtigt og sandt.

Du nævnte også i dit indlæg, at man skal planlægge efter forskellige reaktioner fra teamet. Forskellige mennesker reagerer forskelligt på feedback. Du taler om at give lidt hård kærlighed og også om motiverende samtaler, men uden at gøre budskabet uklart.

Det er en stor udfordring, fordi vi gerne vil være søde ved folk og ikke såre deres følelser. Hvordan finder man balancen mellem hård kærlighed og et klart budskab, samtidig med at man er konstruktiv? Du taler også om at give konstruktiv ros. Hvordan giver man konstruktiv ros uden at gøre feedbackens budskab uklart? Det lyder ret kompliceret.

Ryan Schaefer:

Det er ikke en videnskab, og jeg ville ønske, jeg havde en god opskrift med trin et, to og tre. Jeg tror, meget af det handler om, at man som projektleder sandsynligvis har en vis følelsesmæssig intelligens, som gør det muligt at aflæse og reagere på, hvordan folk tager imod ens feedback i øjeblikket.

Det vigtigste, der hjælper med at begrænse enhver negativ reaktion og afgøre, om nogen har brug for motivation, er modløse eller har brug for hård kærlighed, er at være specifik. Som projektleder skal man ikke argumentere for subjektive ting, fordi det sandsynligvis ikke er ens rolle. Man skal argumentere for objektive beslutninger, som hænger sammen med projektets mål.

Man bør også altid forsøge diskret at vise, at man har tillid til personens evne til at udføre det, vedkommende arbejder på. Det virker opmuntrende, uanset om personen tager konstruktiv kritik personligt eller er ligeglad med den og blot bruger den som noget, der kan udvikles på.

Jeg kan godt lide at høre gode ting om mig selv i næsten enhver sammenhæng, så længe det ikke er nedladende. Hvis man er specifik i sin feedback, bliver det i sidste ende ikke nedladende.

Ben Aston:

Hvis folk har lyttet til denne podcast og tænker: “Mit UX- eller designteam vil aldrig lytte til mig, fordi de bare ser mig som en administrativ person,” hvad ville så være det første skridt eller det vigtigste at huske for dem, der føler, at deres stemme ikke tæller?

Ryan Schaefer:

Første gang du ser noget, der virker forkert – uanset om det er en prototype, et design eller noget andet – behøver du ikke give din mening til kende med det samme, især ikke hvis det er første gang. Brug lidt tid på at gå tilbage til dit skrivebord, se på det og tage nogle noter. Find frem til, hvor du mener, at designet eller artefaktet ikke rammer rigtigt, og kom vigtigst af alt med forslag til forbedringer.

Det giver dig tid til at gennemgå de øvelser, som de selv gennemgår, og det hjælper dig med at møde forberedt op med det, jeg ikke vil kalde research, men som bestemt gør det lettere at argumentere for nogle af dine forslag. Jo mere tid du bruger, og jo mere grundig og omfattende du er, desto mere vil dit teammedlem respektere det, og desto mere åben vil personen være over for at indarbejde det i den næste iteration.

Ben Aston:

Det er virkelig et godt råd. Folk kan nogle gange gå i forsvarsposition, når vi bare siger: “Jeg kan virkelig ikke lide det. Jeg synes ikke, det er særlig pænt,” eller: “Jeg synes ikke, det fungerer særlig godt.”

Det er bedre at tage sig tid – især hvis man er usikker på sin egen mening – til virkelig at vurdere, hvorfor man synes, noget ikke er rigtigt, og have en begrundelse. I stedet for at sige “jeg kan ikke lide det” kan man sige: “Jeg synes ikke helt, det fungerer, fordi x, y og z. Kunden har fortalt os, at det skal kunne dette, og jeg er ikke sikker på, hvordan det kommer til at ske. Kan du hjælpe mig med at forstå, hvordan du mener, det skal fungere?”

Man kan stille spørgsmål, gå i dybden med arbejdet og derefter sige: “Her er, hvad jeg tænkte kunne være en måde at opfylde det behov, vi forsøger at løse.”

Det er vigtigt at have en begrundelse, spørge ind til deres rationale og derefter foreslå nogle løsninger. Man kan også tegne ting på en tavle, hvis det er muligt. Jeg skitserer altid ting i en bog eller på en tavle, så det føles, som om man ikke overtager designet, men bare kommer med nogle idéer. Det kan hjælpe dem med at få mere ud af det, du siger.

Ryan, tusind tak fordi du ville være med. Det har været en fornøjelse at have dig med.

Ryan Schaefer:

Tusind tak. Det var en fornøjelse.

Ben Aston:

Jeg er nysgerrig efter at høre, hvad du synes. Har du nogensinde prøvet at give feedback, og hvordan blev den modtaget? Blev teamet vredt, eller var de glade for, at du påpegede noget, de ikke selv havde tænkt over?

Fortæl os, hvad du synes. Skriv en kommentar til indlægget, og gå til thedigitalprojectmanager.com for at blive medlem af vores Slack-team. Der foregår alle mulige interessante samtaler om alt, hvad der handler om projektlevering.

Hvis du kunne lide det, du hørte i dag, så abonnér, og brug et par minutter på at skrive en ærlig anmeldelse af DPM-podcasten på Apple Podcasts. Vi sætter stor pris på dine bedømmelser og anmeldelser. Mange tak, fordi du gør det.

Indtil næste gang: Tak fordi du lyttede med.