Inceptives blogg

GEIGE - Good Enough Is Good Enough

Inceptive — Mon, 28 May 2012 18:13:25 +0000

More is More

En av världens mest omtalade gitarrhjälte genom tiderna är svensk. Yngwie Malmsteen är arketypen för en Rockstjärna med stort R. Utanför den stora villan i Miami, radar han upp sin samling av Ferraribilar och givetvis samlar han på Rolexklockor. Senaste uppgiften är att han har mer än 517 Rolexklockor.

“I didn’t just want to play it safe…people kept on telling me to slow down, like: “Hey slow down… remember that less is more!” …but how can that be? How can less be more?!! It's impossible! More is more”

Yngwie J. Malmsteen

Yngwie inspireras av klassiska kompositörer som Paganini och Bach och har alltid kopierat duktiga gitarrister för att utveckla sin egen teknik. Han har en grym drivkraft att hela tiden bli bättre inom sitt område. I hans tolkning av världen, att ”more is more” driver honom hela tiden att förbättra sig genom att bli snabbare, mer virtous och mer komplett som gitarrist. Det är intressant att Yngwie är som störst i länder som Japan som har en kulturell fascination för teknisk perfektion. Allt japanerna gör drivs av en strävan efter perfektion, förbättring och fokuserat mästerskap.  Det gäller att inte rädas det som är svårt och stort och omfattande. Att inse att man kanske måste ägna hela livet åt fokuserad och medveten förbättring för att kunna uppnå mästerskap. I det sammanhanget är ”more is more” en passande devis.

More is less

Barry Schwartz är professor i Social Theory and Social Action vid Swarthmore College. I en av sina senaste böcker ifrågasätter han det klassiska antagandet att ett större utbud och ökad valfrihet ger ett bättre liv.  Den traditionella konsekvenskedjan är enligt följande:  maximerat antal möjliga val→maximerad frihet→maximerad välfärd→”ett bättre liv”.  Enligt denna logik innebär det att om man kan välja från ett större utbud, så upplever man större frihet och därmed en ökad välfärd.

Men Schwarts argumenterar för att en medveten begränsning av antalet valmöjlighet faktiskt kan minska stress, förvirring och ångest över att man borde valt något annat. Det stora antalet val gör att man i varje stund har så många möjligheter att man inte är närvarande och nöjd med det man har; ”allt ser så fantastiskt ut, det är bara en tidsfråga innan man blir missnöjd”.  I dag har ansvaret för produkten flyttat över från tillverkaren till konsumenten, eftersom om man köper en telefon som man inte gillar eller som inte fungerar perfekt, kan man skylla på den dåliga produkten, men egentligen är det vårt eget fel att vi inte valde något annat. De flesta har svårt att hantera dagens enorma utbud av alla produktvarianter och vi tvingas lägga ner mer och mer tid på att jämföra produkter och att gå igenom val- och beslutsprocesser. Den enorma stress det innebär gör att friheten inte upplevs som frihet och vi njuter inte av välfärden, utan oroar oss för att vi ”valt fel”.  Det är lätt att glida över till vårt svenska ordspråk, att ”man ser inte skogen för alla träd”.  Barry Schwartz sätter ljuset på ett flertal antaganden och konstaterar att för individen kan MORE vara LESS; More is Less.

Less is More

Arkitekten Ludwig Mies van der Rohe var en av pionjärerna inom den moderna arkitekturen. Han var inspirerad av dikten om Andrea del Sarto, ”The Faultless Painter”, av Robert Browning från 1855, där frasen ”less is more” utgör en nyckelfras. Mies strävade efter att skapa en arkitektur med minimal struktur för att ge plats för öppna ytor med mycket rymd och ljus. Han reducerade antalet detaljer för att förhöja helhetsintrycket och skapa en enkel och direkt upplevelse utan att en massa plottriga detaljer. Han ansåg att ”God is in the details”, vilket innebar att han propagerade för att välja detaljerna med omsorg, och att endast välja ut de som bäst representerade själva tanken med helheten.

Less is Less

”Less is Less” kan i min världsbild av arbete med krav i projekt och organisationer, associeras med en förbannad intressent som inte fått det han ville ha, eller det som han trodde att han ville ha.

Känslan av ”less is less” är obehaglig; som att bli lurad på konfekten, som att sitta och lyssna på en ”rolig historia” som inte har en rolig poäng. Vi kan uppleva det när projekt omprioriterats och kapats i ändarna så till den grad att ingen nytta blev kvar. Eller när bombastiska prototyper lovat fantastiska features i lyxförpackning, och leveransen sedan har mindre innehåll, är fulare och inte alls ger någon känsla av förbättring.

GEIGE!

I mitten av båda axlarnas Less och More, har vi en skärningspunkt. Alla uttryck ovan kan i sitt sammanhang och med förståelse av respektive situation och kontext, ha sitt berättigande och kännas naturliga. Men vad vi egentligen bör stäva efter är givetvis en kombination av alla fyra!. Yngwies passion och glädjefulla virtuositet, Barry Schwartz insikter om paradoxala följdeffekter, Mies tydliga och förädlade renhet samt behovet av ett riktigt innehåll som ger nytta, kan alla sammanfattas till: Good Enough is Good Enough!  Genom att tänka på alla riktningarna samtidigt kan vi hitta ett lagom, som inte lämnar någon riktning besviken.

Se Yngwie-klippet här.

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering 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.

Om du inte kan "talk the talk", så kan du inte heller "walk the talk"

Inceptive — Wed, 16 May 2012 08:01:59 +0000

Häromkvällen råkade jag se en del av ett avsnitt av "Gränsbevakarna Australien". Det är ett program med dokumentär prägel som följer ett antal personer som jobbar på gränskontrollen till Australien.

Om man tänker efter så är formatet ganska intressant. Gränskontrollen fungerar som ett "interface" mellan landet Australien och övriga världen. Resande har en given drivkraft: att komma in i landet. Kontrollanternas uppgift är att se till att de som reser in i landet inte tar med sig objekt in i landet som någon typ av regelverk har definierat som "förbjudna".

I många fall i TV-serien rör det sig om olagliga droger och in- eller utsmuggling av växter och djur. Givetvis med en referens till hur många års fängelse smugglarna sedan dömdes till i domstol (detta är troligtvis en av TV-programmets bakomliggande drivkrafter och sponsoricitament: att öka medvetenheten om hur lätt smugglarna blir upptäckta av de ytterst professionella gränskontrollanternas metodiska arbete och hur avskräckande långa fängelsestraff som blir påföljden av en enskild förseelse).

Mer intressant blir det när man även visar de mindre förseelserna som ofta orsakas av okunskap eller olika syn på "samma sak". I programmet porträtterades bland annat en kinesisk student som ämnade resa in i Australien på två veckors semester. Gränsbevakarna öppnade hans väska och hittade pulverte och torkade blad. När man reser in i landet måste man fylla i ett omfattande formulär och på en av punkterna hade studenten fyllt i att han inte hade MAT i sitt bagage. Definitionen av MAT hos gränskontrollanterna var något i stil med: "allt som man kan stoppa i munnen och som ger energi". Studenten hävdade att det bara var "te och löv till dekokt". Men enligt regelboken räknades således även te och dekokter till rubriken "mat". Att definitition av "mat" skiljer sig åt mellan olika länder och olika kulturer, blev studenten pinsamt medveten om genom en bot på 230 Australian Dollars.

Det var ingen idé att försöka argumentera mot den rådande definitionen av "mat", eftersom interfacets protokoll (regelboken för gränspoliserna) bestämmer hur ett acceptabelt inkommande meddelande skall se ut (vad resenärerna får ha med sig eller inte).

I fallet med gränskontrollen, är det tydligt att definitionen av de enskilda begreppen måste hänga ihop med den övergripande visionen av hela arbetet. Varför gör man kontroller vid gränsen över huvudtaget? Hur ser världen ut, för att gränskontroller ska fylla en viktig funktion?

Om inte de detaljerade begreppen, definitionerna och "reglerna" är i harmoni med den övergripande intentionen, kommer vi aldrig få ett bra resultat av det arbete vi gör där dessa används.

Ett annat exempel är vad man menar med att man "låser sin cykel". Alla personerna nedan kommer att kunna använda sig av frasen "jag har låst cykeln", men med delvis olika extension (betydelse i verkligheten).

Intensionsdomänerna för frasen "att låsa cykeln" för tre olika personer: A: {"låsa bakhjul till ram"} B: {"låsa bakhjul till ram", "låsa framhjul till ram", "låsa sadel till ram", "låsa ramen till externt föremål" } C: {"låsa bakhjul till ram", "låsa framhjul till ram", "låsa framhjul till externt föremål"}

Tänk dig att du träffar din VD utanför huvudkontoret när han precis ska parkera sin nya 25 000 kronorscykel . Ett viktigt telefonsamtal gör att han ber dig att låsa cykeln åt honom. I det fallet skulle jag gärna vilja veta mer om vad som ligger i hans koncept "låsa cykeln". Speciellt som det är fullt möjligt att jag "låser" den, för att några timmar senare inse att den blivit stulen. Om det visar sig att den försvunnit på grund av att jag inte låste fast den "på rätt sätt", är jag då ansvarig för stölden eller är jag ansvarig för att ha en annan tolknings- och definitionsmodell?

Kan vi någonsin känna oss säkra på något utan att på riktigt definiera och representera vad vi egentligen menar?

Om en person nickar medhållande när du pratar, vet du då att han nickar till samma insikt som du har? Ställ en kontrollfråga och se efter.

Om författaren

Kvalitetskraven regerar i kravlandet

Inceptive — Tue, 08 May 2012 13:02:09 +0000

Produkter och tjänster som erbjuds nuförtiden har i stort sett samma typ av funktioner. Alla mobiltelefoner har en inbyggd kamera, alla surfplattor har touchscreen, de flesta bilar har krockkuddar och AirCondition. Även om de flesta företag letar efter en så kallad ”killer application” (enligt KANO-modellen en ”Delight” eller ”excitement feature”1) handlar det oftast om en linjär förbättring av redan existerande funktioner. Att göra en kamera med ett större antal pixlar än tidigare (funktionen finns redan men har en sämre KVALITET) eller en skärm med bättre upplösning. Vi är vana vid att de stora företagen kopierar varandra, så att även om en produkt faktiskt erbjuder en helt ny funktion, så kan vi vara ganska säkra på att det märke som man själv har, snart kommer med en uppdaterad version med samma funktion, eller i varje fall en variant av densamma. Funktionerna styr således ofta inte primärt vårt agerande, utan den starkaste drivkraften är HUR BRA kvalitet de existerande funktionerna uppvisar, vilka kvalitetsattribut som produkten eller tjänsten erbjuder. Beskrivningar av dessa egenskaper är vad vi kallar kvalitetskrav.

Många tror att kvalitetskrav handlar om exakta mätetal med massor av decimaler eller konstiga enheter, men ofta handlar det om att förstå innebörden av en mängd kvalitetskrav och hur de uppfattas av olika typer av användare. Om exempelvis en processor kan virtualisera en del av sina kärnfunktioner och därmed utför ett benchmark-test några millisekunder snabbare än den tidigare versionen av processorn, betyder oftast inte själva siffran någonting för mig som person. Däremot är abstraktionen och den förenklade ”förklaringen” av att processorn (i detta exempel en INTEL multicore i7-processor) utför ”virtualisering och är snabbare” tillräckligt för de flesta.
Därför är det förvånande att Apple med sin nya iPad, har tillåtit en viktökning och en ökad tjocklek, i ett produktsegment där de linjära kvalitetsegenskaperna är ”livsavgörande”. För trots den fantastiska nya skärmen, kommer folk i allmänhet att prata om att den nya produkten var tyngre och tjockare. Trots att det rör sig om ett fåtal gram och några få millimeter (troligtvis inte ens märkbart), har man gett kunden möjlighet att verbalisera ett ”kvalitetsmissnöje”.

Men när det gäller Apple, så vet de troligtvis exakt vad de vill med detta och har planerat hur de taktiskt VÄLJER att låta vissa basala kvalitetskrav stå tillbaka för att fokusera på ett par features där skärmen och begreppet ”retina display” kanske till och med lyfts fram till att bli en DELIGHT2.
Den viktigaste faktorn i valet av vilka kvalitetskravsförbättringar som skall prioritieras, är att man har riktig koll på alla intressenter och användargrupperingar.

Även om man är ensam herre på täppan och bestämmer helt och hållet själv, är prioriteringen mellan olika kvalitetskrav inte helt enkel. Speciellt när ett önskat kvalitetsattribut innebär att även vissa funktionella krav kommer att påverkas.

Låt mig berätta om ett enkelt exempel på hur mina kvalitetskrav påverkade tidigare fungerande funktionella egenskaper, och hur jag, trots förlusten av en funktion, ändå blev nöjd med kvalitetskraven och hela projektet.

Det handlar om min ombyggnation av en gammal traditionell cykel till en ”avskalad fixed-gear3-skönhet”.

Lädersadel, läderhandtag, läderclips och läderklätt kedjeskydd. Smala men ”höga” metallfälgar och tätt metallfärgade stänkskärmar som nästan smeker tätt längs däcket. Adjektiv och nomen som beskriver egenskaper och upplevelserelaterade kvalitetskrav. Givetvis måste även hjulen snurra, sadeln vara höj- och sänkbar, kedjan skall kunna sträckas och cykeln låsas. Men utseendet var och är av avgörande betydelse. Det är en ”fix idé”.

Resultatet av min kravspecifikation blev enligt nedan.

Men när jag efter premiärturen skulle låsa cykeln, visade det sig att den höga fälgen (utseendedrivet kvalitetskrav) gjorde att det inte gick låsa cykeln (det funktionella kravet kunde inte uppfyllas).
Jag blev häpen, och min skadeglada kompis skrattade högt, och ni kan se bilden nedan.

Vad blev min reaktion?
Efter några sekunder av uppgivet skratt så accepterade jag faktum och insåg att jag numera får låsa cykeln med det medhavda vajerlåset både genom framhjulet OCH bakhjulet. Dessutom kan jag såga av även låskolven från ramen och göra den ännu mer avskalad, vilket leder till ett renare formuttryck, som i sin tur framhäver läderdetaljerna ännu mer…

Min poäng är att det är enkelt att beskriva en hel hög av ”otroligt viktiga” funktionella krav, men när de sätts ur spel av ett ÄNNU VIKTIGARE kvalitetskrav, så inser man ofta att man drivit det funktionella kravet alldeles för långt och gjort det alltför detaljerat.
Cykeln skall givetvis kunna låsas (eftersom som jag inser och accepterar det faktum, eller assumption, att det finns personer som faktiskt kan tänka sig att lägga beslag på cykeln även om de inte äger den). Men HUR jag låser den, att det specifikt måste vara den ”naturliga designlösningen” med det existerande ramlåset, är ju ett designval. Det finns uppenbarligen flera sätt att låsa cykeln på.

Ofta gör kvalitetskraven att man får upp ögonen för vad som egentligen är viktigt med de funktionella kraven som man beskrivit. Man kanske kommer till insikt om att den detaljerade funktionen faktiskt kan realiseras genom en helt annan design och att det till och med ”gynnar helheten” och i slutändan ger en nöjdare kund. Och en sexigare cykel?

(1) KANO-modellen är en viktig del av IREB® CPRE (International Requirements Engineering Board, Certified Professional for Requirements Engineering) och är en kraftfull metod för att visualisera karakteristiska produktegenskaper och identifiera olika typer av kundbehov samt vilka funktioner och kvalitetsaspekter som användare och kunder anser vara viktiga.

(2) Däremot kan man knappast räkna den förbättrade kameran eller 4G som Delight, eftersom även den uppdaterade kameran är klart sämre än andra mobiler och surfplattors kvalitet och 4G fungerar endast i vissa mobilnät i Kanada och USA. Sen kan man givetvis undra om Steve Jobs skulle ha godkänt denna strategi, jag kan nästan se hur han skulle skälla ut och kanske avskeda folk för att ha ökat vikten med 1 gram!

(3) Fixed gear innebär att man endast har en växel och att hjulet rullar framåt om man trampar framåt och bakåt om man trampar bakåt. Hjulet och vevarmen har en direkt koppling och de flesta som cyklar fixed gear uttrycke en känsla av att ”vara ett med cykeln”. Fixed gear saknar således traditionellt frinav med broms. Bromsning kan ske med handbroms, genom att ”trampa emot” (dvs. hålla igen trampornas fart genom att trampa saktare) eller genom skidding, då man sladdar genom att luta sig frm mot styret och sträcka på benen och låser vevarmen och därmed stannar hjulet.

Om författaren

Om Beatles, Picasso och IT-projekt

Inceptive — Mon, 07 May 2012 08:38:19 +0000

Vad gjorde Beatles, Rolling Stones och U2 till världsartister? De är och var alla duktiga musiker men rent tekniskt så är säkert många amatörer vassare på gitarr, klaviatur och trummor. Varför räknas Picasso till en av vår tids största konstnärer och varför går hans verk under klubban för miljontals kronor? Även om Picasso var skicklig med penseln så är han mest känd för sina tekniskt sett enklare kubistiska målningar. Samtidigt finns det konstnärer som målar med en närmast fotografisk precision och som inte ens kan överleva på sin konst. Rickard Sjölander har aldrig platsat i ett allsvenskt fotbollslag, ändå är han bäst i Sverige på att trixa med boll, bättre än alla allsvenska spelare.

Den gemensamma nämnaren i de här exemplen är att när man når en tillräckligt hög nivå så är det inte den tekniska kvaliteten som är avgörande. Beatles, Stones och Picasso producerade musik och konst av klass, inte för att de var tekniskt fulländade, utan för att de hade visioner, kreativitet och var tillräckligt tekniskt duktiga för att leverera på den visionen.

Detsamma gäller för mjukvara. För att bygga bra mjukvara och för att ett mjukvaruprojekt ska bli framgångsrikt behövs förstås bra programmerare. Men projekt misslyckas i regel inte för att dess programmerare inte håller måttet. Faktum är att programmerare nästan alltid är tillräckligt bra. Inte så konstigt, med tanke på att man oftast blir professionell programmerare för att man tidigt brinner för programmering och antagligen också har fallenhet för det. Detsamma kan man inte säga om andra roller i mjukvaruprojekt. Vem drömmer om att bli kravingenjör eller testare när man är liten?

Projekt misslyckas för att de inte levererar mjukvara som tillmötesgår verksamhetens behov och löser deras problem. Världens bästa programmeringsteam kan inte ensam lösa den uppgiften. Vill man få mest utväxling i kvalitet per investerad krona så ska man investera dem inom krav- och testområdet. Kostnaden för att skapa förståelse för vad som verkligen skall göras, analysera och representera behov, önskemål och idéer, är alltid mindre än den totala kostnaden för att arbeta med en oklar, tvetydig och ofta motsägelsefull kravbild.

Om författaren

Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.

Hur gör du när du pusslar?

Inceptive — Wed, 25 Apr 2012 10:41:03 +0000

Vi slår oss ofta för bröstet och är stolta över den svenska platta organisationen och frånvaron av intrikata och sammanvävda hierarkiska strukturer. Visst har vi lager av politiskt rävspel, strategiska dimmridåer, skvaller och "kniven i ryggen" och rädsla för förändring...men vi har i varje fall inte organiserat oss för att skapa det.

Men vi har en övertro på processer och effektivitet, vilket ofta leder till att kreativiteten och tänkandet "utanför lådan" blir lidande: ju snabbare man kör bilen, desto mer tunnelseende...

Att pussla är en manuell kreativ process som ofta följer ett visst mönster. Försök pussla ett pussel utan att känna till bilden på pussellådan. Har du någonsin köpt ett second hand-pussel i plastpåse utan översiktsbild, så rekommenderar jag upplevelsen. Du känner inte till motivet och vet inte om alla bitarna tillhör samma pussel eller om alla bitarna finns med. Det kan till och med finnas dubletter. Har du varit med om projekt som startas utan tydlig projektvision, utan vetskap om alla nödvändiga resurser existerar?

Googles famösa 70-20-10 princip innebär att 20% av arbetstiden ägnas åt nytänkande i relation till aktuella projekt (de övriga 70 procenten) och 10% hänges åt kreativa vidgande tankar fria från projektbojor och strategiska begränsningar.

Det handlar om att kunna pussla även om alla bitar är helt svarta, eller kanske inse att man faktiskt kan pussla ett runt eller oregelbundet pussel som saknar vanliga kantbitar. Eller kanske kröka det platta pusslet till att skapa en tredje dimension, att pussla en boll eller en kub. Det gäller att inse begränsningar i vardagens aktiviteter och processer baserade på "det som vi alltid gjort". När man pusslar kan man tillåta sig att strunta i ramarna och plocka ut och fokusera på en mängd av bitar som har likande färg eller mönster, vilket indikerar att de kanske hänger ihop, och pussla ihop öar av bitar i en slags kreativ frenesi.

Jag brukar inte tvinga mig själv att börja pussla hela ramen med alla kantbitarna, men jag brukar däremot separera alla kantbitarna från de övriga bitarna och speciellt identifiera de fyra hörnbitarna, de som på ett traditionellt rektangulärt pussel har två helt raka sidor. Genom att kontrollera och placera ut de fyra hörnbitarna kan jag låta kreativiteten flöda i resten av bygget: varje ny mängd av ihopsatta bitar placeras ut i relation till dessa hörnbitarna i enlighet med motivöversikten.

På samma sätt kan man se att projektet har sina "hörnbitar" som strategiskt kan placeras ut enligt den aktuella projektvisionen, för att sedan tillåta iterationer av kreativt passionerat pusslande av delmängder av helheten.

För att skapa denna kreativa miljö, måste man se till att de fyra hörnbitarna är verkliga bitar som tillhör pusslet, att de är "certifierade hörnbitar" helt enkelt!

iSQI (International Software Quality Institute) erbjuder fyra pusselbitar som du kan använda som hörnbitar i ditt projekt. Testcertifieringen ISTQB kombineras med kravcertifieringen IREB (Certified Professional for Requirements Engineering) och tillsammans med en fördjupningsmodul och en dos praktisk erfarenhet, så kan du bygga ihop en otroligt stark certifiering: QAMP - Quality Assurance Management Professional. Fyra riktiga hörnbitar som gör att du kan njuta av ett kreativt projekt, flexibelt med oändliga möjligheter.

Certified Professional for Requirements Engineering (CPRE) är en viktig hörnbit i ett utmanande projektpussel. Har man inte har dokumenterat/representerat, förstått eller kan kommunicera VAD en produkt/tjänst skall göra, kan man inte heller bygga den eller tro att den kommer att bli en succé. Professionella krav är basen för effektiva test och smarta strategiska val för att skapa en produkt som levererar riktig nytta och en verklig effekt!

REFERENSER och LÄNKAR

QAMP = Quality Assurance Management Professional

IREB CPRE = Certified Professional for Requirements Engineering
IREB = International Requirements Engineering Board

ISTQB CTFL = Certified Tester - Foundation Level
ISQTB = International Software Testing Qualifications

iSQI-CAT = Certified Agile Tester
iSQI = International Software Quality Institute

ECQA-CIM = Certified Innovation Manager
ECQA = The European Certification and Qualification Association

iSQI-CPPM = Certified Professional for Project Management

iSAQB-CPSA = Certified Professional for Software Architecture
iSAQB® = International Software Architecture Qualification Board

ISSECO-CPSSE = Certified Professional for Secure Software Engineering
ISSECO = International Secure Software Engineering Council

iNTCCM-CPCM = Certified Professional for Configuration Management
iNTCCM = international Certification of Configuration Management association

Om författaren

Från risk till design

Inceptive — Tue, 17 Apr 2012 08:36:01 +0000

Risker finns överallt! En del av dem gömmer sig i specifikationer och dokumentation inom ett projekt. Jag pratar här om otydligheter som göms i odefinierade begrepp och i textuella strukturer som ser bra ut på ytan, men som vid en närmare betraktelse visar sig dölja antaganden och halvsanningar1.

Låt oss titta på ett litet konstruerat exempel.

Situationen är den att du hittar följande fras i den tekniska specifikationen för en ny filminspelningsprodukt:

Nu hajar varje kravingenjör till och kan inte sitta still och vara tyst, eller hur?
Frasen ovan känns som en ”brasklapp”, en friskrivning som glidit med i specifikationen utan att tas om hand på ett korrekt sätt. NÅGON är tydligen oroad över outtalade och troligtvis krockande antaganden (Assumptions). Temperaturbegränsningarna på strömförsörjningsenheten (”The battery pack”, ännu ett antagande!) och den faktiska miljön som kameran kommer att användas i (System Context)2.

Om vi samlar in ”the Assumption Sheep” och ”put a fence around them” d.v.s. identifierar alla antaganden, synliggör dem och formulerar dem, så angriper vi de gömda riskerna på ett effektivt sätt.

Vissa antaganden kanske borde verifieras men framförallt måste vi adressera dem så att de inte fastnar gömda i en specifikation.
Ett alternativ är att skriva ett antal varningar i användarmanualen. Men handen på hjärtat, vem läser manualer numera? Dessutom lär inte användarna bli speciellt glada om produkten inte fungerar när de väl behöver den, och varningarna i manualen hjälper föga i stunden. Missnöjda kunder!

Ett bättre sätt är att skapa verksamhets-KRAV som fångar in riskerna.
Vi kastar ihop en enkel kravtext3:

Verksamhetskravet är skapat efter insikt om den verkliga användningen av produkten i dess rätta miljö med de tänkta användarna.

Tillsammans med de explicita antagandena leder verksamhetskravet troligtvis till en ny design.

Förslag på nya sätt att tänka är exempelvis:

1. designa helt nya batterier som tål kyla
2. förbättrad isolering av batteripaketet
3. uppvärmning av batteripaketet
4. annan strömkälla än batterier
5. batterierna bärs innanför käderna och endast kameran utsätts för kylan

Alla nya designidéer kommer givetvis ge upphov till nya antaganden och specifika krav.

Gömda antaganden är potentiella risker för projektet och produkten.
Vi måste förstå användaren och hur och i vilken kontext som produkten kommer att användas.
En bra lösning skrivs inte in i en manual, den designas in i produkten

[1] Inom IREBs certifiering CPRE (Certified Professional for Requirements Engineering) handlar hela kapitel 5 om ”Krav och Naturliga Språk”, vilket gör att du får en helt ny syn på text och naturligt tal.

[2] Ett annat kapitel i CPRE-kursen: ”System & Context Boundaries”

[3] Hur man skriver ett effektivt verksamhetskrav är INTE en del av denna artikel, utan här kastar vi fram en första version av en kravtext utan alla andra kravattribut som Rational, Conditions of Satisfaction etc.

Om författaren

Därför misslyckas IT-projekt

Inceptive — Mon, 16 Apr 2012 10:19:25 +0000

Att diskutera projekt med personer från andra branscher än IT-branschen är många gånger upplyftande och nästan alltid intressant. De blir de ofta förvånade när jag beskriver de problem vi dagligen brottas med och hur förtvivlat svårt det är att driva stora mjukvaruprojekt. Skillnaden ligger i de grundläggande olika förutsättningar man har inom vad vi kan kalla hårda och mjuka vetenskaper.

Egenskaper	Hårda vetenskaper	Mjuka vetenskaper
Kännetecknas av...	förankring i bevisade fysikaliska lagar	outforskade områden som behöver upptäckas
Problem löses genom...	planering, definition och beräkning	hypotes, experiment, test och revidering av hypotes
Exempel är...	att bygga hus, broar och vägar	att komponera symfonier, göra film, utveckla mjukvara

Det är lätt att inse att det inte går att tillämpa samma projektmetoder på både mjuk och hård vetenskap. Ändå är det så man inledningvis gjorde i IT-erans barndom. I brist på egna metoder sneglade man på etablerade branscher som t.ex. byggbranschen. Så länge ett projekt var tillräckligt litet så fungerade det hyggligt eftersom små projekt bara kan ha relativt små problem. Men när man försökte göra på samma sätt för allt större och mer komplexa projekt stötte man omedelbart på svårigheter. Man hade sprungit in i uppskalningsproblemet - roten till allt ont i IT-branschen!

När jag förklarar svårigheterna med stora IT-projekt för byggingenjörer så skakar de oförstående på huvudet. För en byggingenjör är nämligen inte storleken på projektet ett problem i sig, eftersom samma principer och metoder går att tillämpa oavsett om man avser att bygga en villa, ett flerfamiljshus eller en skyskrapa. För en byggingenjör är det bara en linjär skalförändring; förvisso fler människor, större budget, längre byggtid och fler ingående komponenter, men fundamentalt samma angrepssätt.

Det är i princip möjligt att i detalj beskriva ett helt byggprojekt, innan man har tagit det första spadtaget. Inte nog med det, ju mer tid man lägger ner i början på att rita, räkna och planera innan man börjar gräva, spika och gjuta, desto mindre risk kommer projektet att bära. Man har med andra ord det bra förspänt eftersom man kan luta sig tillbaks på en väl fungerande byggprocess och kan fokusera sin ansträngning på innehållet i stället för metoden. Man kan i stället låta teknik- och materialutveckling vara drivande i att skapa större och mer komplexa byggnationer när inte processen är en begränsande faktor.

Intuitivt kan man tro att man kan uppnå samma fördelar i ett IT-projekt men för mjukvaruutveckling har man bara en negativ utväxling av en initial hög detaljeringsgrad. Om man försöker tillämpa samma modell kommer att man mycket snart köra huvudet i väggen. Tyvärr finns det en utbredd och missriktad övertro att om man bara detaljerar, begränsar och planerar ännu mer så kommer nästa projekt att gå bättre. Resultatet blir dessvärre tvärtom. Mjuka vetenskaper i allmänhet och mjukvaruprojekt i synnerhet kan inte tyglas och styras genom planer och detaljer utan måste tillåtas växa fram genom tillämpning av vetenskaplighet och kreativitet. Det är det enda sättet att utveckla framgångsrik mjukvara. Metoder kommer och metoder går, men i grund och botten måste de vara baserade på den vetenskapliga metoden att formulera hypoteser (krav) och genom upprepade experiment (kod) validera (test) och modifiera hypotesens korrekthet (iterativitet).

Om författaren

Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.

Våga släpp kontrollen!

Inceptive — Mon, 09 Apr 2012 18:21:05 +0000

På många sätt är jag STOLT över att jobba inom IT. Om man läser om situationen inom flera företag och institutioner utanför systemutvecklingsdomänen, så inser man lätt att den AGILA revolutionen som vi alla mer eller mindre experimenterar med till vardags i olika typer av projekt, faktiskt adresserar de riktigt svåra frågorna. Inom Systemteorin¹går dessa under namnet "soft". Mjuka frågor som berör helhetssyn, hur vi jobbar tillsammans och hur vi lär oss saker tillsammans och hur man får en hel organisation att skapa fantastisk IT.

Att försöka KONTROLLERA och STYRA allt och alla är matematiskt bevisat en omöjlighet. Och strävar vi efter något som inte går att uppnå, kommer vi lägga energi på fel saker och offra kreativiteten på övervakningens altare.

Von Neumann²visade matematiskt att det inte finns någon formel eller mekanisk process som kan avgöra om en specifik sträng av symboler är logiskt bevisbar eller inte. Med andra ord så säger detta klassiska "Entscheidungsproblem" (Decision Problem) att det inte finns ett systematiskt sätt att i förhand avgöra vad en kodmassa kommer att göra, det enda sättet att få dennna vetskap är att KÖRA koden och se vad som händer.

Så i grunden är det omöjligt att KONTROLLERA sig förbi problemen med "det oförutsedda".

Det innebär att vi ska fokusera på att behålla KREATIVITET och förmågan att anpassa sig till det oförutsedda (i stället för att försöka kontrollera det). Att skikta kunskapen så att vi inte vet och inte behöver bry oss om i detalj HUR den "svarta lådan" löser ett problem. Vi vill istället fokusera på bättre sätt att interagera (feedback!) med den och VAD det är vi verkligen kräver att den ska spotta ur sig.

Scrumteamet utgör en fysisk representation av denna "svarta låda" och begreppet enkapsulering. Denna konstruktion är enligt min mening själva kärnan i det agila angreppssättet.

Och enligt ovan resonemang kan vi dessutom hävda att "rent matematiskt" så ska vi INTE detaljstyra teamen, eftersom den totala kontrollen ändå är omöjlig att uppnå!

Vi måste alla förstå innebörden av detta och värna och skydda teamen mot alla "control freaks" som hävdar att de vill ha total insyn och kontroll.

Däremot kan man göra teamet ännu bättre och mer effektivt genom en bättre förståelse av hur hjärnan fungerar och hur vi förstår saker i grupp. Att BARA prata är ofta grunden till många problem.

Mer om detta i en kommande bloggpost, där jag kommer att prata mer om själva Scrumteamet och om behovet av en utpekad roll som har ansvar för produktkraven och produktion av kunskap- och förståelserelaterade arbetsprodukter (exempelvis visualisering och modeller) som inte direkt är kopplade till slutprodukten och själva koden.

1. Obligatorisk litteratur inom Systemteori är allt av Peter Senge, Peter Checkland och John Poulter

2. I George Dysons bok "Turing's cathedral" kan du läsa mer om Turing och gänget som var med och skapade datorn (och atombomben): logikern Alan Turing, ingenjören Julian Bigelow, entreprenören John von Neumann, visionären/biologen Nils Baricelli och kodgeniet Klari von Neumann.

Om författaren

Kan du skilja på vad och hur?

Inceptive — Wed, 28 Mar 2012 11:36:37 +0000

En av de främsta orsakerna till problematiska projekt med missnöjda kunder är det som kallas ”Scope Creep” – de rörliga kraven, eller den ”dynamiska kravmängden”. Många tror att det beror på att produktkraven inte är tillräckligt tydligt definierade eller att de inte är testbara. Jag vill påstå att roten till problemet ligger tidigare i upptäckskedjan, jag pratar om Business Requirements, de riktiga verksamhetskraven. Om produktkraven inte hänger ihop med verksamhetskraven, spelar det ingen roll hur tydliga, välskrivna och testbara produktkraven är. Som vanligt är det så lätt att rusa fram till tåget som håller på att gå, utan att stanna upp och kontrollera att det verkligen går till den tänkta destinationen.

Första steget är att lära sig skilja på VAD och HUR, och att inse att inom varje HUR så finns det även mer detaljerade VAD som i sin tur kan brytas ner och bli mer specifika HUR. Det är skillnad på den abstrakta beskrivningen av en lösning och den mer detaljerade lösningsbeskrivningen.

Varje VAD innehåller HUR och Varje HUR innehåller VAD…

Att bara se Business Requirements som något ”vagt och luddigt” kryddat med lite syfte, mål och massor av personligt tyckande, är en säker väg till projektkatastrof. Det finns ingen magisk formel som bryter ner otydliga och ofullständiga verksamhetskrav till detaljerade produktkrav*.

Nedan visas en enkel informationsmodell som kan underlätta förståelsen av relationen mellan Business Requirements och Product Requirements kan se ut. Vi pratar om att förstå verksamhetens syfte och mål (Business Objectives) och dess regler (Business Rules). Affärseglerna är en typ av CONSTRAINTS (det finns andra begränsningar som styr lösningsvalet, mer om det i en annan artikel.)
Genom att förstå de VERKLIGA behoven i verksamheten kan man representera verksamhetskraven i verksamhetsanvändarnas eget språk (eventuellt turboladdat med enkla effektiva visualiseringar). När de uppfylls, möts och levereras, tillför de verkligt värde i verksamheten, löser verkliga problem, möter nya utmaningar med kraft och öppnar nya möjligheter. Verksamhetskraven är i grunden konceptuella och måste därför UPPTÄCKAS, KOMMUNICERAS, UPPLEVAS och KREATIVT FRAMLOCKAS, de kan aldrig bara skrivas ner.

Bland alla de möjliga lösningarna (det finns ALLTID flera möjliga lösningar på verksamhetens kravmängd) görs sedan ett aktivt val av de som är bäst lämpade att förstå de verkliga verksamhetskraven och lösningsförslagens möjligheter. Vi pratar om en grupp bestående av kravingenjören, arkitekten och andra relevanta intressenter.
Den valda lösningen kommer sedan att brytas ner, detaljeras, utvecklas och beskrivas både funktionellt (Product Functional Requirements) och med avseende på kvaliteter som själva produkten måste ha och de kvalitetsegenskaper som funktionerna måste uppvisa (Product Quality Requirements).

Produktkraven (både de funktionella och kvalitetsattributen) representeras utifrån produktens perspektiv och ett språk som reflekterar den lösningsdomän vi valt att gå vidare med.
Produktkraven beskriver designen på den aktuella lösningen på en nivå som gör det möjligt att realisera den i ett automatiskt system med en specifik konfiguration, ofta redan beslutad via existerande begränsningar på hela den ursprungliga lösningsmängden.

Det är här den stora risken gömmer sig. Det är så ”enkelt” att tänka på produktkraven som ”de riktiga kraven” och att fokusera enbart på utvecklingen av produkten utan att relatera till verksamhetens verkliga behov. Utan en kontinuerlig återkoppling (VALIDERING), att vi verkligen utvecklar rätt produkt för kundens specifika behov, önskemål och förväntningar, så kommer produktens kravmängd att glida. Ofrånkomligt ont och pinsamt fel.
Så skilj på verksamhetskrav och produktkrav och se till att de hela tiden hänger ihop.

*) Däremot så funkar Rapid Prototyping ofta ganska bra eftersom det är lättare att peka på vad man INTE vill ha än att fundera på VAD man egentligen behöver. Risken är givetvis att man i stunden lockas till onödiga features som man kan få på köpet och som känns spännande i stunden när de presenteras, men som ibland inte har någon egentligen koppling till verksamhetens verkliga behov.

Om författaren

Kartan och Verkligheten - TomTom i Ingenmansland

Inceptive — Mon, 26 Mar 2012 08:29:09 +0000

Jag arrangerar varje år ett Nordiskt MonoSki-möte i Hemsedal. Jag har således åkt mellan Göteborg och Hemsedal ett stort antal gånger och har en ganska bra ”magkänsla” för vart jag ska styra, även kring Oslos förvirrande nybyggnationer. Dessutom brukar jag ha med en utskrift på Softresors textuella färdhänvisning, om jag mot förmodan skulle glömma vägnumren. Nytt för 2012 är min TomTom-navigator. Med alla dessa informationskällar kan det ju inte gå fel, eller?

Jag har funderat på den verkliga nyttan av en GPS. Visst är livet härligt när man kan förbättra verkligheten med lite teknologiskt stöd. Men samtidigt som vi vinner en överlagring av information med en typ av förenklad kartbild, vilket kan göra att vi blir hejare på att komma ihåg gatunamn, så stirrar vi mer och mer på den förenklade representationen av verkligheten, istället för att läsa skyltar, stanna till och fråga levande personer, etc.

Visst kan jag se nyttan av ”augmented reality”, speciellt om man kan köpa till den historiska databasen som ger historiska och kulturella fakta om områden man kör förbi, eller om man kan se på skärmen hur byggnader såg ut för 100 år sen. Men för att fatta beslut och för att nå ett mål, kan den nya informationen vara förvirrande.

På vägen utanför Oslo blev jag minst sagt förvirrad. Enligt navigatorn körde jag offroad långt från asfalterad väg. Min magkänsla sa mig att jag var på rätt väg, men den nya informationen från navigatorn gjorde mig osäker.

Den ökade informationsmängden hjälpte mig inte att bättre förstå situationen jag befann mig i, utan gjorde det snarare SVÅRARE att fatta ett beslut. Till saken hör att jag faktiskt hade laddat ner den senaste uppdateringen innan jag åkte, men de nya vägarna som höll på att byggas var inte med. Det går alltså INTE att enbart förlita sig på en situation där man ”fysiskt” har tillgång till alla informationselement, utan man måste försäkra sig om att de är uppdaterade, att själva innehållet är korrekt och att hanteringen av den nya informationen (uppdatering, kontroll av korrekthet, etc.) blir en del av den naturliga arbetsprocessen. Det gäller att inse och planera för att varje mynt har en baksida - att varje ”fantastiskt och enastående” verktygsstöd även kan påverka oss negativt. Ibland är det viktigt att bara lita på att det kommer att gå bra och att försöka göra det enkelt och simpelt och minska informationsmängden.

Det slutade med att jag stängde av navigatorn och förlitade mig på min erfarenhet och min ökade uppmärksamhet på alla vägskyltar. Jag kom fram i tid.

Om författaren