Gi kollegene dine bedre tilbakemeldinger (med Ryan Schaefer fra Viget)

Les transkripsjonen:

Vi prøver ut transkripsjon av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Velkommen til DPM-podkasten, der vi går utover teorien for å gi råd som fungerer når du skal lede bedre digitale prosjekter. Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager.

Så hvordan håndterer du det å gi tilbakemeldinger til personene i teamet ditt? Omfavner du det fordi du jo er prosjektleder og har rett, eller unngår du det fordi du er redd for ikke å bli tatt på alvor? Kanskje får du tilbakemeldinger og tenker at ingen egentlig forstår, eller kanskje ikke engang har hørt, det du sa. Som prosjektledere har vi ansvar for å skape suksess, men det er vanskelig når teamene våre så ofte ser ut til å være på villspor.

Finn derfor ut i dagens podkast hvordan du på en enkel måte kan gi tilbakemeldinger som hjelper teamene dine med å levere bedre arbeid og holde prosjektene på rett spor.

I dag har jeg med meg Ryan Schaefer. Ryan har gått fra å designe og bygge nettsteder til å lede utviklingen av dem, og han jobber i Washington, D.C., hos et byrå som heter Viget. Hei, Ryan.

Ryan Schaefer:

Hei, Ben. Takk for at jeg fikk komme.

Ben Aston:

Så Ryan, fortell oss litt om rollen din akkurat nå. Det jeg egentlig er interessert i, er hvordan du gikk fra design og utvikling til prosjektledelse. Det er et spørsmål vi ofte får. Hva gjør du akkurat nå? Jobber du utelukkende som prosjektleder, eller er du også litt nede i detaljene?

Ryan Schaefer:

Jeg vil si at det heller mest mot ren prosjektledelse, men jeg tror absolutt at noe som gjorde overgangen enklere for meg, var at jeg forsto tankene og prosessene som lå bak design- og utviklingsarbeidet.

Det gjør at jeg kan snakke med de svært dyktige designerne og utviklerne våre på et mer likeverdig nivå. Jeg trenger ikke spørre hva forkortelsene betyr, hvilke verktøy de bruker, og slike ting.

Jeg tror også bakgrunnen min fra et tidligere PR-byrå hjalp. Der hadde jeg en dobbeltrolle med både kundeansvar og gjennomføring, og det forberedte meg litt på hvordan jeg skulle formidle ting til en kunde og samarbeide med andre teammedlemmer. Derfor ble overgangen til prosjektledelse på heltid ganske naturlig for meg.

Ben Aston:

Men hvordan skjedde det? Hva var øyeblikket da du sa: «Greit, det var det. Jeg skal bli prosjektleder»?

Ryan Schaefer:

Det hadde litt å gjøre med at jeg ønsket å styre ting fra et fugleperspektiv, i stedet for å jobbe mer isolert. Men hovedårsaken var at jeg ønsket å bli med i et firma der alle var lidenskapelig opptatt av digitale løsninger og tenkte fremover. Det endrer åpenbart måten vi lever på som samfunn og som land. Jeg ønsket å være omgitt av mennesker som så dette og satte pris på det, og som samtidig var svært dyktige innenfor sine respektive digitale fagområder. Til syvende og sist ville det hjelpe meg med å utvikle meg profesjonelt.

Ben Aston:

Fortell oss litt om hva du gjør nå. Hvordan ser prosjektlederrollen ut hos Viget?

Ryan Schaefer:

Ja, først må jeg si at det heter Viget. Det får vi høre ganske ofte.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, ja.

Ben Aston:

Jeg gikk faktisk inn på nettstedet og klikket på en katt som sa at det uttales Viget.

Ryan Schaefer:

Ja, det finnes en knapp der det står «si hei». Det er Viget.

Ben Aston:

Det får man vel når man har et morsomt navn. Hva betyr det egentlig?

Ryan Schaefer:

«Sammen blomstrer vi» på latin.

Ben Aston:

Å, selvfølgelig.

Ryan Schaefer:

Noe i den retningen.

Ben Aston:

Moren min ville skamme seg over meg. Mamma, beklager. Hun er latinlærer. Jeg burde kunne slike ting.

Ryan Schaefer:

Latin var favorittfaget mitt på videregående. Vi måtte ha det. Jeg kan ikke tro at vi måtte ha det, men.

Ben Aston:

Det har jo forberedt deg godt på alle språkene du snakker nå, ikke sant?

Ryan Schaefer:

Ja, nettopp. Men rollen min som prosjektleder i Viget omfatter mange forskjellige ting. Det finnes selvfølgelig de sentrale prosjektlederoppgavene, som tidsplan, budsjett, planlegging, bemanning og ressursstyring. I tillegg har vi oppgaver som er mer spesifikke for produktledelse. Vi har ikke egne produktledere her, så prosjektlederne har ansvar for mange brukerreiser, funksjonsdefinisjoner, kvalitetssikringstesting og for å forstå virksomhetene vi jobber med og produktene vi skal bygge, fra innsiden og ut.

Ben Aston:

Så det er både prosjekt- og produktledelse?

Ryan Schaefer:

Ja, det er en blanding av begge deler.

Ben Aston:

Kan du fortelle oss litt om noen av prosjektene du jobber med nå?

Ryan Schaefer:

Jeg gikk faktisk over til fulltid på ett enkelt prosjekt for et par uker siden. Det er første gang det har skjedd meg. Vi jobber med et stort markedsnettsted og en slags portal for ulike målgrupper. De kan logge inn, og forskjellig data hentes for hver målgruppe.

Vi bygger i praksis økosystemet på nytt, oppdaterer designet for alt det digitale materialet deres som vender mot omverdenen, og lager en plan for fremtidige produkter, kanskje en app eller noe lignende. Det er svært omfattende, og jeg gleder meg til å fordype meg i ett prosjekt, bli godt kjent med det og lære mer.

Ben Aston:

Du skal holde et lynforedrag på DPM-toppmøtet om tips for å lede utviklingen av en innebygd app. Kan du gi oss kortversjonen av foredraget ditt? Hva har du oppdaget om utvikling av innebygde apper?

Ryan Schaefer:

Foredraget bygger på det jeg lærte under det største prosjektet jeg har jobbet med her, som var et design- og utviklingsprosjekt for en Android-app.

Jeg skal snakke om forskjellene mellom å lede utviklingen av en innebygd app og en mer vanlig nettbasert løsning, om beste praksis for dette og om de spesifikke tekniske kravene en prosjektleder må være oppmerksom på.

Det finnes et par eksempler. Konsekvensene av feil er svært store for en app, fordi appen kan krasje. På et nettsted er det vanligvis bare å laste siden på nytt. Språkene man bruker til innebygde apper, er heller ikke som JavaScript, som brukes til nettapper. Du må utvikle en langt større del av løsningen selv enn du vanligvis trenger på nettet.

Det finnes også systemkontroller og andre begrensninger, som at appen må fungere uten nett. Hvordan fungerer appen når den er frakoblet? Hvordan samhandler menyknappene på telefonen med appen, og hvor leder de deg? Slike ting må du ha oversikt over.

Ben Aston:

Du har jobbet med nettapper og åpenbart også innebygde apper. Hva mener du om utviklingen fra nettapper til innebygde apper?

Ryan Schaefer:

Vi ser blant annet en økning i tjenester som Squarespace, Beams i WordPress og Weebly. Dette er nyttige tjenester som gjør det mulig for personer med begrenset teknisk kunnskap å lage et nettsted som ser svært bra ut.

På grunn av den lave kostnaden og tilgjengeligheten er det vanskeligere å finne tradisjonelle markedsnettsteder. Innebygde apper har ennå ikke blitt like tilgjengelige, og derfor ser vi mange muligheter der. Det er også litt kult å kunne si at man har en app.

Ben Aston:

Hva finnes i verktøykassen din som prosjektleder? Hvordan styrer du produktene og prosjektene du jobber med?

Ryan Schaefer:

Det er viktig å starte sterkt. Jeg liker å legge til rette for fokuserte oppstartsmøter med kunden. En visjonssamtale er nyttig, der man snakker om hva organisasjonen gjør nå, hva produktet gjør og ikke gjør, og hvor de ønsker å være. Jeg liker også verksteder om problemer, mål og delmål, samt intervjuer med interessenter.

Mye av dette kan du ikke finne ut av i salgsprosessen, uansett hvor detaljert du prøver å være. Når du først forstår alt dette, noe som kan ta et par uker eller mer, kan du starte raskere, bygge mer effektivt og til slutt levere et bedre sluttprodukt.

Verktøyene du bruker for å organisere alt dette, kan være mange. Airtable er svært bra, og det samme gjelder GitHub Projects, ZenHub, Trello og flere andre. Vi bruker dem basert på kundenes preferanser og våre egne anbefalinger.

Ben Aston:

Finnes det noen bestemte prosjektlederverktøy du nylig har oppdaget, og som gjør livet enklere?

Ryan Schaefer:

Jeg bruker mye tid på å lære hurtigtaster på datamaskinen. De sparer kanskje bare sekunder, men det blir mange sekunder i løpet av en dag.

Ben Aston:

Hva er den favorittsnarveien du nylig har oppdaget?

Ryan Schaefer:

Command-Shift-T åpner den sist lukkede fanen.

Ben Aston:

Min favoritt på Windows er Windows-V i Windows 10, som viser historikken over det du har kopiert og limt inn.

Ryan Schaefer:

Det er en veldig god snarvei.

Ben Aston:

Det andre verktøyet jeg bruker, er Notion. Det er en arbeidsflateapp for notater og samarbeid, med støtte for frakoblet arbeid og et ryddig brukergrensesnitt. Du kan bygge inn innhold, lage nedtrekkbare seksjoner og bygge sider inne i undersider. Den finnes også på nett og mobil og kan tilpasses mye.

Ben Aston:

Hva synes du er vanskeligst i rollen din og i prosjektene du jobber med?

Ryan Schaefer:

Det vanskeligste er ofte å bytte kontekst. Som prosjektleder har du gjerne flere prosjekter og mange møter i kalenderen. Du hopper fra ett møte til det neste og må hente frem all informasjonen om prosjektet på vei til neste møterom. Jeg prøver å løse dette ved å ta grundige notater, lage sakslister til alle møter og sette av tid i begynnelsen av dagen til å tenke gjennom statusen for hvert prosjekt.

En annen utfordring er å legge til rette for samarbeid mellom designere og utviklere. Du får kanskje en vakker skisse fra designeren, men det er ikke alltid åpenbart hvordan alle funksjonene skal dokumenteres eller hvordan de skal styres i administrasjonsløsningen.

Vi undersøker derfor hvordan vi kan bruke Airtable til å strukturere innholdet, kryssreferere de ulike elementene i skissene og gjøre det enklere for utvikleren å forstå hvordan alt skal fungere, og hvor mye tid og budsjett som kreves.

Ben Aston:

La oss snakke om innlegget ditt. Det handler om å gi tilbakemeldinger på en måte som gagner prosjektet og fører til et bedre produkt.

Ryan Schaefer:

Det finnes et par grunner til at vi holder igjen. Den første er menneskelig: Vi vil ikke fornærme kollegene våre eller tråkke på arbeidet de har gjort. Den andre er at vi kanskje ikke føler oss sikre nok når vi gir tilbakemeldinger til fagpersonene, designerne og utviklerne.

Dette er rimelige bekymringer, men som prosjektleder er du nærmest kunden. Du ser arbeidet med et friskere blikk enn den som har jobbet nede i detaljene. Du kan derfor best simulere sluttbrukerens perspektiv og tilføre arbeidet et annet synspunkt.

Du bør føle deg trygg på denne typen kompetanse. Som prosjektleder ser du kanskje noe for første gang, slik brukeren også gjør. Formidler det tydelig hva organisasjonen gjør? Appellerer det til målgruppene? Er det åpenbart at dette er en rullegardinmeny? Slike reaksjoner hjelper teamet med å koble arbeidet til forventet brukeradferd og forretningsmål.

Ben Aston:

Hvordan vet man at man er tilstrekkelig informert?

Ryan Schaefer:

Man vet aldri helt sikkert at man har all informasjon, og det er greit. Visjonssamtaler er et godt utgangspunkt. Du lærer hvordan selskapet ser på seg selv og hvor det ønsker å gå. Samtaler med ledende interessenter gir deg en forståelse av hvordan de vil gjennomføre planene sine.

Når du starter et oppstartsprosjekt med personene som skal være direkte involvert, får du en forståelse av hvordan prosjektet henger sammen med ledelsens planer og virksomhetens overordnede mål. Alt dette bør komme tydelig frem i det dere forsøker å oppnå.

Det er en prosess i utvikling og krever mye investering i begynnelsen. Vi har lagt stor vekt på slike avklaringsfaser, fordi de skal besvare nettopp disse spørsmålene. Det gjør prosessen mer effektiv og fører til et bedre sluttprodukt.

Ben Aston:

Du nevnte også at man bør sette seg inn i flere fagområder. Hvordan gjør du deg kjent med kvalitetssikring, brukeropplevelse og andre områder du ikke kjenner fullt ut?

Ryan Schaefer:

Snakk med så mange på teamet som mulig, og vær åpen om kunnskapshullene dine. Hvis jeg kommer fra utvikling og ikke kjenner brukeropplevelse like godt, bør jeg ikke være redd for å følge en UX-designer og se hvordan vedkommende gjennomfører en gjennomgang.

Du bør også prøve å gjøre tingene selv. Det finnes mange ressurser hvis du vil lære å kode eller designe. Jeg prøver å bruke fem timer i uken på å øve på design, holde kodeferdighetene ved like og lese artikler. Jo flere møter du deltar i og jo lengre du jobber digitalt, desto mer lærer du også naturlig.

Ben Aston:

Hvilke nettsteder bruker du for å holde deg oppdatert?

Ryan Schaefer:

Thedigitalprojectmanager.com er et godt sted. A Girl’s Guide to Project Management er også bra. Adweek viser hvor det kreative feltet er på vei. For utvikling har W3Schools ressurser for CSS, JavaScript og andre teknologier.

Ben Aston:

Har du opplevd at denne tilnærmingen har slått feil?

Ryan Schaefer:

Det har heldigvis ikke skjedd med meg. Hvis du tar utgangspunkt i kundens perspektiv, er det et syn teamet må og vil respektere. Det handler mindre om å si «jeg liker ikke den fargen» og mer om å knytte valget til merkevareretningslinjer, målgruppe og prosjektets mål. Da kan designeren forklare begrunnelsen sin, eller gjøre nødvendige justeringer.

Ben Aston:

Hvordan balanserer du tydelige tilbakemeldinger, konstruktiv ros og det å ikke gjøre budskapet uklart?

Ryan Schaefer:

Det finnes ingen fast oppskrift. Som prosjektleder har du sannsynligvis en viss emosjonell intelligens, og den hjelper deg med å lese og reagere på hvordan folk tar imot tilbakemeldingen.

Det viktigste er å være konkret. Du bør ikke argumentere for subjektive ting, men for objektive beslutninger som kan knyttes til prosjektets mål. Du bør også formidle at du har tillit til personens evne til å gjennomføre arbeidet. Det er oppmuntrende, enten personen tar kritikken personlig eller bruker den som grunnlag for videre utvikling.

Ben Aston:

Hvis noen føler at stemmen deres ikke teller fordi de bare blir sett på som en administrativ prosjektleder, hva er det første de bør gjøre?

Ryan Schaefer:

Når du ser noe som virker feil, trenger du ikke gi tilbakemeldingen med én gang. Gå tilbake til pulten, se på det og skriv ned noen notater. Tenk gjennom hvor designet eller leveransen ikke treffer, og kom med forslag til forbedringer.

Da får du tid til å forstå arbeidet og møte forberedt. Jo mer grundig du er, desto mer vil teammedlemmet respektere tilbakemeldingen og være åpen for å ta den inn i neste versjon.

Ben Aston:

Det er gode råd. Folk kan reagere negativt når man bare sier «jeg liker ikke dette» eller «jeg synes ikke det fungerer». Det er bedre å forklare hvorfor noe ikke føles riktig, knytte det til kundens behov og spørre hvordan personen mener løsningen skal fungere. Deretter kan du foreslå mulige løsninger.

Å ha en begrunnelse, stille spørsmål og foreslå løsninger er viktig. Du kan også skissere ting på en tavle, slik at det føles som idéutvikling og ikke som om du prøver å overta designet.

Ryan, tusen takk for at du ble med oss.

Ryan Schaefer:

Tusen takk. Det setter jeg pris på.

Ben Aston:

Jeg lurer på hva du synes. Har du prøvd å gi tilbakemeldinger, og hvordan ble de mottatt? Ble teamet irritert, eller var de glade for at du påpekte noe de ikke hadde tenkt på?

Fortell oss hva du synes. Kommenter innlegget, og gå til thedigitalprojectmanager.com for å bli med i Slack-teamet vårt. Der finner du mange interessante samtaler om alt som handler om prosjektleveranser.

Hvis du likte det du hørte i dag, kan du abonnere og bruke et par minutter på å legge igjen en ærlig anmeldelse av DPM-podkasten på Apple Podcasts. Vi setter stor pris på vurderingene og anmeldelsene deres.

Men frem til neste gang: Takk for at du lyttet.