Att få saker gjorda på rätt sätt (med Michael Luchen från Crema)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ursäkta eventuella stavfel eftersom roboten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Det är frustrerande när saker inte fungerar, särskilt när vi har ägnat veckor eller månader åt att bygga ett projekt och sedan blir svikna av en lömsk bugg när det är dags för den slutliga UAT-testningen. Men varför verkar det nästan alltid hända, och finns det något vi kan göra åt det? Om buggar stör dig, fortsätt lyssna, för i dagens poddavsnitt ska vi diskutera hur vi kan få saker gjorda på rätt sätt med en förbättrad produkt och process samt magin i en kvalitetsstyrningsplan.

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av Project Managers. Välkommen till DPM-podden. Vårt uppdrag är att hjälpa projektledare att lyckas och att hjälpa personer som leder projekt att leverera bättre resultat. Vi vill hjälpa dig att ta ditt projektarbete till nästa nivå. Besök thedigitalprojectmanager.com för att läsa mer om vår utbildning och våra resurser som vi erbjuder genom medlemskap. Den här podden presenteras av Clarizen, ledande inom programvara för projekt- och portföljhantering för företag. Besök clarizen.com för mer information.

I dag har jag sällskap av Michael Luchen, som är en av våra fasta DPM-experter. Han arbetar som produktcoach på Crema, en digital produktbyrå som skapar webb- och mobilappar för nytänkande företag och branschledare. Han arbetar vanligtvis på distans från Washington D.C. och hjälper team att förbättra sitt samarbete samt analysera och lösa komplexa problem. Han har arbetat med bland andra Adidas och Callaway Golf och är coach på Crema. I dag ska vi prata med honom om att bygga en kvalitetsstyrningsplan. Hej Michael och välkommen till programmet.

Michael Luchen:

Hej Ben, hur är läget?

Ben Aston:

Bra, tack. Jag är nyfiken eftersom din roll har utvecklats under de år vi har pratat med varandra och spelat in poddavsnitt. Jag är särskilt intresserad av din nya roll som coach. Kan du berätta lite om vad en coach är, vad en produktcoach gör och vad det innebär på Crema?

Michael Luchen:

Det här bygger på ungefär sju års praktisk erfarenhet av projekt- och produktledning. Ärligt talat håller rollen fortfarande på att definieras. Vi försöker förstå vad en coachroll på Crema ska innebära. Just nu ser vi den helt enkelt som ett tjänande ledarskap där vi hjälper kunder att förstå agilt arbetssätt och bli bättre versioner av sig själva. Jag kan fungera som facilitator, produktstrateg och design thinking-utövare för att hjälpa dem att omformulera problem och hitta innovativa angreppssätt. Det som är intressant med den nya rollen och satsningen på Crema är att vi försöker göra skillnad i en konkurrensutsatt bransch genom ett mycket unikt och icke-föreskrivande angreppssätt. Det finns så många föreskrivande coachningsprocesser där ute, och vi vill göra saker annorlunda.

Ben Aston:

I din roll arbetar du alltså med ett litet team direkt tillsammans med kunden. Är det mer strategiskt än när man försöker definiera projektets eller produktens färdplan?

Michael Luchen:

Det liknar det du nämnde, men är lite bredare och mer fokuserat på människor. En av sakerna jag tycker bäst om med projektledning är att skapa en hälsosam miljö där team kan göra sitt bästa arbete. Det här handlar om att hjälpa kunder att få de verktyg och det tankesätt som krävs för att skapa en sund och produktiv kultur och miljö i teamen, så att de kan uppnå riktigt bra resultat.

Ben Aston:

Vilka typer av utmaningar möter du när du hjälper kunder att förändra sitt leveranstänkande?

Michael Luchen:

Det finns många utmaningar, men en viktig sak är att resultaten inte alltid kommer omedelbart. Det här är inte något där jag kan gå in och säga: gör så här, så blir allt bättre. Det finns mycket sådant där ute – lär dig ett visst ramverk så kommer teamet att lyckas. Men det viktiga är att förstå hela den kulturella kontexten i organisationen och inse att det tar tid att experimentera och förstå hur lärdomarna passar in när man stärker de ledare man arbetar med.

Ben Aston:

Det stämmer verkligen att det inte finns en enda process som är helt rätt för alla organisationer eller byråer. Om man bara följer stegen får man inte plötsligt magiska resultat. Det finns ingen silverkula som löser alla problem. Ibland tänker människor att agilt arbetssätt är silverkulan, men då måste man först definiera vad det betyder. Det låter som en intressant roll. Gör du främst detta på distans eller på plats hos kunderna?

Michael Luchen:

En kombination. Just nu, när vi spelar in detta, sker allt till hundra procent på distans. Relationer kan byggas personligen, så om det är möjligt är det bra att inleda coachningen på plats. Men jag har upptäckt att man kan skapa mycket produktiva och meningsfulla samtal via Zoom, eller använda Loom skärmdelning för att ge vägledning, besvara frågor och samarbeta i Mural-tavlor. Det går alltså bra på båda sätten.

Ben Aston:

Vi talar om distansarbete och befinner oss mitt i karantänen på grund av corona. Du höll nyligen en workshop för oss om distansarbete. För den som missade den, eller för dig som nu reflekterar över hur det är att arbeta på distans när alla tvingas göra det, vilken metod använder du för att inte bli tokig när du arbetar ensam? Hur hanterar du känslan av isolering?

Michael Luchen:

Jag försöker mentalt komma ihåg att jag samarbetar med och arbetar tillsammans med andra människor. Därför har videosamtal i Zoom varit otroligt värdefulla. Det låter enkelt, särskilt nu när Zoom är en av de mest nedladdade gratisapparna, men det är viktigt att använda samtalen medvetet ur ett samarbets­perspektiv. Vi kan hoppa in i ett Zoom-samtal med teamet och prata igenom saker. Icke-verbal kommunikation är mycket värdefull, särskilt för en projektledare. Jag brukar till och med ha en andra skärm när jag delar min skärm, så att jag fortfarande kan se allas ansikten.

Ben Aston:

Det är goda råd. Zoom är ett bra verktyg, men när vi också har Slack kan frestelsen vara att bara skriva i Slack och glömma all kommunikation vi går miste om samt möjligheten att bygga relationer. Samtalet blir annorlunda när man använder Zoom, så klä på dig och ta ett Zoom-samtal också.

Michael Luchen:

Just nu går jag helt över från produktledning till coachrollen. Jag avslutar ett stort utvecklingsprojekt för ett företag som har pågått i flera år. Det är intressant att närma sig det med ett coachande tankesätt eftersom det finns mycket överlappning när man tar coachning ner till praktisk nivå. Nu blickar jag framåt mot att bygga upp coachningstjänsterna och tydliggöra hur Crema kan göra skillnad och hjälpa kunder med ödmjukt självförtroende.

Ben Aston:

När du funderar på vilka kundutmaningar du kan hjälpa till att lösa, vilka leveransproblem ser du som möjliga möjligheter när du bygger upp rollen?

Michael Luchen:

Jag har en intressant metafor för det. Vi ser coachning som ungefär en termin i en högskoleutbildning. Anledningen är att effektiv coachning i hög grad handlar om experimenterande, där de personer jag coachar själva får prova och lära sig. Min roll blir framför allt att vara facilitator, vägledare och mentor med praktisk erfarenhet.

Det innebär regelbundna avstämningar, retrospektiv, observationer och delade anteckningar. Man kan säga: prova det här på nästa möte. Det handlar om att skapa en rytm så att vi efter några veckor eller månader kan se tillbaka och konstatera att det skett en tydlig förbättring och att teamet kan producera mer.

Ben Aston:

När du identifierar delar av en organisation som kan bli mer agila, hur hjälper du dem att prioritera? Hur identifierar du vilka delar av processen eller leveransen som är lämpliga att börja med?

Michael Luchen:

Jag tror att det börjar med en undersökning och ett samtal. Undersökningen behöver kanske inte bara gå till en kontaktperson utan även till projektledare, utvecklare och andra som deltar eller vill delta i processen. Man tar reda på vad de uppfattar som viktigast att lösa. Sedan går teamet tillbaka, granskar svaren och jämför dem med undertexten i det man hört. Därefter kan man rekommendera att gå vidare med de två eller tre områden som sannolikt ger bäst resultat.

Ben Aston:

Jag vill återgå till ditt inlägg och ämnet där vi började: kvalitetsstyrning. Om du inte redan har läst inlägget, hittar du det på thedigitalprojectmanager.com. Det heter hur man utvecklar en kvalitetsstyrningsplan. Michael går igenom en grundlig steg-för-steg-process för att skapa kvalitetsplanen. Medlemskapet ger också tillgång till en lista över målenheter och krav samt en mall för kvalitetskontroll.

Vi ska inte gå igenom hela processen här eftersom den finns i inlägget, men sammanfattningsvis beskriver Michael hur man skapar en kvalitetsplan för sitt projekt eller sin produkt. Jag vill börja med själva kvalitetsbegreppet. Du börjar med att skapa en gemensam förståelse för vad kvalitet betyder i projektet. Varför är det så svårt att få grepp om?

Michael Luchen:

Jag ser kvalitet som två saker: produktkvalitet och processkvalitet. Produktkvalitet är kvaliteten på den konkreta eller digitala produkten och omfattar resultatet av designteamets, utvecklingsteamets och andras arbete. Processkvalitet är något som vi projektledare har stort inflytande över och syftar på den process vi utvecklar, som i sin tur påverkar teamets möjlighet att skapa resultat. Ett exempel på ett mått som många känner till är hastighet, som kan hjälpa till att mäta hur processen fungerar.

Det är svårt för många team att skapa en gemensam förståelse av kvalitet eftersom det finns så mycket subjektivitet och känslor i frågan. Många intressenter, inklusive utvecklare och designers i det egna teamet, kan ha olika perspektiv och skäl. En kund kan vilja ha en kvalitetsnivå som motsvarar förväntningarna, medan en utvecklare kan värdesätta kodkvalitet och ren kod och vilja skriva den perfekta koden. Vi måste därför hjälpa till att skapa balans.

Ben Aston:

Med agilt arbetssätt har vi acceptanskriterier för en användarberättelse som definierar vad den ska göra. Vi har också en definition av klar, som gäller för alla användarberättelser. När vi arbetar agilt försöker vi leverera värde stegvis. Ibland kan kvalitet verka stå i konflikt med detta. Vad är viktigast: att uppfylla alla acceptanskriterier och definitionen av klar, att leverera värde eller båda delarna – och måste vi då arbeta långsammare?

Michael Luchen:

Att fokusera på kvalitet står inte i konflikt med agilt arbete. Jag tycker tvärtom att kvalitet påskyndar och möjliggör agila arbetssätt. Om teamet i början av projektet definierar vad kvalitet betyder och inte betyder, hjälper det teamet att fokusera på rätt saker när arbetet byggs och levereras. Det tydliggör vad som ska och inte ska räknas in.

Acceptanskriterierna fungerar också som ett verktyg för att stödja agilt arbete. Om teamet arbetar med en användarberättelse under en sprint och utvecklarna stöter på ett tekniskt hinder som förändrar en del av acceptanskriterierna, öppnar det för en bra diskussion. Man kan pausa, prata kort tillsammans och uppdatera kriterierna. I det exemplet finns acceptanskriterierna där för att stödja kvalitet.

Ben Aston:

Det handlar alltså om att förändra synen på kvalitet. Kvalitet behöver inte stå i konflikt med att snabbt leverera värde. Kvalitet är i själva verket en viktig del av värdet. Om något inte uppfyller de kvalitetskriterier vi har satt kanske det inte skapar så mycket värde som det borde. Vi behöver se kvalitet som en del av det värde vi skapar.

Michael Luchen:

Precis.

Ben Aston:

Du talar också om att dela upp ansvaret för kvalitetsstyrning. Större byråer eller organisationer har ibland särskilda kvalitetssäkringsteam, men ofta hamnar ansvaret hos projektledaren eller utvecklarna. Du förespråkar rollen som testingenjör. Varför är den så viktig?

Michael Luchen:

Tidigt i min karriär som projektledare arbetade jag själv med kvalitetssäkring. Nu när jag samarbetar med testingenjörer ser jag en enorm skillnad. Rollen är viktig eftersom det krävs ett tränat kritiskt öga för kvalitet. Testingenjören fungerar enligt min erfarenhet som projektledarens bästa partner. Rollen granskar detaljerna i både det som byggs och det som levereras på ett sätt som ingen annan i teamet gör.

Testingenjören arbetar på detaljnivå ur ett tekniskt perspektiv men ser också helheten: utvecklingen och hur det som byggs faktiskt levereras till användarna. När testingenjören får arbeta på det sättet blir personen en central teammedlem som förstärker värdet av utvecklarnas, designernas och projektledarens arbete.

Ben Aston:

En testingenjör eller kvalitetssäkringsanalytiker har ofta ett annat tankesätt än en projektledare. Som projektledare tänker jag på den optimala vägen. När jag testar något tänker jag: det här är vad man gör, eftersom jag känner produkten och vet hur den ska fungera. En testingenjör har däremot erfarenhet av att förstöra saker och tänka på kundupplevelsen genom utforskande testning. Det ger mer noggrannhet och ökar kvaliteten på slutprodukten eftersom det alltid kommer att finnas buggar i det vi producerar.

I artikeln talar du om att fastställa målenheter. Det kan vara svårt när kunden vill att produkten ska fungera på alla enheter, även gamla telefoner och webbläsare. Hur hjälper du kunden att hantera det?

Michael Luchen:

Att fastställa målenheter är en av mina favoritövningar. Det hjälper inte bara till att begränsa kvalitetsfokus och var teamet ska investera, utan även till att begränsa fokus på vilka resultat man försöker skapa för användarna.

Om kunden vill stödja alla enheter och operativsystem som någonsin har funnits kan man börja ställa frågor om vilka användare man faktiskt stödjer och vad de behöver. Ibland leder diskussioner om gamla webbläsare till viktiga samtal om användarvärde. Samtalet om målenheter hjälper teamet och kunden att fokusera på användaren, prioritera och förstå vad som är viktigt och vad som inte är det.

Ben Aston:

Det är bra råd. När du skriver en arbetsbeskrivning eller definierar acceptanskriterier bör du vara försiktig med formuleringar om vilka enheter som stöds. Skriv inte bara att produkten ska fungera på alla mobila och stationära enheter för all framtid. Webbläsare utvecklas och saker som fungerade tidigare kan sluta fungera när en ny version släpps. Därför är det viktigt att definiera målenheterna i förväg.

Jag vill tala om testfall och gå ner på detaljnivå. Många har hört talas om testdriven utveckling, men det finns också testning i stunden och dokumentation under arbetets gång. Bör man ha en testplan? Vad tycker du om testdriven utveckling och ger den rätt resultat i fråga om värde?

Michael Luchen:

På Crema har våra testingenjörer lett företaget mot förståelsen att kvalitet är allas ansvar. Våra utvecklare arbetar med testdriven utveckling och ser till att integrationstester skrivs in i koden för de komponenter där det är relevant. När den testbara funktionaliteten når testingenjören finns det utrymme att fokusera mer på manuell testning ur användarens perspektiv, skriva automatiserade tester och utföra utforskande testning av gränsfall.

Ben Aston:

Alla ansvarar alltså, men fienden till att alla ansvarar är att ingen ansvarar. Hur uppmuntrar ni kvalitet som ett värde i organisationen? Hur ser det ut i praktiken?

Michael Luchen:

Det börjar med utbildning. Vi har Slack-kanaler där vi pratar om kvalitet och ser till att det pågår en kontinuerlig diskussion om vad kvalitet betyder för våra projekt. Projektledare kan hjälpa till genom att skapa processer som gör att teamen kan genomföra kvalitetskontroller under hela arbetet. Vi använder JIRA, där arbetsflödena kan konfigureras med exempelvis kodgranskningar. När något går från pågående till testmiljö genomförs en kodgranskning, och när det går från testmiljö till kvalitetssäkring finns en process som säkerställer att det får tillräckligt med tid och täckning.

Ben Aston:

Kvalitet integreras alltså i själva processen, inte bara genom att man bygger en komponent och sedan testar den. Att utveckla komponenten innebär också att den ska testas. Man kan använda både manuell och automatiserad testning. Hur avgör ni när automatiserad testning är värd tiden det tar att bygga upp?

Michael Luchen:

Manuell testning är mycket värdefull och lätt att komma igång med. Den är särskilt användbar när användarupplevelsen är omfattande eller när det inte är värt arbetet att bygga automatiserade tester, exempelvis vid en dra-och-släpp-interaktion i en app.

Automatiserad testning är däremot bra när man ska göra samma sak om och om igen. Långa och komplexa informationsformulär är ett bra exempel. Extra bra är det om testingenjören kan skriva automatisk ifyllnad med alla ovanliga tecken som våra appar ibland måste hantera.

Ben Aston:

Det låter som att er kvalitetsstyrningsplan bygger på att göra rätt från början genom att integrera kvalitet i utvecklingen, men också på att undvika en standardlösning för kvalitet och testning. Angreppssättet anpassas efter projektet och de komponenter man arbetar med. Hur blir du säker på att ni väljer rätt väg i en organisk process?

Michael Luchen:

Jag tycker mycket om den organiska processen. På samma sätt som vi mäter hastighet under några sprintar för att skapa bättre förutsättningar för resten av projektet ser jag på kvalitet. När vi startar ett projekt gör vi ett första försök. Artikeln om att skapa en kvalitetsstyrningsplan beskriver en bra struktur och en stabil grund.

Men det är alltid ett antagande. Om teamet inte har arbetat tillsammans tidigare kommer saker naturligt att förändras under de första sprintarna eller veckorna. Man måste vara öppen för att justera planen utan att avvika dramatiskt. Om man exempelvis upptäcker att en av målenheterna inte används kan man uppdatera listan och lägga mer tid och energi på andra områden.

Nästa gång jag startar ett projekt bygger jag naturligtvis på erfarenheterna från det föregående, men med hänsyn till det nya teamet.

Ben Aston:

Sunt förnuft spelar en stor roll i kvalitetsstyrning. Om kvalitet alltid trumfar allt annat kan planen bli som dokumentation som görs bara för sakens skull. Vi behöver hitta balansen: ha kontroller och en plan, men också använda sunt förnuft och anpassa oss under arbetets gång. Det knyter an till det agila arbetssättet, där man kan använda mer flexibel och utforskande testning för att säkerställa att man levererar värde stegvis.

Michael Luchen:

Exakt.

Ben Aston:

Vi har nyligen lanserat en podd på vår systersida som heter QA Lead. Om du är intresserad av kvalitetssäkring och arbetar med testingenjörer, be dem besöka QAlead.com. Som projektledare bör du också läsa inlägget, som är mycket detaljerat och innehåller exempel och mallar som delas genom medlemskapet.

Om du inte har använt en kvalitetsstyrningsplan tidigare kommer den att hjälpa dig att tänka igenom processen, projektet eller produkten och hur du kan skapa mer värde genom att leverera en produkt av högre kvalitet.

De här tipsen har varit värdefulla, men det som verkligen fastnade hos mig är tanken att kvalitet måste odlas i hela organisationen. Oavsett om man har testingenjörer eller inte behöver alla tänka på kvalitet – inte bara om något är trasigt, utan också på hur processen fungerar och hur organisationen kan förbättras. Tack så mycket Michael för dina insikter.

Michael Luchen:

Tack.

Ben Aston:

Vad tycker du? Vilka knep, tips och metoder använder du för att leverera projekt eller produkter med hög kvalitet? Berätta vad som fungerar och inte fungerar. Om du har misslyckanden eller framgångar att dela med dig av, skriv en kommentar nedan.

Om du vill lära dig mer och utvecklas i arbetet kan du gå med i vår gemenskap genom DPM-medlemskapet. Besök thedigitalprojectmanager.com/membership för tillgång till vårt Slack-team, mallar, workshops, frågestunder, e-böcker och mycket mer. Om du tyckte om dagens avsnitt kan du prenumerera och hålla kontakten via thedigitalprojectmanager.com. Tack så mycket för att du lyssnade.