Kravhantering – kontraproduktivt?

Kravhantering, så som den bedrivs i IT-projekt idag, är slöseri med tid och resurser. Med tanke på hur många, särskilt inom användbarhetsområdet, som arbetar med kravhantering är det förstås en provokativ tanke.

Kraven finns där för att det är en stor lucka mellan affärs- och verksamhetskonsulternas abstrakta rapporter och den faktiska systemimplementationen de ibland förordar. Så långt allt väl. Men vad är kraven egentligen bra för? Vad försöker de beskriva?

Jag hävdar bestämt att krav är en artefakt av ett alltför ingenjörsorienterat arbetssätt. Ett arbetssätt där man trots allt uppmärksammat att man på något sätt måste definiera och specificera vad det är som ska göras, visst. Problemet är att så fort kraven är formulerade glömmer man varenda ord om vad, varför och för vem. Du kan ha kartlagt och skrivit personas, definierat scenarios, vad som helst, men när kraven finns där är det dom som styr. Obevekligt. Och i 9 fall av 10 levereras ett system som uppfyller tillräckligt många av kraven för att leveransen ska vara godkänd men som inte går att använda och som inte fyller nån affärsnytta.

Pengar i sjön.

Och det värsta är inte att jag säger dethär utan att det faktiskt händer. Igen och igen och igen. Och beställarna svarar med att försöka bli bättre och bättre på att skriva krav. Blir det det?

Inte så vitt jag vet.

Snarare har kraven förvandlats från generella ”bilen ska vara bränslesnål” till specifika ”bränsleinsprutningen måste vara kalibrerad till 0,00001% marginal”. Kontraproduktivt.

Därför har jag börjat prata om att krav är föråldrat. Vill man verkligen uppnå affärsnytta kartlägger man behov och förväntningar och matchar dem mot verksamhetens strategier och visioner.

Detdär är ju inget nytt för de flesta av oss. Men nästan alla arbetar fortfarande med krav och kravhantering – det är till och med en särskild yrkesroll och i linjeverksamhet har man ofta kravhanterare anställda; först tar man fram behoven, målen och konceptet. Sen simsalabim gör man krav.

Och där någonstans tappar man bort hela nyttan med investeringen.

Som en konsekvens av detta provar jag just nu med att strunta i krav. Det enda (sic!) som behövs är ju egentligen att kartlägga, prioritera och balansera alla intressenters behov och förväntningar, inklusive affärsstrategierna och målen. Sen dokumenterar man det i koncept, design rationale, lösningsarkitektur och interaktionsdesign. Hur exakt man går till väga beror ju på om man implementerar standardsystem, om man gör en app till en padda, eller vad det nu är, men i grunden är det ju inga konstigheter.

Självklart måste man ha koll på informationsarkitektur och verksamhetsregler och en massa andra saker. Men så fort man gör krav av dem blir det de som styr, inte nyttan eller meningen med hela investeringen.

Och hela meningen med det vi gör är ju att det ska bli nytta, nytta och ändamålsenligt!

Workshop som metod: alternativen

I ett tidigare inlägg har jag smutskastat workshopen som verktyg. Syftet nu är att följa upp med alternativen.

Workshopen används vanligen i tre olika syften – för att definiera och avgränsa systemet; för att specificera innehåll och funkationalitet; eller som ett rent PR-verktyg.

Definiera och avgränsa systemet
Här handlar det om flera nivåer, där jag tänker beröra två av dem – konceptuellt/övergripande samt systemtekniskt/specifikt.

Med konceptuellt avser jag den typ av avgränsning som görs i och med att man definierar mål och syfte. Nyckelkunskap här är verksamhetens -

• Kärnverksamhet
• Kultur
• Förhållande till omvärlden
• Mål och strategier

Problemet med workshop i detta läge är att de olika verksamhetsrepresentanterna gärna undviker att visa interna konflikter och sprickor – man vill ge en enad bild till den inhyrda konsulten. För att undvika det brukar jag be att få allt material de har, hur irrelevant eller perifert uppdragsgivaren än anser att det är. Detta kompletteras med intervjuer med representanter för de olika verksamheterna, inklusive verkställande ledning. Intervjuerna är konfidentiella och dokumenteras för eget bruk men lämnas inte ut till uppdragsgivaren. Tillvägagångssättet innebär att konflikter och skilda uppfattningar synliggörs utan att de inblandade behöver hamna i en konfliktsituation, och kunskapen om vilka konfliktpunkterna är är till stor hjälp när man ska ta fram själva systemdesignen.

Andra bra verktyg är att intervjua användare, göra användningstester på befintliga system, ta en promenad genom korridorerna/besök en produktionsanläggning (eller två), och fokusgrupper med användare. Allt med syfte att förstå verksamhet och kultur.

Med specifik definiering och avgränsning menar jag den fas då man fastställer det faktiska systemets omfattning, matchat mot specifika mål och syften. Här är en av de få tillfällen då det är viktigt att vara överens om vad vill man uppnå och med vilka medel. Men inte heller här är workshopen att föredra. Istället bör utföraren presentera förslag som sedan diskuteras, och där de slutgiltiga besluten fattas av uppdragsgivarens ledning. Skälen till det är två – dels är det ytterst sällan en projektgrupp har mandat att fatta denna typ av beslut – det ligger istället hos verksamhetsledningen, dels för att konsulten då kan fungera som extern måltavla för interna konflikter och eventuellt kontroversiella förslag.
Den konsult som underskattar de politiska kvaliteterna kommer inte bara missa måltavlan – man riskerar att skjuta sej själv. Vilket måste betraktas som icke önskvärt.

Specificera innehåll och funktionalitet
Även här handlar det om flera nivåer. I vissa fall måste man genomföra utredningar, exempelvis avseende roller och rättigheter, eller avseende migrering (eller inte) av befintligt innehåll – vad ska med, hur ser databaserna ut… och utredningarna består huvudsakligen i att kartlägga fakta och om att intervjua rätt personer, samt om att sätta ihop ett beslutsunderlag.
Alltså inte läge för workshop, om man vill ha resultat.

I andra fall handlar det om namngivning, hierarkier och flöden. Här är vi inne på frågor som bäst hanteras med interaktionsdesign och användningstester; jobbar man här med samförståndsprincipen, och hoppas att användarna ska jämka/hitta lösningar åt en, är man mer eller mindre dömd att misslyckas och som en konsekvens går workhop bort.
(Det är lite snett vid sidan om, men i sammanhanget kan man inte nog understryka vikten av att inte speca innehåll och funktionalitet utan att ha bra koll på mål, syften och kultur /förutom de klassiska sakerna som användningssituationer och scenarios/.)

PR-verktyg
För det första bör man fråga sig varför man behöver göra PR för det nya eller förändrade systemet. Är det för att man är angelägen om att ha användarna med sig? Då finns det andra sätt, exempelvis att kontinuerligt arbeta med användningstester under själva specnings- och utvecklings-/konfigureringsfaserna. På så sätt får användarna konkret vara med och påverka saker som ordval, flöden och liknande.

Är det för att man vill sprida kännedom om att saker är på gång? Då spelar man falskt om man informerar bakom masken av en workshop eftersom man då förespeglar användarna att de får möjlighet att påverka. Vill man bara sprida vetskap finns det många andra verktyg att tillgå. Vilka man väljer är i första hand ett val relevanta informations- eller marknadsavdelningar får hantera.
Workshop går i alla fall bort.

Jag har avsiktligt hållit detta på en övergripande nivå, och utan att gå in på leverabler – ska man gå in på detaljer blir det boklängd på det hela och detta är ett blogginlägg som redan överskridit gränsen. Trots det hoppas jag att jag gett en provkarta på metoder och verktyg som är mer relevanta än workshopen.

Finns det då tillfällen när workshopen kan vara relevant? Det är en fråga jag själv ställt mej, och jag har för avsikt att återkomma i frågan.

Workshop som metod: bedrägeri på hög nivå

Jag har länge varit allergisk mot användandet av workshoppar. Många undrar varför, det är en vedertagen metod inom IT-branschen, och många kunder förutsätter att man ska använda den – ”vi har sagt att vi ska bjuda in till workshopar, när kan vi ha den första” är en inte helt ovanlig fråga.

Workshoparna kommer också som en naturlig del i exempelvis metoden MSF Agile for Sharepoint, från Microsoft, och är en given grundkomponent i praktiskt taget alla arbeten som görs av verksamhetskonsulter på IT-bolag.

Workshop betyder, fritt översatt, arbetsmöte. Jag har inget emot arbetsmöten. Men vanligen avses med workshop en alldeles särskild typ av arbetsmöte där deltagarna under ganska strikt ledning flyttar gula lappar (eller motsvarande). Workshopledaren leder, definierar och avgränsar arbetet, deltagarna bidrar inom de avgränsade ramarna.

Vad är då felet?

Metoden används för att fånga krav, sägs det. Ett sätt att kartlägga och tillgodose användarnas och verksamhetens behov. Genom att låta en grupp användar- eller beställarerepresentanter få bestämma vad som ska gälla för applikationen, eller vad det nu är, hoppas man att IT-systemet ska göra det man vill att det ska göra. Och man gör det med målet att man på arbetsmötet tillsammans ska nå samförstånd.

Redan nu tror jag de flesta höra själva hur fel det låter, men jag ska ändå vara tydlig -

Oavsett om det gäller målsättning och avgränsning, innehåll och struktur på övergripande eller detaljerad nivå, eller ren PR-verksamhet, handlar konsulten oansvarigt om man oreflekterat använder workshoppen som metod eftersom man med detta överlåter en stor del av arbetet på kunden, samtidigt som man låtsas att man tillvaratar kundens intressen.

I verkligheten har extremt få användare och beställare tillräckligt god uppfattning om exakt hur och vad som ska göras – enligt exempelvis Erik Fors-Andrée är det till och med en risksignal om kunden tror de vet exakt vad som ska göras – och extremt få användare har en bra uppfattning om vilka arbetsredskap de skulle ha nytta av eller hur de skulle se ut. De är experter på att UTFÖRA sitt jobb, men inte alltid på att analysera det i termer av IT-system eller i relation till företagets totala verksamhet, strategier och kultur.

Man lever då också med den falska bilden att införandet av nya system kan göras i en anda av samförstånd när det i verkligheten undantagslöst är så att det finns gott om folk i organisationen som har investerat åtskilligt i tid, pengar och personligt rykte i de befintliga arbetssätten, IT-stödda eller inte, samtidigt som det inte sällan finns motsättningar mellan vad de anställda vill och vad ledningen vill.
Och då har jag ändå inte nämnt alla de högljudda särintressen som genom sina specialiserade utbildningar tror sej vara mer lämpade än alla andra att tala om för folk vad de behöver…

Att då lägga över ansvaret på kunden och kundens medarbetare är inte bara oförsvarbart – det är bedrägeri. Ett fegt bedrägeri.

I bästa fall är konsulten/utföraren omedveten om att det finns bättre metoder. IT-branschen är trots allt fortfarande tekniktung och workshoppen är ett beprövat ingenjörsmässigt verktyg, det vill säga verkar logiskt och som sunt förnuft.
Sunt förnuft har lurat den bäste, många gånger.

I sämsta fall används den mot bättre vetande, eller för att det känns så himla bra att komma ut från en workshop och känna att det finns samförstånd. Många är bara riktigt nöjda om de känner att alla är överens när de kommer ut från ett möte och workshopen är en enda lång orgie i att hamna på samma sida bordet.

Hur det än ligger till, om det är självbedrägeri eller uppsåtligt, så är workshopmetoden inte ett ändamålsenligt tillvägagångssätt varesej syftet är att definiera övergripande omfattning, att ta fram en specifik detaljdesign eller att förankra i en organisation.

Resultatet är bara halvdana kompromisser och undermåliga beslutsunderlag och det är en etiskt motbjudande metod av två skäl – man lurar kunden att göra jobbet, och man gör fel jobb med fel verktyg.

Dags att öppna verktygslådan och se efter vilka alternativen är, den som vågar.

Ja, jag kan höra er – ”Varför presenterar du inga alternativ NU? Det är så lätt att klaga och så svårt att vara konstruktiv, jäkla nej-sägare (”/&%%##/())”. Lugn. Uppföljaren kommer handla om det ;D
Jag bara håller tummarna för att det inte dröjer – det är fullt upp, för tillfället…

När du gör intervjuer: råd

Steve Bay, Red Square, har skrivit en artikel med tips om vad man bör tänka på när man genomför intervjuer.
Min enda kommentar är – jag kunde inte ha sagt det bättre själv
Eller, det kunde jag ju, för jag kunde ha skrivit på svenska, men detta är gott nog.

Håll till godo.