Att lyckas med krav (med Kelly Suter från BI Worldwide)

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge expertråd inom projektledning för bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Så var ärlig: har din kund någon gång vänt sig till dig i slutet av projektet och sagt: ”Du lyckades verkligen med det där. Det är exakt vad vi ville ha, precis det du sa att du skulle göra i början av projektet, och det är fantastiskt hur du lyckades få med allt utan att tappa något på vägen”?

Jag misstänker att det inte har hänt. Och det beror förmodligen på att era krav inte var tillräckligt väl definierade. Så hur kan du hantera krav så att du inte hamnar i en total röra senare i projektet, samtidigt som du ger kunden och utvecklaren den information de behöver för att få jobbet gjort? Det är vad dagens podd handlar om: projektkrav.

Det sätt på vilket vi definierar ett projekt och funktionalitet för våra kunder, så att alla vet vad som ska levereras. I grunden tycker jag att krav är ett kommunikationsverktyg, men det är ett väldigt svårt verktyg att få rätt. Om vi definierar kraven för löst ger vi oss själva större flexibilitet, men vi kanske inte får tillbaka exakt det vi ville ha. Om vi definierar dem för strikt kan det däremot finnas mängder av saker som saknas. Så hur hittar vi rätt balans?

I dag pratar jag med Kelly Suter. Kelly är teknisk projektledare på BI Worldwide och en av våra lokala Deakin-experter hos The Digital Project Manager. Hej Kelly.

Kelly Suter:

Hej, tack för att jag fick vara med, Ben.

Ben Aston:

Nej, det är fantastiskt att ha dig här. Jag tror att det här är vår andra podd, eller hur?

Kelly Suter:

Ja, det stämmer.

Ben Aston:

Vi gjorde en podd för länge sedan. För de som har glömt vem du är, vill du ge oss en överblick? Hur kom du in på projektledning? Du har tagit en intressant väg, tror jag, vilket egentligen inte skiljer sig så mycket från de flesta projektledares väg. Vi hade aldrig som mål att bli projektledare när vi växte upp. Berätta lite om din historia. Hur kommer det sig att du nu är digital projektledare?

Kelly Suter:

Jag började faktiskt min yrkeskarriär som sportreporter. Därifrån gick jag vidare eftersom jag hade studerat kommunikation med inriktning på PR och medier. När jag insåg att tidningar inte längre var en bransch på uppgång bestämde jag mig för att gå över till PR-branschen. Jag arbetade som PR-konsult i ungefär tre år för ett varumärke, Sesame Street Live, och fokuserade verkligen på det varumärket under de åren. Sedan träffade jag någon som arbetade på en specialiserad e-handelsbyrå, en digital byrå med full service och helt fokus på e-handel.

Hon sa: ”Vi har ingen projektledningsavdelning här. Vill du bli projektledare?” Och jag svarade: ”Vad är det?” Min pappa hade faktiskt en grafisk designbyrå, så under hela min uppväxt hade jag tillräcklig insyn i byråprocesser för att veta att det var hektiskt och alltid var något på gång. Men jag tänkte: ”Ja, jag är med. Vi får se vad ni har där.” Jag började där, och den första bok jag någonsin läste var Meghan McInernys People, Pixels, and Process. Jag vet inte om jag sa det i rätt ordning, men jag läste den och tillämpade den—

Ben Aston:

Jag vet vilken du menar, ja.

Kelly Suter:

Ja. Jag—

Ben Aston:

People, Pixels … Jag tror att den heter People, Pixels, and Process, ja.

Kelly Suter:

Precis. Jag tillämpade den så gott jag kunde på byrån jag hade framför mig. Då var vi tolv personer. Som sagt byggde vi anpassade webbplatser för e-handel. Efter ungefär fyra år hade jag byggt upp ett team med sju projektledare, och vi kunde tillämpa den här processen som hela tiden utvecklades. Därifrån tänkte jag att jag kände mig väldigt bekväm med Magento, Drupal, Cantego, WordPress och liknande, och jag ville verkligen bredda mina tekniska kunskaper. Därför sökte jag den tekniska projektledarroll som fanns på min nuvarande arbetsplats, BI Worldwide. Jag gick hit eftersom jag ville tillbaka till projektledningsvärlden, komma närmare projekten och vässa mina tekniska verktyg. Det är där jag befinner mig i dag. Det har varit väldigt spännande. Det känns som om tiden har gått på ett ögonblick, men jag älskar det verkligen.

Ben Aston:

Jag är alltid nyfiken: är det här ditt … Berätta, vad är ditt drömjobb? Det känns som om du har haft en väg som låter ungefär så här: ”Det är häftigt, jag är sportreporter, jag arbetar för Sesame Street och nu jobbar jag inom teknik som projektledare.” Men vad vill du bli när du blir stor?

Kelly Suter:

Det är en väldigt bra fråga. Jag tror att det jag tycker bäst om med det jag har hamnat i, både där jag är nu och där jag nyligen var på Irish Titan, den andra utvecklingsbyrån, är att komma in när det är tydligt att en process inte riktigt finns eller precis håller på att utvecklas. Det betyder inte att teamet inte är väldigt kompetent eller redan levererar bra saker, men jag tycker verkligen om att ta mig an utmaningar där det finns utrymme för process: att se vad som fungerar och få team att känna lättnaden i att ha något att arbeta med och luta sig mot. Jag tror att mitt drömjobb är att få vara den brandman, i brist på ett bättre ord, som hjälper kanske nystartade eller växande företag att införa en process. Sedan kan man säga: ”Okej, vi har infört den här processen. Nu provar vi den på det här och det här.” Jag älskar verkligen en saftig utmaning.

Ben Aston:

Härligt. Berätta då: vilka utmaningar arbetar du med nu? Du går väl in i den där brandmansrollen och försöker reda ut processer och byråarbete, vilket är en utmaning. Men vilka utmaningar möter du dagligen, eller vilken särskild utmaning arbetar du med just nu?

Kelly Suter:

För närvarande skulle jag säga att min största utmaning bland alla de saker vi ständigt kämpar med är att på ett sätt som inte blir tråkigt få teamet att verkligen ställa sig bakom dokumentation. Jag vill inte låta som om jag säljer in ämnet för just den här podden, men när man har en entusiastisk kund och ett engagerat team är det svårt att få fullt stöd för: ”Okej, vi behöver inte sakta ner och vi behöver inte tappa momentum, men vi måste dokumentera.” Sedan behöver dokumentationen mallifieras och grunderna täckas tillräckligt väl. Det behöver inte vara så arbetskrävande som det ibland blir, men det måste finnas tillräckligt med dokumentation för att inte all logik och alla processer ska försvinna om du byter team, blir befordrad eller får en annan roll. Jag har sett team som hela tiden uppfinner hjulet på nytt, antingen i produktutvecklingen eller i dokumentationen. De överkonstruerar sådant som annars kunde ha mallifierats eller gjorts effektivare.

Just nu arbetar jag med dokumentation där den senaste versionen är från 2014. Den har fungerat för alla, även kunden, men vi vill inte att det ska fortsätta vara så. Senare, när man granskar arbetet, är det skönt att ha allt samlat och uppdaterat.

Ben Aston:

Okej. Du arbetar alltså med utmaningarna att definiera processer, skapa dokumentation och förbättra processer. När du gör det, finns det några verktyg du använder som gör livet enklare just nu? Hur levererar du det och vad använder du?

Kelly Suter:

När det gäller dokumentation brukar jag inte ändra på något som fungerar. Jag använder Google Workspace, Google Dokument och ett delat utrymme, förutsatt att kunderna inte har säkerhets- eller integritetsproblem med informationen i dokumentationen. Man kan ställa in behörigheter för vem som bara får läsa, vem som får kommentera och vad som endast ska delas internt med teamet.

Då behöver man inte tänka på versionshantering, och senare kan man exportera dokumentet som PDF och göra det till ett formellt dokument som går att signera. När det handlar om att faktiskt skriva dokumentationen är det vad vi använder. InVision är ett mycket bra verktyg för kreativa avstämningar och kommentarer när man tar fram den kreativa delen. Där lägger formgivarna in sina designer eller trådskisser, och sedan kan kunden eller intressenten som granskar materialet kommentera. Det är ett intuitivt sätt att kommentera när designerna är färdiga. Man kan dessutom analysera dem i InVision och sedan exportera dem till dokumentationen, eftersom visuellt material tillsammans med dokumentation är mycket värdefullt. Om man inte har InVision, eftersom det är en tjänst som kostar pengar och kan bli dyr, kan man använda Sketch. Sketch är ett verktyg jag har använt när jag inte haft någon budget för InVision. Det är ett kostnadsfritt verktyg från Evernote som kan användas för att kommentera på ett snyggt och enkelt sätt. Man laddar bara upp sina designer, lägger till siffror eller bokstäver som kommentarer och arbetar vidare därifrån.

Jag försöker alltså inte göra det mer komplicerat än nödvändigt. Jag behöver ett sätt att importera mina designer, kommentera dem, lägga in dem i dokumentationen och sedan skriva texten. Det är vad som har fungerat för mig när det gäller dokumentation.

Ben Aston:

Bra. Jag vill gå tillbaka till din utveckling som digital projektledare. Nu är du teknisk projektledare, men jag förstår att du har flera olika roller: projektledare, BA, affärsanalytiker och SCRUM-master. Hur skiljer sig en teknisk projektledare från en digital projektledare? Är det samma sak? Och hur fungerar det för dig att bära alla de här olika hattarna?

Kelly Suter:

Det är en mycket bra fråga. I min specifika roll här känner jag mig väldigt lyckligt lottad eftersom den är unik. På BIW arbetar jag både med teknisk projektledning och mer traditionell projektledning. Jag arbetar med projektledning för liveevenemang och med projektledning för kursinnehåll. Det utgör ungefär en fjärdedel av det jag gör. De övriga tre fjärdedelarna består av teknisk projektledning, och där tror jag att det varierar beroende på var man arbetar.

Man kan hitta digital, teknisk och agil projektledning, men man är fortfarande projektledare. Den största skillnaden mellan den digitala projektledarroll jag hade tidigare och min nuvarande roll som teknisk projektledare är nivån på den förståelse som krävs för det digitala arbete man utför. Hur tekniskt blir arbetet? När jag var digital projektledare hade jag händerna i alla rörliga delar. Jag arbetade kanske på en högre nivå, men jag visste att jag behövde förstå innehållsstrategi, webbplatsstruktur, trådskisser och kreativt arbete. När det gällde utveckling tänkte jag ungefär: ”Jag vet att ni måste granska den här informationen och ta fram hur informationen ska se ut vid export för ert lager. Säg till när ni är klara.”

I min nuvarande roll som teknisk projektledare är jag mycket djupare nere i utvecklingsarbetet. Jag hanterar fortfarande leveranser från den kreativa avdelningen, den digitala strategin och kvalitetssäkringen, men i utvecklingen kan jag i ett projekt behöva vara närmare kvalitetssäkringen. Vid kodgranskningar och releaser arbetar jag sida vid sida med den ansvariga utvecklaren och säger: ”Det här är kraven jag skrev. Hur stämmer de överens med koden du ser innan den bockas av från listan?” En annan skillnad är att jag själv skriver de tekniska kraven. Ju närmare kraven man befinner sig, desto större ansvar har man och desto närmare behöver man vara när diskussionerna dyker upp längre fram.

Som digital projektledare hanterade jag kraven, informerade rätt personer om vad de behövde göra och såg till att det blev gjort. Som teknisk projektledare skriver jag faktiskt kraven själv. Jag befinner mig alltså längre ut i utvecklingsarbetets skyttegravar.

Ben Aston:

För de som inte är bekanta med funktionella krav eller affärskrav: det är det du arbetar med, eller hur? Du utformar funktionella krav och affärskrav. Det här är ofta ett lite känsligt och förvirrande område, eftersom det kan finnas en tvetydighet kring vem som ansvarar för vad. Ur utvecklarens perspektiv kan man höra: ”Det är projektledarens jobb” eller ”Det är affärsanalytikerns jobb. Det är inte mitt jobb att definiera det.” Å andra sidan kan BA:n eller projektledaren säga: ”Jag kan inte definiera det här. Jag vet inte vilka alternativen är.” Du har uppenbarligen en roll där du sitter någonstans i mitten. Hur går du tillväga?

Kelly Suter:

I början av varje projekt, eller när man först kommer in i ett team eller ett företag, måste man verkligen förstå rollerna och ansvarsområdena. Även om de är definierade kan de utvecklas eller förändras beroende på kunden. Det har hänt att vi arbetat med en anpassad integration där jag kunnat säga: ”Okej, den här integrationen är som ett lager, en databas med alla olika produkter. Jag behöver att produkterna visas löpande och att det exakt framgår hur många T-tröjor som finns i lager, samt hur många som finns i små, mellan och stora storlekar. Informationen måste uppdateras dagligen vid den här tiden.”

Jag kan berätta för utvecklaren vad jag behöver ska hända, men utvecklaren kanske går en nivå djupare än jag kan. Jag förstår inte den nivån och kan inte låtsas göra det. Jag vill i stället kunna säga: ”Okej, jag ansvarar för kraven fram till den här punkten. Kan du hjälpa mig att slutföra dem genom att ställa de fem varför-frågorna?” Det är något jag tar upp i min artikel. Man frågar: ”Varför behöver du att detta fylls i på det här sättet?” Svaret kan vara: ”Det är så ofta besökarna köper den här produkten.” Sedan fortsätter man fråga varför.

Vid någon punkt måste man dra en gräns och säga: ”Okej, utvecklare, jag behöver att du hjälper till att skriva resten av kraven för den här funktionen eftersom jag inte kan göra det, och jag vill inte riskera att något faller mellan stolarna bara för att jag inte förstår det.”

Det är en balans. Man måste identifiera vad man kan göra från början. Jag har fått frågan: ”Varför gör du det här när affärsanalytikern borde göra det?” eller ”Borde inte utbildningsstrategen göra det?” Mitt svar är: ”Absolut, ni kan be någon annan i teamet att göra det. Men då måste ni fråga er hur mycket av deras budget ni är beredda att avsätta för kravarbete, och sedan behöver ni göra avstämningar där alla granskar arbetet. Var sparar ni mest budget? Var blir ni effektivast: om ni skriver kraven själva eller om någon annan gör det?” Det är en balans som förändras. Så länge människor inte tar det personligt vem som äger vad, utan i stället spelar på varandras styrkor, kommer det att lösa sig. Men det måste finnas kommunikation kring det.

Ben Aston:

För de som hör det här och tänker: ”Vad är affärskrav eller funktionella krav ens?” De kanske tänker att en byrå eller studio bara gör design och sedan lämnar över till utvecklarna som bygger. Du pratar om dokumentation. Är inte det motsatsen till vad vi borde göra? Vi borde väl vara agila och flexibla?

Vad är din syn på det? Vad är de här dokumenten och varför är de viktiga?

Kelly Suter:

När jag talar specifikt om dokumentation av affärskrav, BRD, och dokumentation av funktionella krav, FRD, kan man jämföra BRD med en grundkurs. Det är ofta de övergripande punkterna: vi behöver översätta detta till spanska och mandarin, vi behöver leverera tio olika kurser, detta måste vara live i april och vi måste kunna stödja en användardatabas med 6 000 användare eller den mängden trafik. Det kan vara innehållet i en BRD. Det är i princip: ”Det här har vi pratat om hittills. Se till att ni arbetar åt rätt håll.” Det är en formalitet och en kontrollpunkt där alla på båda sidor bekräftar: ”Okej, vi är överens.”

Samtidigt finns det förstås formuleringar om att vi ska definiera detta mer noggrant senare. Om något faller utanför omfattningen eller börjar överskrida budgeten meddelar vi det, prioriterar om och avgör vad som ska vara kvar, vad som ska tas bort och vad som flyttas till en fas två.

FRD:n är ytterligare en kontrollpunkt, och mycket händer mellan BRD och FRD. Man tar varje punkt och utvecklar den med större detalj. Okej, vi ska översätta till spanska och mandarin. Ska vi använda en extern leverantör? Ska vi skriva kod så att det blir mer automatiserat? Ska administratören manuellt lägga in tre språk separat i innehållshanteringssystemet? Man utvecklar alla dessa punkter. BRD:n är alltså en kontrollpunkt som säger: ”Vi är alla överens.” Samtidigt vet man att FRD:n kan växa, definitivt. Man kan upptäcka att kunden inte har budget för översättning just nu och därför flytta den till en fas två. Det dokumenterar man i FRD:n och fokuserar på att definiera resten.

Den ena utvecklas alltså till den andra, och FRD:n blir egentligen ritningen för bygget, eller så borde den vara det.

Ben Aston:

BRD:n är alltså det vi definierar i början av projektet. Den beskriver i princip hur framgång ser ut ur ett affärsperspektiv. Hur ska projektet skapa framgång? Vilka områden behöver vi beröra? De funktionella kraven beskriver däremot hur en viss funktion ska fungera. Om webbplatsen ska vara tillgänglig och läsbar för personer i Kina måste den vara på mandarin och lokaliseras. Där går vi in på detaljerna.

Men låt oss prata om det agila. Det finns utvecklare som säger: ”Visa mig kraven, jag kan inte göra något utan krav.” Men när man ger samma utvecklare kraven säger de ibland: ”Det här är inte hur vi borde arbeta. Vi borde vara agila, leverera en liten del av funktionaliteten och iterera. Vi behöver inte skapa all den här omfattande dokumentationen.” Hur hittar man balansen mellan ett iterativt arbetssätt och mer agila arbetsmetoder, där man försöker begränsa dokumentationen och i stället testa och lära?

Du försöker ju definiera allt så väl som möjligt i den funktionella kravdesignen, så att det finns en gemensam förståelse för hur affärsnyttan ska levereras. Hur hittar du den balansen?

Kelly Suter:

Man hittar balansen genom att ha en gemensam förståelse från början. Jag vågar nästan säga att man bör dokumentera den: ”Okej, vi kommer att använda en agil process. Det här innebär det. Det här behöver vi från kunden och det här behöver vi internt.” Man behöver ha en ordentlig intern projektstart där man säger: ”Okej, här är produkten vi arbetar med.”

Just nu bygger vi ett program som kopplar poäng till lärande. Man går igenom kursmaterial, gör framsteg och får poäng. Det finns logik som är direkt kopplad till att samla poäng som sedan kan användas på en marknadsplats. Vi vet inte det vi inte vet. Kunden vet att de vill ha det och vill ha det i januari. De litar på oss eftersom vi har arbetat med dem i flera uppdrag tidigare och vet att vi kan genomföra det.

Vi har inte tid att göra all dokumentation, hur mycket jag än skulle vilja det. Jag måste känna mig bekväm med att säga: ”Okej, det här är slutmålet.” Utan att definiera alla mellanliggande steg och utan att mödosamt bygga ut alla uppgifter och dela upp dem i sprintar har vi våra dagliga avstämningar vecka för vecka. Då säger vi: ”Du arbetar med märken, du arbetar med certifikat, du arbetar med topplistan och du arbetar med köpupplevelsen.”

Varannan vecka gör vi en leverans och presentation för kunden. De vet att det de ser inte bara är grovt utan också att det inte kommer att vara färdigpolerat på framsidan. Målet är att få funktionaliteten på plats, eftersom det finns API:er i bakgrunden som hanterar poängen, deras värde och var de kopplas.

De här avstämningarna är ovärderliga. Som projektledare kan du dokumentera dem: ”Det här visar vi i dag. Vi visar märken kopplade till den här typen av kursmaterial. Det här kan ni förvänta er eftersom det är vad vi har gjort den senaste veckan. Här är frågorna vi eventuellt har till er.”

När man har den avstämningen med kunden och de säger: ”Jag trodde att det skulle vara så här”, finns det ett förtroende. De kan uttrycka sin oro, vi kan bemöta den och ta fram en plan för följande vecka. Det svåra, men nödvändiga, är att hela tiden följa utvecklingen—

Ben Aston:

Där har vi det.

Kelly Suter:

Man behöver fråga: ”Hur ligger vi till mellan nu och den färdiga produkten? Behöver vi kanske ta bort certifikaten eftersom vi inte kan göra dem just nu och måste fokusera på något annat?” Jag tror alltså att det handlar om ständig kommunikation, löpande dokumentation och förtroende.

Ben Aston:

En sak som ofta kan sätta projektet på paus redan i början är om man väntar tills allt är definierat. Om man säger att man inte kan göra något innan de funktionella kraven för hela projektet är färdiga tar det väldigt lång tid. Jag gillar tanken att de funktionella kraven är viktiga eftersom de ger utvecklarna en tydlig definition av vad de ska bygga, kunden tydlighet kring vad den kommer att få och kvalitetssäkringen möjlighet att veta vad den ska testa mot. Kraven utvecklas alltså under arbetets gång: gör så mycket som behövs för att hålla projektet i rörelse.

Men det tar förstås mycket tid att dokumentera allt. Hur gör du det i praktiken? Skriver du en uppgift i JIRA eller hur ser arbetsflödet ut?

Kelly Suter:

När jag har slutfört en FRD betyder det inte att jag har arbetat isolerat utan att jag har stämt av med alla. Jag informerar teamet om att jag kommer att ställa frågor under arbetets gång, antingen om bästa praxis eller om var vi landade i en tidigare diskussion.

När FRD:n är färdig har alla granskat den och den har godkänts av kunden. Då gör jag en av två saker. Jag presenterar den för utvecklingsteamet på ett sätt som tar hänsyn till att vissa utvecklare vill få kraven och veta exakt vilka uppgifter de har, medan andra inte vill att man berättar hur deras uppgifter ska utföras.

Jag frågar därför: ”Vill ni helst bygga ut uppgifterna själva eller vill ni att jag gör det?” Oftast kan jag bygga ut dem eftersom de har granskat FRD:n. Jag skapar en uppgift för varje rad och skriver mina berättelser per sidtyp: registrering, startsida eller produktsida. Sedan skapar jag deluppgifter för varje rad på den sidtypen.

Jag låter alltid utvecklarna uppskatta sin egen tid. Om möjligt bör den person som ska utveckla funktionen göra uppskattningen. Eftersom de har läst kraven och känner till förväntningarna bör avvikelsen mellan uppskattningen och dokumentationen vara minimal.

Jag använder JIRA, Atlassians verktyg för uppgiftshantering. När allt finns i backloggen får utvecklarna uppskatta arbetet och ordna det ungefär efter hur de tänker angripa uppgifterna. Sedan delar jag in dem i sprintar baserade på 30–35 timmars veckor, om de arbetar med en enda uppgift i taget. Om man arbetar agilt och vill ha ett kvalitetssäkringsmoment för varje uppgift bör kvalitetssäkringsresursen, eller du själv, lägga in en rad i varje ärende som beskriver hur man testar att uppgiften lyckades.

Ben Aston:

Jag vill beröra det du nämnde om uppskattning. När projekten blir mer tekniska blir det en större utmaning. I början vill kunden veta vad projektet kommer att kosta, men vi känner inte till all funktionalitet. Du beskrev en mer agil process där man arbetar med kunden och kanske har ett löpande avtal, så att man inte behöver uppskatta hela projektet på förhand utan kan uppskatta per krav.

Hur hanterar du början av projektet när du ska säga: ”Jag tror att det här kommer att kosta 200 000”? Utgår du från affärskraven? Hur gör du den preliminära uppskattningen innan de funktionella kraven är färdiga, så att projektet kan starta? Och hur översätter du sedan den preliminära uppskattningen till de faktiska funktionella kraven och den mer detaljerade funktionaliteten?

Kelly Suter:

Det är en omfattande fråga. Om jag fick bestämma skulle jag som projektledare få vara med och ta fram en grov uppskattning. Men 90–95 procent av tiden har jag inte möjlighet att påverka uppskattningen, annat än i en förbipasserande diskussion. Om någon säger: ”Jag pratar med en kund som har en bra idé. Tror du att vi kan få det klart till mars?” har jag förstås hundra och tio frågor direkt.

När jag faktiskt får möjlighet att ta fram en grov uppskattning vill jag först veta vad vi har gjort tidigare. De flesta företag har någon form av specialisering. De som säger att de är plattformsoberoende, erbjuder full service och gör allt möjligt får det svårt att sälja.

Jag tar reda på vad vi gjort tidigare och ser om det finns likheter i användarbasens storlek eller företagets storlek som jag kan jämföra med. Ett exempel är att en e-handelswebbplats i Magento tidigare tog sex till åtta veckor med två utvecklare. Det var en ungefärlig tidsram som gav oss en viss prisnivå att utgå från, även om vi inte hade exakta timmar eller kronor.

Det jag skulle säga till säljare eller affärsutvecklare är: ”Vi vet inte ännu.” Om det inte finns några integrationer eller anpassningar och det handlar om en standardlösning kan vi säga vad den sannolikt kommer att ta. Men det är svårt att uppskatta mer än så. Därför är det värdefullt att ha en utvecklingsansvarig eller teknisk projektledare som kan tala för den avdelningen. Ibland är det den tekniska projektledarens roll. Det är bra att ha ett enkelt dokument i bakfickan: ”Om det gäller e-handel eller ett lärplattformssystem har vi detta att jämföra med.” Det är ett öppet svar, men det är svårt.

Ben Aston:

Du talar om jämförande uppskattning. Det är det bästa sättet tidigt i ett projekt när vi ombeds ge en ungefärlig siffra men ännu inte känner till de funktionella kraven. Man frågar en utvecklare hur lång tid det tar att bygga en e-handelswebbplats, men det finns så många variabler att det enda vi egentligen kan göra i det tidiga skedet är att säga: ”Här är tre projekt som liknar det ni beskriver. Här är den lägsta och den högsta nivån. Det nya projektet hamnar kanske någonstans däremellan.” Sedan bör man undvika att binda sig vid siffran tills kraven har definierats mer fullständigt. Upptäcktsarbetet handlar om att definiera kraven, och när de är definierade kan vi göra en bättre uppskattning.

Kelly Suter:

Två övningar jag alltid gör är väldigt snabba att prata med kunden om. Den första är triangeln med omfattning, tidsplan och budget. Jag ber kunden rangordna dem från ett till tre efter betydelse. Kunden säger ofta: ”Alla tre!” och skrattar. Då säger jag: ”Men om du måste rangordna dem, vad är viktigast?” Det avgör mycket. Prioriteringen kan förändras under projektet, till exempel när ett nytt räkenskapsår börjar.

Den andra övningen är bra, bättre, bäst. Om kunden har en viss budget säger jag: ”Jag vill lika gärna som ni hålla oss inom den budgeten. Men om en integration dyker upp eller en extern leverantör gör att något hamnar utanför omfattningen, kan vi göra det här, men det kostar mer än budgeten. Om vi håller budgeten får ni däremot avstå från något i omfattningen. Eller så hittar vi en medelväg.” Kunden får fatta det svåra beslutet, i stället för att vi bara säger att något inte kommer att hända.

Det är de två övningarna jag tycker är mest värdefulla för att hålla projektet inom tidsplan, omfattning och budget. De gör också att kunden känner sig delaktig i samarbetet och får fatta affärsbeslutet.

Ben Aston:

Det är bra. Du talar om att göra det till ett samarbete. Kunder kan ibland pressa oss att binda oss vid en budget, vilket är särskilt svårt vid fast pris och i tekniska projekt med nya integrationer eller plattformar som vi inte känner till. Jag gillar tanken på att göra det till ett samarbete och hjälpa kunden förstå att utökad funktionalitet kräver mer arbete. På så sätt kan vi anpassa uppskattningen, arbetssättet och funktionaliteten efter kundens verkliga prioriteringar.

Om någon lyssnar och tänker: ”Det här låter bra. Om jag kunde definiera för utvecklarna vad de ska bygga, även om de aldrig har gjort det tidigare och hittills bara fått trådskisser och designer, skulle det vara värdefullt.” Vad säger du till någon som vill prova att skriva krav? Vilket är det första steget för att introducera krav och bli mer noggrann med att definiera utvecklingsarbetet?

Kelly Suter:

Om du för första gången arbetar som digital projektledare och lever i den digitala tidsåldern, med smartphones, surfplattor och teknik överallt, vet du mer än du tror. Du har redan exponerats för digitalt beteende, lärt dig vanor och klarat dig i den tekniska tidsåldern. Du har fått mer erfarenhet än du förmodligen inser.

Hoppa därför inte direkt in på Google och sök efter en mall för teknisk dokumentation, ladda ner den och försök fylla i luckorna. Börja med att ta ett steg tillbaka: ”Vad gör vi för den här kunden? Vi bygger en registreringssida för ett evenemang med en startsida och ett webbformulär på startsidan. Vad behöver vi definiera?” Hitta varje element på sidan och fråga: ”Vad gör detta på mobil och på dator?” Börja där.

Förklara det som om du pratade med någons mormor, som fortfarande använder en gammal Nokia-telefon. Förklara det högt för dig själv och gå sedan till utvecklaren och fråga: ”Har jag förstått det rätt?” Utvecklaren kommer att uppskatta att du ställer frågorna och säkerställer att du definierar något på ett sätt som gör det möjligt för dem att lyckas när de bygger det.

När du börjar dokumentera krav, dela upp arbetet i elementen som ska byggas och förklara dem. När jag tittar på min första kravdokumentation låter den säkert mer samtalslik än den borde, och jag var förmodligen inkonsekvent med samma funktion på olika sidor. Det är okej. Det kommer att utvecklas. Det här är ett digitalt projekt för kunden, något de sannolikt inte gör hela tiden. Du representerar ditt företag, din grupp eller ditt team som expert. Gå igenom det med kunden. Du vet mer än du tror eftersom vi alla lever i den digitala världen.

Ben Aston:

Det var verkligen hjälpsamt. Krav handlar i grunden om att ställa frågor och få svar på dem. När man börjar definiera krav kan man tänka: ”Är det här en dum fråga? Är det uppenbart?” Men inget är egentligen självklart. Börja med att ställa frågorna till dig själv. Om du skulle förklara det för din mamma eller mormor, vad skulle du behöva berätta?

Kom också ihåg att kraven bara är ett kommunikationsverktyg: dokumentationen gör att alla kan vara överens om vad som faktiskt ska göras. När ni har tydlighet kring leveransen blir det mindre slöseri med tid och mindre arbete med att hantera förväntningar. Det tar tid att skapa dokumentationen, men den betalar sig genom att ni slipper omarbete och besvikna kunder som får något annat än de förväntade sig.

Kelly, stort tack för att du var med. Det har varit fantastiskt att ha dig här.

Kelly Suter:

Tack, jag uppskattar det.

Ben Aston:

Som en av våra DPM-experter medverkar Kelly också i vår kurs Att bemästra digital projektledning. Om du inte vet vad jag pratar om men känner att du behöver utbildning inom projektledning kan du ta en titt. Vi har en intensivkurs på sju veckor med interaktiva videolektioner, uppgifter, gruppdiskussioner och webbinarier. Gå till dpmschool.com och anmäl dig. Kursen börjar i februari. Om du vill bidra till diskussionen om krav och hur vi arbetar med dem kan du gå till resurssektionen på thedigitalprojectmanager.com och gå med i vårt Slack-team, där det pågår många intressanta diskussioner, eller kommentera inlägget. Men tills nästa gång: tack för att du lyssnade.