Senast uppdaterad
Här kommer en enkel fråga: när vet du som minst i ett projekt? Är det i början, i mitten eller i slutet?
I början va?
Trots det är det just då många skriver sin kravspecifikation, som i sin tur ligger som grund för både offert och planering av projektet. Varför gör vi så: tar på oss ansvars-hatten och försöker lösa det allra svåraste först? Dessutom gör vi det i ord i ett dokument, inte genom konkret arbete som sker när rätt personer samarbetar. Min gissning är att kravspecifikationen är ett bekvämt sätt för både beställare och leverantör att få igång en dialog.
Ett konkret exempel
Som en del i Invise så bygger vi hemsidor och titt som tätt får vi frågan: vad kostar en ny hemsida?. Som svar på det kan vi ge den lätt irriterande återkopplingen: hur långt är ett snöre? För saken är den att det är stor skillnad på en hemsida och en hemsida. Det är som att fråga: vad kostar ett hus?
Med en kravspecifikation kan den som beställer helt enkelt skicka samma underlag till flera olika leverantörer och jämföra deras svar och pris. Och som leverantör får man helt enkelt något att definiera ‘hur långt snöret egentligen är’.
Men det finns ett fundamentalt fel i detta! Beställaren skriver kravspecifikationen (galet nog rätt ofta på begäran av leverantören) trots att det är leverantören som är mest kunnig på området!
Jaha – vad ska vi göra istället då?
Till att börja med tycker jag man ska göra en sak – träffa personerna för projektet. Är det exempelvis aktuellt att ta in en byrå som oss. Träffa några potentiella byråer. Handen på hjärtat – Invise får inte hem affärer på att vi skickar offerter till kunder vi aldrig träffat. Det funkar inte för oss!
Innan ni träffar de olika personerna/leverantörerna så kan det vara bra med en kort story eller målbild. Det räcker som referensram för att få igång dialogen. Det bör få plats på ett A4 och kan beskriva ett drömscenario för projektet. Ska ni ha någon form av specifikation till detta så ta bara med sånt ni vet att ni måste ha!
Jag vill också betona en sak till: all den tid som går in i en kravspecifikation (som ändå kommer visa sig fel) kan ni lägga på något annat. Som riktigt arbete i projektet!
Vad ska ni titta efter?
Genom att ta bort kravspecifikationen så kommer det bli svårare att jämföra olika leverantörer baserat på deras pris. Jag kommer till detta senare. Men i början ska ni kolla på dessa saker istället:
- Har personerna/teamet gjort något liknande tidigare?
- Finns kemin där, klickar ni med varandra? Tro mig det är viktigt!*
- Finns passionen där. Det känner ni – och kom ihåg att passion inte alltid uttrycker sig som rationella argument. Det märks på andra sätt och är svårt att i intervjua sig fram till. Man kan inte tvinga fram passion genom att grilla någon med frågor för att sätta press! Det får motsatt effekt. Fråga istället: om du fick fria händer att lösa XYZ, hur skulle du göra?
- Fråga tidigt om en form av referensram för priset, detta bör inte vara en offert eller ett avtal. Bara ett sätt för er att se att ni talar samma språk när det kommer till priset.
*Jag vill faktiskt nämna denna lite extra. Om kemin och tron på varandra finns där så uppstår det ett helt annat utbyte där alla vågar leva ut mer. I detta kommer både ärlighet och modighet att slänga ut idéer, testa nya saker osv. Allt detta bygger resultat!
Vad gör ni efter detta?
Rätt enkelt faktiskt, skissa fram en tydligare målbild och utforma en lite bättre specifikation. Till denna sätter ni en budget!
Har ni kommit så här långt så har ni börjat lära känna varandra genom att jobba på något gemensamt. Detta kallar jag riktiga framsteg! Som i alla projekt kommer detta underlag lägga grunden för ert arbete. Nu är det viktigt att förstå att ni kommer komma på fler saker under arbetets gång. För som jag inledde med, ni vet som minst om projektet i början. Det viktiga då är att ni har satt upp en budget att styra mot. Då går det att gemensamt ta beslut som står i förhållande till denna budget. Kan och vill ni få fram mer pengar för att finansiera eventuella saker som ni kommit på längs med vägen eller behöver ni prioritera något nytt före något ni sa från början?
Läs mer: Spara tid (pengar) genom att bli en bättre beställare!
Förmågan att prioritera är en av nycklarna. Det är så mycket viktigare än att falla tillbaka på en kravspecifikation och säga vad som är rätt eller fel i relation till den. Den som ändå går i fällan att tro att kravspecifikationen är mätvärde för om ni gjort rätt eller fel kommer att:
- Få ont i huvudet för då måste ni börja tänka som jurister och leta fel mellan kravspec och verklighet
- Ta död på all passion från de som är allra bäst i projektet genom att i efterhand peta hål på bra idéer och beslut som fattats efter kravspecen och i arbetet
- Bygga in ett beteende att kravspecifikationer är exakt vetenskap (vilket de aldrig är) för att sedan hitta någon att skylla på för att ni inte levererat enligt kravspecen.
- Att definiera något som kanske gått bra, som ett misslyckande för att ni glömmer värdet i det som egentligen skapats
Jag tänkte avsluta det här inlägget med två citat som kommer från design- och mjukvaruutveckling men som jag ändå tycker återspeglar den “riktiga världen” rätt bra 🙂
“A ‘spec’ is close to useless. I have never seen a spec that was both big enough to be useful and accurate.
And I have seen lots of total crap work that was based on specs. It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality!”
Linus Torvalds, creator of Linux (from: Linux: Linus on specifications)
”I found that people insisting on extensive requirement documents before starting any design were really ‘blockers’ just trying to slow the process down (and usually people with nothing to contribute on design and innovative thinking).
All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good results.”
Mark Gallagher, corporate intranet developer (from Signal vs Noise)
