Otur när man tänkte, eller systematiskt tankefel?

Det är inte bara företag för spårbunden trafik i västsverige som har “otur när man tänker”.

Nu har det franska SJ, SNCF (Société Nationale des Chemins de fer Français) trampat i klaveret genom att beställa 2000 vagnar till regionaltågen TER (Transport Express Regional), som sedan visade sig vara några centimetrar för breda och höga för 1300 av de 9000 tågstationerna i det franska järnvägsnätet.

trains trop larges.jpg

Beställningen landar på circa 15 miljarder Euro. RRF (Réseau Ferré de France) har påbörjat ombyggnationen av 300 stationer vilket redan kostat 80 miljoner Euros. Och mer pengar krävs från respektive region.

Hur kan det gå så fel?

Till skillnad mot komplexa automatiska system är det ganska enkelt att förstå nyttan med satsningen på de ny järnvägsvagnarna. Så både visionen och målen är ganska klara och nöjdhetsvillkoren borde vara lättdefinierade.

Jag tror personligen att vi ser effekterna av ett dåligt strukturerat tänkande inom kravingenjörsarbetet!

hammare_spik.jpg

En trolig grundorsak till dessa häpnadsväckande tankevurpor är ett av mina “hatobjekt #1” inom krav; de så kallade “icke-funktionella kraven”Ordspråket: “Fö

Ordspråket: “För den som bara har en hammare ser alla problem ut som spikar”, träffar mitt i prick! 

Världen är INTE uppdelad i funktioner och ”icke-funktioner”, punkt!

De så kallade ”icke-funktionerna” döljer ofta dolda och oanalyserade funktioner och endast ett fåtal av de krav som kastats i ”the non-functional dustbin” är i verkligheten kvalitetsattribut. Det icke-funktionella tankefelet leder till att personer “glömmer bort” att ställa rätt frågor, och många gånger ligger de så kallade icke-funktionella kraven orörda och hela organisationen fokuserar mest energi på funktionerna, det nya som det (automatiska) systemet är tänkt att kunna utföra.

Men en funktion är inte bättre än dess kvalitetsattribut, och en funktion måste alltid fungera i en specifik situation eller kontext/omgivning. Och den specifika situationen och kontexten måste man givetvis ha fullständig koll på och representera på bästa sätt. Dessutom finns det alltid begränsningsområden i mängden av alla möjliga lösningar till problemen som uppstår i det förändringsarbete med önskan om förbättring, som faktiskt alla projekt innebär. Dessa begränsningsområden omfattar saker man absolut inte får ändra på eller som man i projektet måste följa eller uppnå enligt lagar eller direktiv huggna i sten. Man måste helt enkelt måste förhålla sig till dessa vid arbetet med funktionerna och analysen och designen av hur bra dessa ska fungera (dvs. kvalitetskraven på funktionerna, komponenterna och systemet som helhet)

Genom att strukturera och utforska behoven i Funktionella krav, Kvalitetskrav och Begränsningar (vilket även innefattar verksamhetsregler etc...), så glöms inte de viktiga frågorna bort:

  • Vilken kvalitet ska funktionerna ha?
  • Vad är villkoren för att intressenterna blir nöjda med funktionerna?
  • Vilka yttre begränsningar påverkar ALLA funktionerna och kvalitetsattributen?
  • Hur ser kontexten ut? Vilka saker, personer och roller ingår i den relevanta kontexten?
  • ...

Ett tydligt begränsningskrav i fallet med SNCF borde vara storleken på de 9000 perongerna där tågvagnarna är tänkta att fungera. Det spelar ingen roll om vagnarna har fantastiska funktioner eller till och med förbättrade kvaliteter på redan existerande funktioner om de är för breda för att rulla in på stationen.

Visst är det lätt att vara efterklok och skrika högt när pengarna rullar iväg på dumheter som man borde tänkt på redan från starten.

Men om man har fel tankemodell från början, kanske man inte ska bli varken förvånad eller upprörd.

Bättre då att fylla sin verktygslåda med bättre tankemodeller än bara en hammare!

  1. Förståelsen av skillnaden mellan Funktionella krav, Kvalitetskrav/attribut och Begränsningar (Constraints) är en viktig poäng i IREB CPRE FL- certifieringen (International Requirements Engineering Board  - Certified Professional for Requirements Engineering och i Klaus Pohls 814-sidiga grundbok för certifieringen, ”Requirements Engineering – Fundamentals, Principles and Techniques” från 2010 på Springer förlag.

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravingenjörsskap och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.