Jag har arbetat på Altran sedan februari och relativt snabbt befann jag mig på mitt första uppdrag ute hos kund. Uppdraget innebär vidareutveckling av Sharepoint-applikation. Som ny i branschen är det för mig det perfekta uppdraget då det inte bara kräver kunskaper inom Sharepoint utan även inom tekniker som C#, ASP.NET, Silverlight, JavaScript/HTML/CSS och designmönster. Ständig kompetensutveckling är viktigt och något jag uppskattar med IT-branschen, det dyker alltid upp nya problem som kräver lite tankeverksamhet.

I måndags höll Kompetensfabriken kvällskurs på kontoret som behandlade ämnet sökmotorsoptimering. Målet är toppen på Google men vägen dit är inte självklar. Det jag tar med mig är att med en genomtänkt länk- och innehållsstruktur jobba mot Googles riktlinjer med målet om att bygga en framtidssäkrad webbplats. När webbplatsen väl är sökbar gäller det att behålla besökarna. Bra innehåll, SEO och användbarhet – alla bitarna krävs på plats för att skapa en konkurrenskraftig site. Det hela gav en bra inblick i ämnet och jag ser fram emot fler lärorika träffar.

Slutligen önskar jag alla en trevlig ledighet!

Vikten av att fatta beslut baserat på data och inte på åsikter. Att faktiskt ta reda på vad det är som behöver göras, istället för att utgå ifrån antagande eller gamla meriter. Visst ska man inte underskatta tidigare erfarenheter när man står inför beslutsfattande, men utan att faktiskt ta reda på vad det är som gäller nu så är risken stor att man hamnar på långa omvägar eller inte kommer fram alls. Det här är ett område där det finns mycket att jobba med och förbättra.

Värdet och sidoeffekterna av att jobba i korta iterationer och att kunna leverera snabbt och ofta. Förutom en kort och kraftigt förenklad föreläsning av de vida ekonomiska fördelarna med att leverera snabbt och ofta, så handlade detta huvudsakligen om continuous integration. Vad jag fann mest intressant angående detta var det omvända upplägget som lades fram. Idén var att det snabba arbetssättet framtvingar andra viktiga egenskaper i de system som vi bygger. Typisk så handlar detta om testbarhet och kodkvalitet mm. Utan sådana egenskaper så blir det i längden omöjligt att kontinuerligt leverera snabbt och ofta, så de uppstår som en sidoeffekt. Jag skulle nog säga att det inte riktigt skulle fungera så bra att bara bestämma sig för att börja leverera snabbt och ofta och hoppas på att en massa bra sidoeffekter bara ska trilla in av sig självt. Man får nog lägga en hel del resurser på att nå en grundnivå av dessa egenskaper innan det blir självbärande genom snabba och frekventa leveranser.

På den tekniska sidan så handlade det som fångade mitt intresse mest om byggverktyg för Java. Det börjar finnas rätt gott om sådana nu. Jag hamnade på en föreläsning som huvudsakligen handlade om Maven och Gradle. Innehållet var väldigt objektivt framställt och beskrev ganska vanligt förekommande byggproblematik och lite om möjliga lösningar för dessa. Vad som var roligt var att även Tesla smögs in på ett litet hörn i föreläsningen. Jag skulle inte säga att Tesla är ett eget byggverktyg utan snarast en utökning av Maven, där man försöker komma tillrätta med mycket av den problematik som man kan stöta på i Maven. Efter att ha provat på Tesla lite på egen hand så kan jag säga att det känns ganska lovande. Det ska bli spännande att se om det blir något av det till slut.

int i = 5;
i.toString();

5.getClass();

Om fem år är det dock dags för Java att ta steget in i den rena objektorienterade världen. Detta enligt Oracles egen preliminära roadmap för Java som uttrycker att Java 10 ska släppas år 2017 och att primitiverna då skrotas.

Vad betyder detta rent praktiskt för språket Java? Vilka är för- och nackdelarna med primitiver och varför skapades de från början?
För att svara på dessa frågor måste vi gå tillbaka till 90-talet när Gosling och hans team började utveckla språket Oak som senare blev Java. En av de stora utmaningarna för Oak-teamet var att sprida Java till så många utvecklare som möjligt. Då utvecklarvärlden vid denna tid först och främst bestod av C/C++-utvecklare så var det dessa som man försökte attrahera. Java har därför en rad ”flörtar” med C-världen och primitiverna är just en sådan flört.

Den uppenbara fördelen med primitiver är annars att de är snabbare än objekt. Värdet på en primitiv lagras direkt i stacken i datorns minne vilket ger snabb åtkomst. Ett objekt lagras å andra sidan bara som en referens till objektet i stacken, själva objektet lagras på heapen. För att komma åt objektet läses alltså först objektreferensen från stacken och denna referens används sedan för att hitta objektet på heapen.
För att tydliggöra prestandaskillnaden kan du prova att köra nedanstående kod.

Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++) {
sum += i;
}
System.out.println(sum);

På min hyfsat pigga dator tar detta åtta sekunder.
Byter jag däremot ut klassen ”Long” mot primitiven ”long” på första raden så tar det bara en dryg sekund. En minst sagt markant skillnad.
Ytterligare en fördel är att primitiverna av naturliga skäl inte kräver någon garbage collection.

Över till nackdelarna, den kanske största nackdelen med primitiver är att de, till skillnad från objekt, inte kapslar in implementationen. Ett exempel på detta är char som lagrar ett tecken i 16 bit. Med den ständigt växande Unicode-standarden räcker detta numera inte till för alla tecken men eftersom char avslöjar sin implementation för omvärlden kan inte Java anpassa sig utan att bryta bakåtkompabiliteten. Det går därför inte att lagra alla Unicode-tecken i en char utan det blir ett kompileringsfel istället.

Den mest uppenbara nackdelen är annars att primitiverna inte kan användas någonstans där det krävs ett objekt, du kan exempelvis inte använda primitiver i generics:

List<int> integerList; // Kompileringsfel

För att underlätta, eller komplicera beroende på vem man frågar, så finns det i Java även objekt-varianter av alla primitiver. Exempelvis int finns även som Integer och boolean som Boolean. När Java i samband med Java 5 införde generics så infördes även autoboxing och unboxing, alltså att en primitiv automatiskt omvandlas till objektvarianten och vice versa. För att göra om en primitiv till objekt med Java 1.4 så tvingades man till följande:

int i = 5;
Integer intObject = new Integer(i);

I och med boxing i Java 5 går det istället att skriva:

Integer intObject = 5;

Mycket smidigare och med detta så kan man tycka att allt borde vara frid och fröjd. Använd primitiver om du bryr dig om prestanda och objektvarianterna om du är OO-purist.

Dessvärre har även detta mynt en baksida och det är att Java i många fall beter sig minst sagt besynnerligt i hanteringen av primitiver och objekt. Jag kan garantera att alla Javautvecklare (utom möjligen nämnde Gosling samt hans gamle kompis Joshua Bloch) fallit i någon av följande fällor:


int a = 1000;
int b = 1000;
System.out.println(a == b); //true, inget konstigt med det.

Integer a = 1000;
Integer b = 1000;
System.out.println(a == b); //false, just det, Java jämför själva objekten.

Integer a = 100;
Integer b = 100;
System.out.println(a == b); //true, wtf!! För Integer upp till 127 så fungerar detta?

Integer a = 1000;
Integer b = 1000;
System.out.println(a.equals(b)); //true, equals-metoden fungerar som önskat.

Så, sammanfattningsvis tror jag att språket Java har mycket att vinna på att överge primitiverna, inte minst i att det blir konsekvent och därmed lättare att ta till sig för nya utvecklare. Dessutom tror jag att Oracle har en enorm utmaning i att genomföra denna ändring utan att bryta bakåtkompabiliteten eller införa ordentliga prestandaproblem.
Jag är tveksam att det ens är möjligt men det får framtiden för utvisa.

Blickar jag tillbaka på dessa tre projekt så kan dessvärre inget av dem bedömas som lyckade om man använder traditionella kriterier som ”levererades önskad funktionalitet”, ”överskreds budgeten” och ”överskreds tidplanen”. Det stora misstaget som gjordes var att det endast fokuserades på metodikens roller, möten och artefakter. Den bakomliggande agila grundtanken missades helt.
Jag ska försöka beskriva några av de kardinalfel som jag upplevde i dessa projekt och dela med mig av de erfarenheter som projekten gav mig.

Det dolda vattenfallet

Arbetssätt
Projektet inleddes med en lång period av kravarbete. Kraven portionerades därefter ut på X antal iterationer för att säkerställa att allt hanns med inom utsatt tidsram och budget. Redan från dag ett fanns det alltså exempelvis en uppfattning om vad som skulle utvecklas i sprint nummer elva.

Problem
Reflektera lite över detta, vad är egentligen skillnaden mellan ovanstående och ett traditionellt vattensfallsprojekt med kontinuerliga statusavstämningar. Egentligen ingenting och med detta arbetssätt gick mycket riktigt projektet i många av de fällor som lurar i traditionella vattenfallsprojekt. En stor del av det inledande kravarbetet var bortkastat då det i praktiken var omöjligt kravställa och designa systemen på papper i förväg. Funktionalitet fick därför skrivas om gång på gång och många av de utvecklade funktionerna användes aldrig. Projekten lade dessutom stora resurser på planering och omplanering. Varje iteration som inte levererade full funktionalitet spillde över i nästa iteration, knuffade den ursprungliga planeringen framåt och krävde ideliga möten för nya estimat och tidplaner.

En mer agil lösning
Vad vi borde ha gjort var att dra lärdom av tidigare iterationer och användarnas input efter varje iteration. Det som innan förra iterationen verkade som en nödvändig funktionalitet visade sig många gånger vara helt onödig när användarna började ”känna” på systemet. Genom att succesivt planera arbetet hade vi kunnat fokusera på den funktionalitet som användarna verkligen önskade och dessutom sluppit många av de oändliga diskussioner som uppstod vad det gällde tidplaner och krav.

Megastorys

Arbetssätt
Varje iteration populerades med väldigt stora uppgifter. Det var inte ovanligt att två, tre utvecklare jobbade tillsammans, med samma uppgift, under hela iterationen.

Problem
Varje uppgift tog mer eller mindre hela iterationen, i vissa fall ändå mer. Därmed blev det omöjligt för testarna att hinna testa inom iterationen. Eventuella buggrättningar drabbade därför nästkommande iterationer. Stora uppgifter visade sig dessutom vara betydligt svårare att estimera och många gånger underskattade vi arbetsbördan och tog på oss alltför mycket inom en iteration. De gånger som dessa kolosser till uppgifter inte hanns med inom iterationen så levereras inget affärsvärde alls. Ett annat bekymmer var att det i det närmaste var omöjligt att fånga hur vi låg till inom iterationerna eftersom inga uppgifter blev klara förrän under iterationens sista dag.

En mer agil lösning
Istället för att ”fuska” under kravarbete och sprintplanering borde vi ha lagt mer tid på att populera varje iteration med många, små, fristående uppgifter. På så vis hade testarna kunnat börja testa tidigt och de allra flesta uppgifter hade då varit testade och buggrättade inom iterationen. I de fall då vi tagit på oss för många uppgifter inom en iteration så hade vi dessutom ändå levererat affärsvärde i och med att övriga uppgifter var klara. Dessutom är det betydligt lättare att se hur arbetet ligger till tidsmässigt inom iterationen om uppgifter färdigställs kontinuerligt. Därmed hade vi tidigt kunnat vidta åtgärder om det pekade på att tiden inte skulle räcka till.

Överfyllda iterationer

Arbetssätt
Varje iteration fylldes med maximalt med arbete för att hinna med så mycket som möjligt.

Problem
En gammal sanning är att stressade utvecklare ofta genererar ”quick and dirty”-fixar vilket sett över tiden blir mer kostsamt än att lägga lite extra tid initialt. Vi straffades också av kontinuerligt sjunkande kodkvalitet vilket gjorde att produktiviteten sakta avtog. När alla utvecklare dessutom hela tiden var fullt upptagna med sina egna problem till 100 procent så gavs det mindre tid till att dels hjälpa varandra men också till att ta ett steg tillbaka och fundera på alternativa tekniska lösningar som kunde vara betydligt effektivare. Tiden till att kontinuerligt genomföra förbättringar som kostar lite extra tid kortsiktigt men som ger positiva effekter på lång sikt gavs inte heller.

En mer agil lösning
Jag har suttit i andra projekt där vi medvetet planerat in ”slack”, både inom iterationerna men också mellan iterationerna. På så vis har det hela tiden funnits tid för reflektion, kontinuerliga förbättringar och kommunikation mellan team-medlemmar. Dessutom omkullkastar inte en eller ett par sjukdagar i teamet hela iterationen.

Utdelade uppgifter

Arbetssätt
Uppgifter delades ut av projektledare/scrummaster vid början av varje iteration, därefter satt varje utvecklare var för sig och utvecklade sina delar.

Problem
Arbetssättet byggde inte en grupp utan en mängd enskilda individer som i första hand såg till sin egen uppgift. Detta trots att det många gånger fanns andra viktigare uppgifter som egentligen borde prioriteras. Utan att kunna påvisa några direkta fakta så fick jag även känslan av att detta beteende i vissa fall gav missnöjda utvecklare då uppgifter upplevdes som ”påtvingade”. Varje sprintplanering avslutades med något som uppfattades som ett ”uppgiftslotteri” där vissa drog nitlotter och andra drömvinster.

En mer agil lösning
Min erfarenhet är att optimal prestation fås i ”självorganiserande utvecklargrupper” där varje medlem i gruppen själv, eller genom diskussioner inom gruppen, avgör vilken uppgift som är lämpligast för närvarande. Det kan verka banalt men ”frihet under ansvar” fungerar. Jag kan garantera att det ger mer engagerade utvecklare, utvecklare som strävar efter att teamet tillsammans ska leverera och utvecklare som tar ett kollektivt ansvar över kod och arbetsuppgifter. Lite som Dumas musketörer, ”en för alla, alla för en”.

Jag skrev i första inlägget om makt och kultur som styrning av innebörder. Det handlar till exempel om hur frågor och problem ramas in och styrs mot särskilda föreställningar som stämmer med maktens idéer. Verkligheten presenteras och skapas på ett sånt sätt att antalet möjliga tolkningar av den blir färre – världsbilden snävas in för människorna.

I andra inlägget rörde jag mig mot makt och introducerade Michel Focaults maktteorier. Makt fungerar genom diskurser enligt Focault. En diskurs är ett kollektivt sätt människor har att se världen, förstå den och prata om den.

Diskurser styr människornas tankar och tal vilket har en begränsande, inskränkande effekt anser Focault. Han har en skeptisk, misstänksam attityd till hur diskurser disciplinerar människors tänkande och binder dem till en viss självuppfattning.

Jag tycker att poängen för oss är att han vågar gå hela vägen med sin tanke om hur diskurserna är större än människorna, bärs av dem, talar genom dem och kontrollerar deras idéer om vad som är normalt, naturligt, bra. Tack vare att han drar det till sin ytterlighet och pratar om förtryck blir hans teori praktiskt användbar.

Andra inlägget slutade med ett tips för att träna maktblicken på exemplet jag gav. Hur verkar makten här? På med Focault-glasögonen:

• Leta efter de restriktioner människor sätter på sina tankar, världsbilder, handlingar och självbilder
• Hitta de diskurser och makttekniker som styr hur folk jobbar och definierar sig själva

Vi fortsätter och analyserar makten i exemplet: Jag ser en restriktion i hur lösningen byggdes: Verksamheten förväntade sig en lösning som uppfyllde kraven de hade skapat. Kollegerna på IS/IT, å andra sidan, lät på ett självklart sätt en teknisk norm bestämma något annat och agerade som om det var naturligt att lösningens utformning skulle styras så. Det verkar som om it-sidan såg det som logiskt att de själva skulle definiera lösningen – de kan ju tekniken.

Om det för IS/IT är naturligt att tekniken går före, blir en uppfattning att det var oproblematiskt att skippa verifieringen mot verksamhetskraven mer begriplig. Enligt it-diskursen var det en självklar och korrekt restriktion på lösningen. Ett exempel på makt som bärs av en grupp genom deras bild av hur man skapar it-lösningar.

Men hur kunde projektledaren bara vifta undan verksamhetskraven så där, gällde de inte längre? Nej, jag tror inte det (hemska tanke). Här kommer en annan maktteknik in, it-projektmetoden. Jag tror att innebörden av krav med den metoden snarare blir att krav är ett av många dokument som ska produceras och bockas av, än ett uttryck för kundens behov av att förbättra sin verksamhet.

Så här tänker jag: It-projektmetoden som är till för it-projekt och används av it-människor, den fokuserar på it. Dessutom handlar projektmetoder om att producera och bocka av dokument (slå mig projektadministratörer men så ser jag att metoderna tillämpas på fältet). Så jag tror att det enligt it-diskursen var normalt och naturligt att se på kraven som bara ett dokument utan koppling till hur it-lösningen skulle se ut. Okay, jag drar det kanske lite långt men jag gör det i Focaults anda.

Dessutom var projektpengarna förbrukade och då kommer ytterligare en diskurs in, budgeten. Vad budgeten säger är alltid det rätta, även om det den säger är fel. Snacka om maktinstrument.

Identiteter, till slut. Makten styr även människors självuppfattning. Den här aspekten av makt är väldigt viktig att använda när man ska påverka en organisation. Jag anser att it-diskursen dominerar i det här fallet. I it-diskursen är IS/IT i centrum och it-människorna underordnas vissa identiteter.

Vilka är dessa identiteter? Jag tror att till exempel it-arkitektens självbild var den självklare beslutsfattaren och främste påverkaren på den lösning projektet skulle skapa (för verksamhetens pengar). It-arkitekten förknippade troligen sig själv helt naturligt med den tekniska designen, den som styrde allt annat.

It-utvecklarnas identiteter? De ser sig som problemlösare som arbetar med ny och spännande teknik. Ge dem problem att lösa och tillgång till ny teknik så är de lyckliga, allt annat är mindre viktigt. Ja, jag provocerar, men jag jag jobbar med makt i Focaults anda idag och därför går jag längre än vanligt. Lite får ni tåla.

It-diskursen är inte att leka med. Vi har kvar att analysera projektledarens självuppfattning. Titta på beteendet, på vad som verkar rätt, logiskt, förnuftigt för projektledaren i den här situationen. Jag tror att självbilden är att vara den som garanterar att projektet går i mål administrativt, det vill säga i tid och inom budget.

Om den självbilden stämmer är det förklarligt att projektledaren avstod från att verifiera lösningen mot verksamhetens krav. Lösningen var ju klar, i tid, och pengarna var slut. För en som ser sig som projektets garant var det otänkbart att riva upp lösningen i det läget.

Jag ska sammanfatta: it-människornas beteende i projektet, deras självbilder, påståenden, ordval, projektmodellen – allt tyder på en sammanhängande världsbild som tillåts dominera även utanför IS/IT. Denna världsbild, jag har kallat den it-diskursen, verkar gå ut på att IS/IT sysslar med införande av it-system.

Och? säger någon. Ja, ursäkta en verksamhetskonsult men i min värld ska IS/IT definiera sitt uppdrag som att de förbättrar verksamheter, inte att de inför it-system. Det är stor skillnad mellan vad föreställningarna ’införande av it-system’ och ’förbättring av verksamheter’ gör med folks tankar och beteenden.

Till exempel blir det olika svar på frågan ”För vem gör du det här?” beroende på vilken världsbild den svarande har. För it-personen som anser sig jobba med införande av it-system blir (det ärliga) svaret notoriskt att det är för IS/IT:s skull. För de få it-personer som ändå har idén att de jobbar med att förbättra verksamheter blir i stället svaret att de gör det för sina kunders skull.

I det här fallet verkar alltså den dominerande diskursen inom IS/IT styra personalen till uppfattningen att det är logiskt att de definierar lösningen själva, de kan ju tekniken. Och eftersom de delar föreställningen att projekten handlar om att införa it-lösningar, inte om att förbättra en verksamhet, är det oproblematiskt att skippa verifiering mot kraven.

Okay, tack för den långa samhällsvetenskapliga essän. Men hur gör man praktiskt för att motivera kravarbete internt? Hur kan perspektivet kultur-och-makt komma till nytta för den som konkret vill förändra organisationens inställning till kundinvolvering?

Makten omger alla, även verksamheten som köper it-lösningarna. Så vad göra när det är så här? För det första: Möt dem där de är. För det andra: Var relevant. För det tredje: Var uthållig; se påverkan som en process och inte en händelse.

Jag ska avsluta de här inläggen om kultur och makt med att ge en metod för det första steget, att möta dem där de är. De två andra stegen handlar om inflytande och förändringsledning, de kommer i inlägg längre fram inom ramen för mitt bloggande om ledarskap för konsulter.

Skickliga påverkare knyter an till sin publik, det är vad jag menar med att möta dem där de är. Du har nytta av din kunskap inom makt och kultur när du tar reda på var publiken är. Skickliga påverkare vet att det är omöjligt att kommunicera effektivt med andra utan att veta något om dem. De fokuserar på människorna de ska kommunicera med, inte på sig själva.

Ta reda på var publiken är. När budskapet är genomtänkt rikta tanken mot dem och ställ sex typer av frågor:

1. Vilka är de? Vilken världsbild har de? Vilken självbild har de?
2. Vad är syftet, varför är jag här?
3. Hur redo är de för mitt budskap? Vilka frågor eller invändningar har de?
4. Vad behöver de veta (kunskapsmål)?
5. Vad behöver de göra (handlingsmål)?
6. Hur får jag mitt budskap att fastna?

Notera att fem av frågorna rör människorna och endast en budskapet – påverkan handlar om dem, inte om dig. Vi ska fokusera på steg 1 och 3 som handlar om att ta reda på var de är så att du kan möta dem där.

Fråga 1: Vilka är de? Vilken världsbild har de? Vilken självbild har de? Här lägger du ut den information du har från din analys av kultur och makt. Dela in publiken i kategorier, kanske yrkesdiscipliner eller uppfattningar eller självbilder. Låt inte det här ta för lång tid för du vill till steg 3 som är kärnan i förberedelsen.

Fråga 3: Hur redo är de för mitt budskap? Vilka frågor eller invändningar har de? Nu går du över i deras perspektiv, ser världen med deras ögon, tänker som de. Detta är möjligt med den kunskap du har skaffat i kultur-och-maktanalysen. Notera att här krävs fantasi, inlevelseförmåga och oräddhet så det är inget för medelmåttor.

Det är här du skapar det underlag som ger dig handlingsutrymme och unika fördelar i din strävan att förändra organisationens inställning till kundinvolvering och kravarbete. Här får du ut nyttan av att ha lärt dig analysera kutur och makt. Få gör detta så du har ett potent redskap i din hand. Som du ska använda med omdöme; folk gillar inte alltid att bli avslöjade men de gillar uppmärksamhet och bekräftelse.

Slutklämmen blir: Lär dig perspektivet kultur och makt, ha det som ett verktyg för påverkan, använd det med respekt och ödmjukhet.

Jag skrev i förra inlägget om makt och kultur som styrning av innebörder. Det handlar till exempel om hur frågor och problem ramas in och styrs mot särskilda föreställningar som stämmer med maktens idéer. Verkligheten presenteras och skapas på ett sånt sätt att antalet möjliga tolkningar av den blir färre – världsbilden snävas in för människorna.

Makt är ett negativt laddat ord för de flesta. Dess vanliga innebörd, som är att en part avsiktligt bekämpar och motverkar motstånd hos en annan, kallas instrumentell makt.

Men det finns intressantare definitioner av makt, mindre synliga men mer effektiva. Som kravanalytiker kan du ha nytta av att se på en organisation i perspektivet kultur och makt. Jag erbjuder här ett tankesätt som ger dig ett annat fokus och mer skärpa i tolkningen av ditt företags attityd till kravarbete.

När samhällsvetare talar om makt refererar de oftast till Michel Focault, fransk efterkrigsfilosof. Focault är svår att läsa, försök inte, och kritikerna är många, men hans inflytande på hur vi numera ser på makt är enormt. Jag ska kortfattat beskriva ett par delar i hans tänkande om makt som är brukbart för en kravanalytiker.

Focault säger att det viktiga är inte att fastställa vem som har makt utan det är att förstå hur makten verkar. Makten ska studeras i hur den utövas mellan människor, säger han. Men med det menar han inte ett tvång utövat av den som har makt på den som inte har det, utan en makt som omger alla, påverkar alla och sprids av alla – en nätverksteori om makt.

Hur kan makt omge alla, påverka alla och spridas av alla? Genom diskurser, ett av de centrala begreppen i Focaults maktteori. En diskurs är ett kollektivt sätt människor har att se världen, förstå den och prata om den. Diskurser styr människornas tankar och tal vilket har en begränsande, inskränkande effekt anser Focault. Han har en skeptisk, misstänksam attityd till hur diskurser disciplinerar människors tänkande och binder dem till en viss självuppfattning.

Makt fungerar alltså genom diskurser enligt Focault. Jag tycker att poängen är att han vågar gå hela vägen med sin tanke om hur diskurserna är större än människorna, bärs av dem, talar genom dem och kontrollerar deras idéer om vad som är normalt, naturligt, bra. Tack vare att han drar det till sin ytterlighet och pratar om förtryck blir hans teori praktiskt användbar för oss.

Resultatet av den här sortens förtryckande begränsande makt, säger Focault, är att människorna utvärderar sig alldeles själva mot de standarder diskurserna föreskriver. Makten lever alltså sitt eget liv och bärs av alla på alla nivåer; vi är alla lika fast i diskursernas grepp om våra världsbilder.

Inte så kul att tänka på, men brukbart som redskap för den som vill påverka folk, till exempel förändra en organisations inställning till kravarbete. Focaults teorier om makt behöver inte vara sannare än andra teorier men de är användbara för våra syften här, det räcker.

Snart ska jag lämna de abstrakta samhällsvetenskapliga resonemangen och ge konkreta exempel på hur makt verkar sedd i ett Focault-perspektiv. Snart men inte riktigt än, håll ut för jag har viktig sak till.

Enligt Focault finns många kunskapsformer med koppling till makten, till exempel designregler, engineering-ramverk, tekniska standarder, managementmetoder och projektmetoder. Dessa fungerar disciplinerande; de är maktinstrument som styr och begränsar människornas handlingsfält. Dessutom styr de identiteter, det vill säga varje individs uppfattning om vem den är.

Nu ska jag konkretisera med ett exempel från min konsultpraktik: I ett uppdrag skulle jag hjälpa två processutvecklare att kravställa ett it-system för redovisning av vissa miljöfarliga material. It-systemet skulle utvecklas främst för att möta lagens krav så det fanns inga kommersiella behov som drev. Däremot skulle systemet få ganska många användare och det var för att involvera dem i kravarbetet som jag anlitades.

Vi intervjuade, observerade, simulerade och validerade fram en rätt bra kravbild som godkändes av verksamheten och lämnades över till IS/IT. Sen gick jag vidare till andra uppdrag och tänkte inte mer på hantering av miljöfarligt material. Förrän ett och ett halvt år senare när jag träffade de båda processutvecklarna på en konferens där jag höll ett seminarium i ledarskap.

Med sorgsna ögon berättade mina klienter att it-systemet var utvecklat och infört men att användarna var väldigt missnöjda med vad de fått. Systemet gjorde visserligen teoretiskt vad det skulle men det var svårt att använda och arbetet tog mer tid än med det manuella registret de haft tidigare.

Jag frågade hur det hade kunnat bli så med tanke på kravens goda kvalitet. De berättade då att acceptanstestet hade varit en fars. Användarna hade gjort tummen ner på punkt efter punkt där systemet inte uppfyllde kraven. Men projektledaren hade svarat dem att det här är vad ni får, att databasdesignen styrt hela lösningens utformning och att budgeten nu var förbrukad, klart slut.

Hur verkar makten här? På med Focault-glasögonen, träna maktblicken:

• Leta efter de restriktioner människor sätter på sina tankar, världsbilder, handlingar och självbilder
• Hitta de diskurser och makttekniker som styr hur folk jobbar och definierar sig själva

I nästa inlägg gör jag den här maktanalysen och ger konkreta anvisningar för hur du sätter kunskapen om kultur och makt i verket.

Kravlegitimering, det andra behovet, handlar om att göra kravarbete giltigt och betydelsefullt; det handlar om att motivera kundinvolvering, brukarorientering och voice of the customeri en organisation. Det här behovet är större än jag trott så nu kommer jag fortsatt att skriva även om hur man motiverar kravarbete.

Jag börjar med perspektivet kultur och makt där jag läst rätt mycket de senaste två åren för att tillfredsställa mina kritiska och emancipatoriska ambitioner. Senare kommer jag antagligen att skriva om kravlegitimering även i perspektivet retorik och argumentation, alltså mer praktiskt och konkret om hur man gör när man motiverar kravarbete.

Kultur och makt berör den politiska dimensionen i organisationer. Men inte endast –   politik blir lätt ett negativt laddat ämne trots att dess yttringar finns på nästan varje arbetsplats – för det berör även en rent social dimension. Detta är samhällsvetenskap, mina vänner, välkomna till den andra sidan.

För att ett kollektiv, till exempel ett företag, ska fungera behöver medlemmarna dela vissa grundläggande föreställningar och verklighetsuppfattningar – man måste vara överens om vad som är sant och vad som är rätt för att kunna arbeta tillsammans.

Fenomenet organisation kan därmed förstås som gemensam verklighetsuppfattning och verksamheten i en organisation som människornas skapande och upprätthållande av den verklighetsuppfattningen. Detta är ett av flera möjliga sätt att förstå vad organisation är, och vi ska använda det sättet nu.

Förenklat (samhällsvetare gillar inte det här, de vill hellre komplicera ämnet) kan man säga att kultur är kollektiva vanor, till exempel en grupps vanor att:

• definiera vad som är bra och dåligt
• uppmärksamma vissa saker och bortse från andra
• använda somliga ord men inte andra
• lyda några auktoriteter men inte andra

Makt är ett laddat ord, negativt laddat för de flesta. Den vanliga innebörden, instrumentell makt kallad av samhällsvetarna, handlar om att en part avsiktligt och med kraft bekämpar och motverkar en annan.

Men det finns fler och mycket intressantare definitioner av makt; de är subtila, mindre synliga och omedvetna men effektiva. Som kravanalytiker kan du ha nytta av att se på en organisation i perspektivet kultur och makt. Jag erbjuder här ett tankesätt som ger dig ett annat fokus och mer skärpa i tolkningen av ditt företags attityd till kravarbete.

Vi ska titta närmare på styrning av innebörder, en alternativ definition av makt. Det handlar om hur dominans utövas i en organisation genom att vissa innebörder ses som naturliga, logiska och oproblematiska. Ledande personer och grupperingar visar i handling, många gånger omedvetet och oavsiktligt, att de är goda företrädare för denna kulturellt reglerade verklighetsuppfattning. De utövar makt på ett indirekt sätt utan att riktigt veta om det.

Jag vet att detta är abstrakt samhällsvetenskap men stanna med mig lite till, snart kommer exempel som gör det mer konkret. Och om du tar till dig detta har du ett verktyg som ger dig fördelar när du vill utöva inflytande i en organisation.

Kulturell styrning av innebörder handlar om hur frågor och problem ramas in och styrs mot särskilda föreställningar som stämmer med maktens idéer. Verkligheten presenteras och skapas på ett sånt sätt att antalet möjliga tolkningar av den blir färre – världsbilden snävas in för människorna, på gott och ont.

Med det här synsättet utövas inte makt genom att starka aktörer synligt och uttalat bestämmer över svaga, vi snackar inte om diktatur och propaganda. Nej makten utövas i stället genom ett vardagligt skapande av särskilda föreställningar och uppfattningar på ett sätt vi inte alltid märker.

I det följande kommer jag att se på makt så här: makt är människors processer, tekniker och handlingar vilka styr innebörder och definierar människornas verklighet.

Låt mig konkretisera med ett exempel: I ett företag där jag gjorde ett konsultuppdrag kom jag i kontakt med en grupp reparatörer, det var mekaniker och elektriker. Reparatörerna skrev sällan rapporter efter sina jobb vilket gav ledningen gråa hår. Rapporternas information behövdes som kunskapsbas för förebyggande underhåll men väldigt lite kom in den vägen.

Jag tänkte att reparatörernas mönster att undvika rapportskrivande säkert hade goda skäl och frågade dem om det. Snabbt förstod jag att normen hos dem var enkel: att jobba är att skruva och reparera, men att skriva rapporter på dator är inte att jobba. Hjälte blir den som rycker ut och lagar grejer som är sönder, inte den som skriver utförliga underhållsrapporter. Skruva-inte-skriva var alltså den gällande gruppnormen. Den som avvek fick höra det och rättade in sig eller sökte sig annat jobb i fabriken.

Vilka var då kulturyttringarna som hyllade skruva och nedvärderade skriva? Tre exempel: Det var de krävande och brådskande reparationerna man pratade om vid kaffet, inte den senaste underhållsstatistiken. Det var skämten i duschen om tjänstemännen som sysslade med tabeller och analyser inom förebyggande underhåll och aldrig blev manligt smutsiga om händerna. Det var tillfredsställelsen när kön av akutjobb var lång och de svettiga reparatörerna hade allas uppmärksamhet.

Föreställningen om vad det innebär att jobba på riktigt styrdes alltså kulturellt. Likaså uppfattningen om hur man får status i reparatörsgruppen. Verkligheten definierades kollektivt som en rad mer eller mindre akuta reparationsjobb, vilket gjorde det oproblematiskt att hoppa över rapportskrivandet.

Jag rekommenderade ledningen att göra tvärtom för att lyckas få ut dugliga underhållsrapporter, att de skulle hylla reparatörernas gruppnorm skruva-inte-skriva i stället för att sucka över den och tjata på gubbarna.

Metoden jag föreslog var enkel: Lova reparatörerna att införa verktyg som gör det möjligt att skapa en rapport på en minut. Det går aldrig fick jag till svar och då visste jag att vi var på rätt väg. I workshopen kom sen cheferna med mängder av idéer om handdatorer, streckkoder, röststyrning och annat konstruktivt. Reparatörerna applåderade och kom med fler idéer om att skriva snabba rapporter – nu hade ämnet blivit intressant även för dem.

Träna på att upptäcka kulturellt styrda innebörder i din organisation. När du hittat dem har du många gånger nyckeln till hur du ska nå fram och påverka rådande attityder. Gör så här:

• Inventera rådande uppfattningar om vad som är bra, naturligt och logiskt i verksamheten – tänk efter själv, fråga andra, spana
• Lägg märke till vilka händelser och handlingar som uppmärksammas positivt bland folk – vad blir till snackisar
• Lyssna efter ord som används ofta – vilket språk är det, vilka ämnen kommer orden från

Försök sammanfatta dina kulturella slutsatser i enkla normbeskrivningar, typ skruva-inte-skriva. Går det enkelt är normen tydlig, annars kan du behöva spana mer. Det finns en risk att kulturella analyser blir ytliga och triviala. Det motverkar du med att söka efter en mångfald kulturella uttryck: vad som sägs, vad som inte sägs, hur det sägs, vad som görs, vad som inte blir gjort, skillnader, motsägelser, likheter, handlingskraft, energi, apati.

En allmän uppfattning är att inkapsling, och det närbesläktade ”information hiding”, i princip handlar om att göra alla fält i en klass till private och därefter skapa getters och setters för dessa fält. Finito, done, perfectum, klassen är inkapslad efter konstens alla regler.
Jag skulle vilja påstå att ingenting kan vara mer fel. Detta beteende ligger sannolikt bakom de flesta av de buggar som beror på att objekt har felaktiga tillstånd och gör dessutom system betydligt svårare att underhålla och förändra. Att då våra utvecklingsmiljöer erbjuder möjligheten att rutinmässigt generera getters och setters utifrån klassens fält borde snudd på rapporteras som en bugg. Vad den funktionaliteten gör är att uppmana till ett destruktivt beteende, ungefär som om bilhandlaren skulle bjuda på drinkar i samband med att man provkörde en bil. För vissa enstaka medpassagerare skulle det säkert ses som en trevlig service men för den stora massan mest fungera som ett försök att locka till en bedrägligt handling. Brottsprovokation är som bekant förbjudet för den svenska polisen men det är bevisligen tillåtet i Eclipse och IntelliJ.

För mig handlar istället inkapsling om en klass förmåga att gömma interna data och implementationsdetaljer, om att separera API från implementation. Hur självständigt ett objekt är och att reducera objektets beroenden till andra objekt.
En del i att uppnå detta är att alltid se till att ett objekt är färdigt att användas så fort det skapas och därefter erbjuda minsta tänkbara möjlighet att ändra objektets tillstånd. Ofta ser man dock kod som nedanstående:

Account account = new Account();
account.setId(accountId);
account.setType(accountType);
account.setOwner(owner);
listOfAccounts.add(account);

Det som utvecklaren bakom Account gjort här är dels att läcka implementationsdetaljer och dels att lämpa över ansvaret för att objektet skapas korrekt från sig själv till den som ska använda klassen. Detta trots att det med största sannolikhet är den som utvecklade klassen som borde veta vad som krävs för att objektet ska vara redo att användas. Finns det dessutom ytterligare några setters på Account så är det i princip omöjligt för en utvecklare att veta att exempelvis Owner är obligatoriskt. Missar han att sätta Owner så resulterar det om han har tur i ett ”nullpointer exception”. Har han otur slinker buggen igenom och ett halvår senare får han en felrapport i knät på att vissa konton saknar ägare.

En mycket bättre lösning på detta hade varit om Account hade tagit de fält som krävs som argument till konstruktorn. Dessutom hade sannolikt lite polymorfism suttit bra här:

Account savingsAccount = new SavingsAccount(accountId, owner);
listOfAccounts.add(savingsAccount);

Enklare, snyggare och definitivt mycket säkrare.
Ur detta perspektiv är det beklagligt att Java implicit skapar en ”no argument” konstruktor automatiskt om utvecklaren inte skriver en konstruktor själv. Det vore bättre att konstruktorlösa klasser gav kompileringsfel och att man i de undantagsfall där det faktiskt är befogat med en konstruktor utan argument skulle vara tvungen att skriva den själv. Det skulle om inte annat tvinga utvecklaren att tänka till angående implementationen, i alla fall till dess att han skulle upptäcka ”generera konstruktor”-funktionen.

Ett annat problem med såväl getters som setters är att de avslöjar klassens implementationsdetaljer. För att återgå till exemplet med ”savingsAccount”. Så här skulle det mycket väl kunna vara tänkt att räntan räknas ut:

//Calculate daily interest.
double amount = savingsAccount.getAmount();
int rate = savingsAccount.getRate();
double interest = (amount * rate / 100) / 365;

Här finns dessvärre möjligheten att ta del av implementationen av savingsAccounts och när någon plötsligt kommer på att det inte var så klokt att lagra rate som en integer och vill förändra detta så kommer det säkerligen att krävas förändringar på flertalet ställen i systemet. Är det dessutom så att det rör sig om ett publikt API som kunder använder så blir lösningen sannolikt att skapa ytterligare en getRate()-metod och därefter leva med en deprekerad getRate()-metod under resten av programmets livslängd.
Ovanstående exempel är tyvärr ett ganska vanligt tillvägagångssätt där utvecklaren väljer att fråga objektet efter information för att därefter själv processa den på lämpligt sätt. En smidigare lösning är att be objektet som sitter på informationen att även göra beräkningen:

double interest = savingsAccount.calculateDailyInterest();

Koden blir lättare att läsa och nu finns möjligheten att ändra ”rate” från en int till en double utan att det påverkar övrig kod eftersom detta är inkapslat inne i savingsAccount.

Något annat som kan utnyttjas för att kringgå inkapsling är arv. Det är en smal sak att ärva en klass och därefter överrida en metod så att den gör saker som klassen inte alls var designad för. En ändring i superklassen kan dessutom medföra fel i subklassen utan att subklassen ändras alls. Därför tycker jag att man rent generellt bör säkerställa att det inte går att ärva från klasser. Finns det goda skäl till att klassen trots allt ska vara möjlig att överridas så har man som utvecklare ett ansvar att designa sin klass så att inkapslingen äventyras så lite som möjligt.

Det absoluta drömobjektet är det som skapas av konstruktorn och där det sedan inte går att påverka objektets tillstånd alls. Dessa objekt kommer, så länge som de instansieras korrekt, aldrig att vara föremål för buggar som beror på felaktiga tillstånd. De kommer dessutom att vara trådsäkra och kan därmed delas hur mycket som helst mellan olika trådar och olika användare. Sträva därför efter att i möjligaste mån göra dina klasser oföränderliga.

Jag skulle vilja avsluta med en liten checklista för att säkerställa att ett objekt är inkapslat till en acceptabel grad. Följer du nedanstående så kommer du ett stort steg på vägen mot att bygga system som är lätta att underhålla och som sannolikt innehåller få tillståndsbuggar:

• Minimera synligheten på variabler, metoder och klasser (instansvariabler ska exempelvis självklart vara private).
• Generera inte getters och setters rutinmässigt.
• Se till att objektet är klart att använda då det skapas (erbjud ingen default-konstruktor).
• Sträva efter att göra klasserna oföränderliga.
• Se till att din klass inte kan överridas, förslagsvis genom att göra klassen ”final”.
• Erbjud inga metoder som påverkar klassens tillstånd.
• Låt klassen som besitter informationen erbjuda tjänster, inte ”rådata”.

Men i de många kommentarerna till inlägget skriver folk att visst visst det är helt rätt att reflektera, prioritera, säga nej, vara konsekvent, ha disciplin – men man orkar inte vara så duktig. Och då tänker jag, praktiker som jag är, att bra teori inte hjälper om implementationen uteblir.

Vi vet allt hur vi ska göra för att öka vår effektivitet, gå ner i vikt, ha en positiv attityd. Men vi gör det inte för implementationen är det svåra.

Gör i stället så här: Börja med väldigt små steg. Sätt typ målet att göra fem armhävningar varannan dag i två veckor. Sen tio armhävningar varannan dag i två veckor. Det är inte särskilt mycket och gör inte ont. Sen tio armhävningar varje dag i en månad. Efter två månader har du etablerat en vana vilket är poängen. Om du nu låter bli armhävningarna under några dagar kommer du att sakna dem – för att de blivit en vana.

Skapa vanor alltså och gör det i så små steg så att det blir av. Disciplinen att börja göra något litet och enkelt varje dag är mindre än att börja göra något stort och svårt varje dag. Börja med små steg.

HBR-artikeln betonar värdet av reflektion men säger samtidigt att detta görs inte på grund av det frenetiska tempot som inte har utrymme för stunder av koncentrerad eftertanke. Jag har frågat mina klienter systematiskt det senaste halvåret om vad de uppskattar mest med att jobba med mig som konsult i ledarskap och kommunikation. Alla, verkligen alla, svarar: Reflektionen. De älskar att reflektera och de gör det aldrig själva. Motsägelsefullt men sant.

Så här är en konkret anvisning för dig som gärna vill reflektera men inte riktigt fått till det än. Bestäm dig för att en enda gång per vecka göra en reflektion i tre steg (se nedan) och dokumentera resultatet med en snabb anteckning. Det tar 3-5 minuter av koncentrerad tanke och sen är det klart. Gör anteckningen i kalendern så att du sen kan följa upp att du gjort veckans reflektion.

Metoden kallas good-better-how och är enkel. Alla metoder jag jobbar med är enkla. Tre steg:

1. Vad gick bra?
2. Vad kunde gått bättre?
3. Hur kunde det gjorts bättre?

Tänk inte för mycket, ta det som dyker upp först i tanken. Anteckna några få nyckelord. Kom ihåg, du bygger en vana, tränar in en ny metod, och då är formen viktigare än innehållet. Bara gör det (just do it – bra fras men nån annan tog den före mig).

Efter en dryg månad har du reflekterat med good-better-how ett halvdussin gånger. Om du då hoppar över en vecka kommer du att sakna reflektionen för att vanan finns och drar dig åt rätt håll. Sätt igång redan idag!

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

I Java kan du exempelvis sätta teckenkod när du startar JVM:n med parametern

-Dfile.encoding=utf-8

eller när du läser från en fil

Reader reader = new InputStreamReader(is, "UTF-8");

För er som vill ha lite bakgrund till hur detta med teckenkodning hänger ihop kommer här en liten historielektion.
I begynnelsen var datorspråket engelska, alla tecken som behövdes fanns representerade i ASCII-tabellen och allt var frid och fröjd. Om det nu mot förmodan finns någon gammal IBM-räv som läser detta så antar jag att det höjs röster mot att det minsann fanns saker som BCD, BCDIC och EBCDIC innan ASCII tog över. Det är förvisso sant men för oss vanliga så var det före begynnelsen.

Hur som helst, klassisk 7-bitars ASCII hade plats för alla engelska tecken och dessa tecken representerades av siffrorna 32-127, exempelvis var ”blank” 32, 0 var 48, A var 65 och z var 122. Siffrorna 0-31 användas för att representera olika styrtecken som TAB, ESC och liknande.

Den dominerande IBM-datorn på denna tid använde sig dock av 8 bitar vilket gjorde att det fanns en bit kvar, utöver den traditionella ASCII-tabellen. Denna extra bit gav möjlighet att lagra ytterligare tecken med representationen 128-255. Runt om i världen började det också poppa upp utökningar för att ge stöd åt det egna språkets speciella bokstäver, det som vi uppe i norden ansåg vara en utmärkt representation för Å blev i Grekland bokstaven Ἠ. Asiaterna å sin sida byggde ett eget system som kalldes DBCS (”Double Byte Character Set”) för att få plats med alla sina tecken. Språkproblematiken var född.

Efter ett tag kom man i alla fall överens, via ANSI-standarden, att 0-127 skulle vara lika över hela världen men från 128 och uppåt var det helt olika tecken beroende på var man befann sig. Vad 128-255 representerade kom att kallas OEM-kod. Original IBM PC teckenkodningen blev OEM 437 medan exempelvis våra grannar i Norge och Danmark skapade OEM 865 eftersom de saknade Ø i OEM 437.

Ett försök att lösa språkförbistringen gjordes med Unicode. Idén med Unicode var att varje tänkbart tecken skulle få sin egen representation, något som bestäms av ”Unicode Consortium”. För närvarande är Unicode 6.0 den aktuella versionen och den innehåller 862 624 olika tecken. Det är lätt att tro att detta skulle vara det lyckliga slutet på historien men icke. Varje tecken representeras nämligen av en ”code point” på formen ”U+” plus ett hexadecimalt nummer. Exempelvis bokstaven A representeras som U+0041 och ni som kan er hexadecimala konvertering ser att hexadecimalt 41 motsvarar decimalt 65. A har alltså samma värde som i den gamla ASCII-tabellen. Detsamma gäller övriga bokstäver från den gamla 7-bitars ASCII-tabellen (A-Z, a-z). En vanlig engelsk textsträng som ”My name is Luca” representeras på följande sätt med den ursprungliga Unicode-kodningen (UCS-2):

004D 0079 0020 006E 0061 006D 0065 0020 0069 0073 0020 004C 0075 0063 0061

Fiffiga (engelskspråkiga) programmerare tyckte dock att det där var en massa onödiga nollor, här fanns
det diskplats att spara. Därför skapades UTF-8 som sparar tecken 0-127 i en byte medan övriga tecken
sparas i två eller flera byte. Det gav dessutom fördelen att vanliga engelska tecken lagras på precis samma sätt i UTF-8 som i det gamla ASCII-systemet. ”My name is Luca” på UTF-8 blir alltså följande:

4D 79 20 6E 61 6D 65 20 69 73 20 4C 75 63 61

Under åren har det sedan växt fram en rad olika sätt att lagra Unicode där UTF-8 är det vanligaste men det finns även exempelvis UTF-16 (som är närbesläktad till det ursprungliga UCS-2 kodningen), UCS-4, UTF-1 och UTF-EBCDIC som alla har sina egna små egenskaper. Lägg därtill att det fortfarande finns en rad gamla teckenkodningar som ISO-8859-1 som svävar runt därute i cyberrymden. Allt detta innebär att om det inte finns någon teckenkod angiven till en text och det kommer ett tecken som inte ryms inom det ursprungliga 0-127 ASCII-spannet så är det komplett omöjligt att veta vilket tecken som avses, istället skrivs det i vissa fall någon form av ”Mojibake” (skräptecken), i andra fall frågetecken eller fyrkanter.