Krav != lösning

I avdelningen "Märkliga förväntningar" har turen nu kommit till

Jag ställer kraven, du programmerar lösningen.

Jovisst, det är sant att kraven ska komma från verksamheten. Det är verksamheten som ger intäkten och systemen ska stödja verksamheten.

Och jovisst, det är en utvecklingsavdelning som ska leverera lösningen. Det är deras jobb.

Men däremellan är det inte lika enkelt.

För det första: vad är skillnaden mellan krav och utveckling? Egentligen?

I den stund en tanke väckts på en förändring någonstans, så är utvecklingen igång. Så verksamheten utanför utvecklingsavdelningen är i någon mån utvecklare.

Och även om lösningen ska fungera i verksamheten, så ska den ju först och främst fungera. Vilket betyder att den inte enbart är underkastad verksamhetskrav, utan en hel dröse andra krav som har med IT-systemets egenskap av att vara IT-system att göra. Så utvecklarsidan är på samma sätt i någon mån kravställare.

Och då inträder den intressanta situationen att dessa krav gärna är i konflikt, att vi har en zon där muren mellan kravställare och utvecklare inte kan upprätthållas. Och konflikter måste som bekant lösas. Hur?

IT ska inte styra verksamheten. Verksamhetskraven har alltid prioritet över IT-sidans invändningar.

Ett klassiskt sätt att skjuta sig i foten, som mest avslöjar att man inte riktigt förstår sig på IT-sidans invändningar. Och därmed inte sin egen verksamhet heller. Från den stund man blandat in IT i verksamheten, är IT en del av verksamheten.

IT är verktyg, på samma sätt som telefonsamtal, grafiska manualer, säljkampanjer, fabriksgolv, logistikkedjor, you name it. Verktyg har egenskaper. Försöker man sig på att styra verktygsanvändning utan att förstå sig på hur dessa egenskaper påverkar siffrorna i årsredovisningen, går det vanligtvis åt pepparen. Säljkampanj utan kunskap om kundpsykologi, logistikplanering utan geografikunskaper, beslut om IT-stöd utan kunskap om informationshantering och tekniska begränsningar... Hejdå, vinst!

Så hur bör man göra då?

Jo:

1. Ta fram verksamhetskraven. Med prislapp (vad tjänar vi på att få kravet uppfyllt).
2. Låt en människa som är kunnig i både IT- och verksamhetskrav hjälpa dig att skärpa och tvätta kraven, så att både människa och maskin kan bli nöjda med den.
3. Låt en duktig människa ta fram en design som löser problemen. Förvänta dig inte att designen ska implementeras på en gång, det är alltid bättre att ta det i etapper (iterationer). Ofta leder etapp 1 till att de ursprungliga kraven förbättras. Det är därför som RUP och andra iterativa utvecklingsmodeller fungerar så bra.
4. Sätt dig in i vad designen innebär för din verksamhet. Det är designen du kommer att leva med under systemets livslängd (och ofta längre än så, vanligen behåller man en design i flera system).
5. Fatta beslut kring designen. Sådär. Nu har du och din verksamhet försvurit er åt designen. De lösningar som framgent kommer att förverkligas, kommer att ske inom designen.

För varje verksamhetskrav finns det hundra designer som kan lösa kravet. Varje design har egenskaper som kommer att påverka din verksamhet på det ena eller andra sättet.

Därför är det så viktigt att du skiljer mellan krav (som är din verksamhets problemformulering), och den lösning som du vill införa.

Så när någon säger:

Jag ställer kraven, du programmerar lösningen.

...så säger denne egentligen:

Jag ger dig bara en liten del av kraven, och jag bryr mig inte om vilken design du kommer upp med, och jag struntar fullständigt i hur din lösning kommer att påverka verksamheten i framtiden.

Och det tycker jag är ett märkligt sätt att förhålla sig till sin egen verksamhet.