Beskriv dina behov och inte en lösning …. snälla

”Beskriv dina behov och inte en lösning! Det är vi som ska komma på lösningen” är något som man kan höra rätt ofta från en frustrerad kravhanterare eller systemarkitekt.

Det finns nog ett par olika anledningar till att man enkelt hamnar i den situationen när IT och verksamhet diskuterar framtida initiativ. En är att det oftast är enklare att uttrycka sina behov via en lösning eftersom man också har idéer på hur lösningen ska se ut. Att sedan öppna upp för en annan lösning än den man sett framför sig kan både kännas riskfyllt, skrämmande, och framförallt blir ju lösningen då någon annans.  Detta skapar ofta ganska mycket friktion. Att envist basunera ut att man ska hålla sig borta från lösningen är kanske inte de pedagogiska knepet att ta till i dessa lägen och det är heller inte helt rätt (enligt mig).

Jag vill därför ge några argument varför verksamheten ska hålla sig ifrån lösningen och några exempel på situationer då man ska släppa in verksamheten i dessa diskussioner.

Oavsett om man, som beställare, har kunskap eller ej i tekniken, så är man i behov av att förstå sina behov. Det skärper ofta till de egna tankarna kring ämnet och det går också att knyta an nyttor mot dessa på ett mer naturligt sätt än om man beskriver sina behov via lösningar.

Att jobba med behov och problemformuleringar skapar flexibilitet och förståelse. Så hur kan det gagna beställaren?

• Teamet kommer kunna ta fler beslut utan beställarens inblandning och de kommer vara i linje med dennes behov (vilket då rimligtvis borde vara i linje med dennes tankar när hen väl ser lösningsförslaget).

• Behov kan realiseras på många olika sätt. Om beställaren uttrycker sin önskan via en färdig lösning så får teamet aldrig chansen att utforska andra lösningar på givna behov. Exempel : om du säger att du vill ha en Kolmårdsmarmor som golvsten så får du just det. Men om du säger att du vill ha känslan av Kolmårdsmarmor så kan du få ett golv som ser ut som det men som är billigare, hållbarare och lättare att köpa in bara för att du inte har begränsat till en given lösning. Så behov och en tydlighet kring vad som är viktigt är det som ska vara i fokus.

En trångsynt inställning till vem som får bidra med lösningsförslag är ju sällan särskilt konstruktivt och ofta tycker jag att man förväxlar ansvar med att bidra. IT är ansvariga för lösningen men hela teamet bör vara involverade i framtagandet av den. I ett cross-funktionellt agilt team, bör därför även beställaren/verksamheten vara inkluderad. Då kastar vi inte behoven över muren, utan alla förstår behoven och alla är lika välkomna att komma med lösningsförslag.

Så, för att summera; beskriv behov för dig själv och andra så blir ni alla klokare och teamet mer självgående. Släpp in verksamheten i lösningstänket - se det som ett lysande tillfälle att hitta en gemensam yta för att skapa förståelse!

Robert Wallerblad, Require AB