Kravinsamlingsmissar: Fyra tabbar och en katastrof

Under tjugo år har jag jobbat med programutveckling och kravspecifikation, helt eller delvis. I varje nytt projekt lär man sig något nytt. Här tänkte jag dela med mig av fyra kravinsamlingstabbar. Och en katastrof. Lär dig av andras misstag, så slipper du göra egna!

Tabbe #1: Att inte prioritera bland kraven

Det var den där gången då vi skulle göra en utökning av ett CRM åt en gammal arbetsgivare. Vi var unga och naiva. Vi ville utveckla agilt. Det gick inte alls bra. Ska man säga något snällt om projektet, så kan man säga att det var lärorikt. Vår (interna) beställare var säljchef och helt fokuserad på sin försäljning. Projektet däremot, det skulle leverera funktioner för att bygga, sälja och publicera annonser online. Såhär i efterhand så hade det varit bra om vi lagt mer tid på det som borde ha varit skall-krav, och mindre tid på det som borde ha varit bör-krav. Men vi gjorde varken någon sortering eller prioritering av kraven! Istället för en bra annonsförsäljningsmodul (med möjlighet att följa upp försäljningen) så levererade vi ett sinnrikt system för säljuppföljning (som också hade ett visst stöd för annonshantering). Det tog flera år att rätta till alla fel och brister. Lärdom: Gör en strikt prioritering. Vilka är skall-kraven? Vad ska vi vänta med?

Tabbe #2: Att gissa om integrationerna

Integrationer är lömska, så är det bara. Har du inte järnkoll på dem, så kommer de att bita dig. Här kommer ett till synes oskyldigt krav:

• "Det ska vara möjligt att importera ny kundinformation från en fil till registret."

Ser du problemet? Det är inte lätt, för problemet är det som inte står. Mitt naiva krav ovan sätter inga som helst gränser för hur kund­informationen får se ut. Det kan gå bra ändå, det brukar det göra när man själv kan både datakällan och registret. Men tro aldrig att du kan gissa hur lång tid det tar att importera information om du inte har koll på både källa och mottagare. Ja, den fällan har jag trampat i. Min värsta tidsuppskattningsmiss kommer från ett tillfälle då jag antog att kundens information skulle passa rakt in i min databas. När det var dags att leverera, så visade det sig att… det gjorde den inte. Och kunden hade inga möjligheter att leverera på något annat sätt. Istället för en eftermiddags arbete, så blev det en och en halv veckas jobb. Ingen tjänade några pengar på den affären, varken min dåvarande arbetsgivare eller kunden (som vi tappade). Lärdom: Utred varje integration separat. Saknas information om en integration, så kan du gärna göra rimliga antaganden och dokumentera dem... men gör i så fall inga bindande tidsuppskattningar!

Tabbe #3: Att göra en dålig datamodell

Vissa projekt verkar det ligga en förbannelse över. Så fort en liten sak ska läggas till, så faller alla tidsuppskattningar. Sen händer det igen. Och igen. Projektledaren blir allt mer strykrädd. Utvecklarna börjar längta till nästa projekt. Måste verkligen alla IT-projekt gå som Polisens och Försäkringskassans?  Ska jag gissa vad som är fel i ett projekt som verkar ha drabbats av en förbannelse, så gissar jag att projektets datamodell inte räcker till. Datamodellen ska beskriva hur din information hänger ihop, och bör vara ditt projekts stomme. Utan datamodellen så finns det liksom ingenting att hänga användningsfallen på. Har du fel i din datamodell, så kommer dina användningsfall att behöva ändras... liksom all kod som bygger på användningsfallen. Lärdom: Se till att du har en bra datamodell innan kodningen börjar. Då slipper dina utvecklare skriva om koden gång på gång. Det blir bäst och billigast så.

Tabbe #4: Att låtsas som att man förstår

När man kört alla workshoppar, gjort en bra datamodell, skrivit alla användningsfall, prioriterat och detaljerat alla funktionella krav... då är man väl ändå färdig? Nej, inte alls. Nu börjar kravrevisionen! Det är nu det ska det avgöras om kravinsamlingen verkligen beskriver det som ska levereras. Men det är alldeles för vanligt att kravrevisionen hastas igenom. Konsulterna verkar så duktiga, och jag förstår inte riktigt vad det står. Dessutom ska båten i. Och så är Arne sjuk, så jag får rycka in istället för honom. Det är nog rätt som det står i det där kravinsamlingsdokumentet... Kravinsamlare är också människor. Vi missuppfattar dig ibland, även om vi gör allt vi kan för att det ska bli rätt. Eftersom det är nästan gratis att rätta till ett fel under kravinsamlingen, så så vill jag här presentera kravinsamlingens gyllene regel: Fråga om du inte förstår! Lärdom: Förankra kravinsamlingen, och försäkra dig om att både beställare och leverantör förstår innehållet.

Katastrofen

Det var tidig morgon och första dagen på jobbet efter en lång, skön pappaledighet. Jag slog på kaffebryggaren och satte mig vid datorn. Så ringde telefonen på gruppnumret. Jag svarade. Någon skrek i luren. Han var så arg att han hade svårt att få fram orden. ”Vafan… har ni gjort? Ingenting… funkar.”. Det var Mikael som ringde. VD för vår viktigaste kund. När man är föräldraledig så hamnar man lätt i informationsskugga.

Min arbetsgivare hade tydligen tagit ett nytt system i drift medan jag var ledig. Systemet skulle ersätta vår gamla ockrare till dataleverantör. Business caset var visst helt fantastisk. På ritbordet sjönk kostnaderna dramatiskt. All teknik för att hantera informationsflödena funkade perfekt. Men kundnöjdheten var inte på topp. Så, vad var det som orsakade vår kundnöjdhetskatastrof? Det visade sig att vår gamla leverantör behandlade sin information på fiffiga sätt för att höja sökbarheten. Det gjorde inte vi, så den nya leveransen gick knappt att använda. Användarna skrek på sin chef. Chefen skrek på oss. Firman hamnade (milt sagt) i blåsväder. Vi hade lagt hela vårt fokus på projektets ekonomi, deadline och den rena IT-delen. Vi hade missat slutanvändarna. Det är otroligt vanligt att säljprocesser och kravinsamlingar fokuserar på chefernas behov och ansvarsområden. Ekonomi, rapportering, uppföljning och compliance hamnar i första rummet. Det är inte konstigt, det är ju oftast chefer som fattar köpbeslutet. Men samtidigt som cheferna oftast har den bästa övergripande kollen på verksamheten, så är det (oftast) medarbetarna som har den detaljerade kunskapen som behövs för att kravställa systemstöd. Utan medarbetarnas perspektiv riskerar man att leverera en skrivbordsprodukt som användarna inte vill (eller kan) använda. När IT-projekt kör i diket, så beror det på att verksamhets­processerna inte stöds på ett bra sätt. Det är sällan rapporterna det är fel på. Det är heller inte systemets grafiska profil som ställer till det. Vill du ta fram ett nytt IT-system, så bör du därför kartlägga och prioritera alla dina intressenters krav på djupet innan du väljer väg. När du har valt väg, så behöver du förmedla en djup förståelse om dina verksamhetsprocesser – och informationen som ska hanteras – till den som ska leverera ditt system. En kravinsamling hjälper dig med kartläggning, prioritering och informationsförmedling.

Lärdom: Gör en kravinsamling som tar med alla relevanta perspektiv! PS: Visste du att våra (Multisofts) kunder ger oss 4,4 av 5 möjliga i betyg när vi driftsätter nya system? Det är bra i IT-branschen! Särskilt om man tittar på nyutveckling. PPS: Betyget (NKI-index, "nöjd-kund-index") ovan är framräknat från "tidernas begynnelse" (typ 2015 någon gång) fram till i skrivande stund (2017-07-24).