”Det bästa lärandet kommer från misstagen”

”Vi måste fira våra misstag!”

”Här är det tillåtet att göra misstag”

Hej och hå. Det snackas om lärande från misstag, om högt i tak, om experimenterande organisationskultur, om att fira misstag. Men det görs något annat: det straffas, tas i örat, utesluts, pekas ut, snackas.

Fira misstag? Hur långt får hycklandet gå? Vem vill fira ett misstag, vem vill snacka om att den gjorde fel, vem vill annonsera att den klantat sig? Alla vet att det finns mycket att lära från misstag men inte många gör det. Det är alltför riskabelt för karriären, tillhörigheten, positionen, tryggheten – tror man.

För att organisationer ska lyckas lära av misstag krävs enligt min erfarenhet tre saker:

• Ny syn på misstag
• Ny överenskommelse om misstag
• Nytt ledarbeteende vid misstag

För det första krävs en ny syn på misstag som kunskapsbärande händelser, något man ska närma sig i stället för att ta avstånd ifrån. Det är inte så intressant att ta reda på vilken regel som inte följdes eller vem det var som gjorde misstaget. Det intressanta är kunskapen som finns att hämta ur händelsen – fokusera på att hitta den.

Amerikanska marinkåren har en procedur de kallar After-Action Review (AAR) som har spridit sig i världens försvarsmakter. Den är robust och enkel och fungerar därför bra i alla lägen:

1. Hur tänkte vi att det skulle gå?
2. Hur gick det?
3. Hur förklarar vi skillnaden?

För det andra krävs en ny överenskommelse: Säg som det är, säg att ingen gillar misstag. Ingen gillar misstag, fatta. Sluta låtsas, väx upp, våga erkänna. Om organisationen är överens om att ingen gillar att göra misstag blir det lättare att prata om dem för dramatiken minskar.

För det tredje, troligen det viktigaste, krävs att ledare i sina handlingar visar att de 1) ser misstag som kunskapsbärande händelser, att de 2) inte gillar att göra dem och att de 3) drar ur kunskapen ur sina misstag. Att de gör detta så att folk ser med egna ögon; människor tror på vad de ser.

I ett klipp på Fast Company pratar John Arrow om att fira misstag, men inte fira för misstagets skull utan fira möjligheten till reflektion och ny kunskap. Fira behöver inte betyda att man köper tårta, det kan lika gärna betyda att man hedrar genom att uppmärksamma respektfullt, till exempel i en After-Action Review (AAR).

Ledarskap är inflytande så när du som konsult utövar inflytande leder du. Det har inget med position att göra, den i en grupp med mest inflytande är ledaren. Fast ledarskap är inget för otrygga, det är lätt att se, och ledare utan trygghet kommer att ägna sig åt bortförklaringar eller beskylla andra när de gjort misstag.

Men om du i din ledarroll lever de tre kraven ovan kommer andra att följa och göra likadant, jag garanterar. Alla gör nämligen misstag.

Verktyget för beslutsfattande består av nio frågor. Förra inlägget innehöll fråga 1 till 4, nu kommer fråga 5 till 9.

Ju svårare och mer komplexa besluten är desto mer material behöver vi mata in i medvetandet. Så fungerar beslutsfattande i komplicerade frågor: Mata in mycket information, gör något helt annat, vänta på besked inifrån. Större beslut fattas i det undermedvetna, det sköter intuitionen bäst utan intellektuell inblandning.

Jag påpekade att du ska fråga dig om detta verkligen är en beslutssituation: Finns det något att besluta om, har du ett val här? Om du inte har ett val är det inte ett beslut, det är ett faktum. Men om det faktiskt är ett beslut är de nio frågorna ett verktyg att förse medvetandet med beslutsunderlag i många perspektiv och nyanser:

1. Vilka är alternativen?
2. Vem vinner på beslutet?
3. Vilka är riskerna?
4. Hur bra är tajmingen?
5. Vilken uthållighet har jag?
6. Vad blir konsekvenserna längre fram?
7. Vem ska jag rådfråga?
8. Vågar jag fatta beslutet?
9. Fattar jag ett bekvämt beslut?

Fråga 5: Vilken uthållighet har jag? Här kommer en sten till på ledarens redan tunga börda: Det svåraste med beslut är inte att fatta dem, det är att genomföra dem. Ledaren behöver vara uthållig, emotionellt robust och tveklös i sin hantering av besluten när de väl är fattade, annars är besluten bara ord.

För att bedöma din förmåga att hålla ut ska du undvika best-case-tänkande. Tänk i stället risk. Ett dilemma med att agera riskdrivet är dock att vissa tycker det är emotionellt jobbigt. De kan säga saker som att vad ska personalen tro när vi uttalar oss så negativt (de lägger över problemet på andra i stället för att ta ansvar för sin egen ångest). Eller att nej nu måste vi tänka positivt (de orkar inte ta in att saker kan gå åt skogen). Fast för mig är det stimulerande att jobba riskdrivet, det får blodet att piska hårdare och jag blir kreativ.

Den här femte frågan är för att du ska måla en realistisk bild av dina möjligheter att lyckas med beslutet. Kom ihåg att många gånger består framgång av att hänga i ytterligare en minut.

Fråga 6: Vad blir konsekvenserna längre fram? Du har sannolikt en bild av det omedelbara resultat du vill att ditt beslut ska ge. Men du behöver också tänka igenom vad konsekvenserna kan bli på sikt. Det är en dag i övermorgon också – vad betyder ditt beslut då? Vinner du slaget men förlorar kriget?

Det kan vara frestande att med ett beslut fixa ett kortsiktigt bra resultat och bortse från följderna längre fram, att ta ut något trevligt i förskott och skjuta upp betalningen. Jag tänker på förre statsministern Persson vars uttalande ”den som är satt i skuld är icke fri” passar här.

Den här sjätte frågan är för att du ska testa om du kan leva med ditt beslut även längre fram.

Fråga 7: Vem ska jag rådfråga? Som du börjar förstå handlar dessa nio beslutsfrågor om att samla in mycket material och många perspektiv så att ditt undermedvetna kan processa fram ett intuitivt beslut med hög kvalitet. Ju mer och ju rikare beslutsunderlaget är desto bättre; det undermedvetna har praktiskt taget oändlig kapacitet (ingen har ännu lyckats mäta dess maxprestanda).

Det är bra att fråga om råd, bara du frågar fler än en person. Anledningen är att det finns en ganska hög felprocent i rådfrågande. Till exempel ger vissa tillbaka de råd de tror du vill ha, inte de råd du behöver ha, för att de vill vara snälla eller undvika konflikt. Välmenande vänner och föräldrar kan ge korkade råd på det sättet.

Sen ska rådgivaren ha kunskap. Ibland när klienter ber om råd avstår jag för att det är utanför mitt kunskapsområde, jag vet inte allting. Läkare däremot har åsikter om allt, det måste vara något i deras utbildning som formar den attityden (vad kan den delkursen heta?).

Att ge råd kan kräva en del tanke. Ta därför reda på om din rådgivare har tid att tänka efter innan du frågar.

Den här sjunde frågan är för att du ska ta in andras röster och ge ditt beslutsunderlag mer färgstyrka.

Fråga 8: Vågar jag fatta beslutet? Onödig fråga kanske du tycker men det tycker inte jag. Att chefer inte vågar fatta beslut är väldigt vanligt, särskilt i konsensussverige. Jag går som ledarskapskonsult ofta in och betonar beslutsfattarens såväl rättighet som skyldighet att fatta beslut. Sluta be om godkännande och medhåll i oändlighet, bestäm! Folk gillar den tydligheten (så länge det inte blir bossigt men det är ett attityd- eller trygghetsproblem i så fall).

En del chefer verkar ha uppfattningen att alla fakta ska in innan de kan bestämma något. Alla fakta? Hur vet man när allt är inne? De lägger an och siktar, siktar, siktar. De siktar och siktar men skjuter aldrig.

När du fattar ett beslut gör du dig sårbar. Det kan ju gå fel och i så fall står du där, ensam. Därför väntar många, de låter sin inre rädsla vara viktigare än kundens uppdrag, projektets mål eller teamets behov. Den här åttonde frågan är för att påminna dig att ta steget och verkligen fatta beslutet.

Fråga 9: Fattar jag ett bekvämt beslut? Det kan vara skillnad mellan att fatta det bekvämaste och det bästa beslutet. Det bekvämaste kan vara att besluta så att ingen blir missnöjd, att ställa upp, vara lojal och smidig. Det är enklare att säga ja än att säga nej, för vi vill vara omtyckta, verka viktiga och upptagna och vara duktiga.

Dunkla inre drivkrafter och behov kan alltså försämra beslutsförmågan. Det är därför otrygga människor inte ska vara ledare. Vi har alla samma behov av uppskattning, autonomi och tillhörighet men vi ska inte göra ett sämre jobb i vår strävan att tillfredsställa dem. Detta är ett ämne för sig som jag återkommer till, håller på att studera det just nu.

Här är en checklista så att du vet om beslutet är rätt eller bara bekvämt:

• Stämmer det med mina prioriteter?
• Är det i min styrkezon, d.v.s. är jag kompetent?
• Är det till nytta för min kund?
• Har det gått igenom min inre cirkels granskning?
• Har jag validerat det inåt i mig själv?

Den här nionde frågan är för att du slutligen ska kolla att nivån på ditt beslut håller, att dess kvalitet ger en meningsfull helhet i dina intressenters ögon.

Ett slutord jag inte riktigt kan låta bli även om det egentligen ska tas i ett levande samtal och inte i bloggen: Besluta dig för att besluta om de viktiga sakerna i livet. Besluta att besluta. Du måste inte besluta om de stora sakerna familj, hälsa, karaktär, attityder, yrke med en gång. Men fatta beslutet att fatta beslut om dem vid ett visst datum. Som ledare kan du inte ge det du inte har och har du inte fattat dessa viktiga inre beslut blir det svårt att leda andra i deras beslut.

Trots att Clean Code-vågen svept över utvecklarvärlden de senaste åren så förundras jag gång på gång över läsbarheten på den kod som jag dagligen måste brottas med. När jag läser kod vill jag att det ska vara som att läsa en serietidning. Det ska inte krävas någon större tankeverksamhet för att begripa vad koden gör och jag ska absolut inte behöva hålla olika objekts tillstånd eller dåligt namngivna variabler i huvudet. Tyvärr stöter jag ändå alltför ofta på kod som har fler gemensamma punkter med Kafka än med Bamse.

Här kommer därför några små tips i hopp om att göra kodvärlden lite vackrare och mycket enklare att förstå. Tanken är att tipsen utan större arbetsinsats ska gå att sätta igång med omedelbart. Det är inget revolutionerande och säkert inga nyheter för de flesta men bevisligen behöver de upprepas.

Tänk igenom din namnsättning

Använd beskrivande namn med vedertagen nomenklatur. Undvik att använda prefix och följ de namnstandards som finns. Ett variabelnamn bör reflektera vad variabeln står för och ett metodnamn bör beskriva vad metoden gör, inte hur den gör något. Ett klassnamn bör vara ett substantiv som beskriver klassens syfte.

Något som man ofta ser är slentrianmässig namngivning som inte ger någon extra information utöver klassens typ:

List list = new ArrayList();

Med ett mer genomtänkt namn blir allt så mycket tydligare (och självklart bör generics användas även om jag inte gör det i dessa exempel):

List userAccounts = new ArrayList();

Något annat som jag ofta ser är konstanter som namnges efter vad de innehåller istället för vad de representerar. Namnge konstanten DAYS_PER_WEEK istället för SEVEN, eller ännu hellre, använd en väl namngiven enum.

Checka inte in bortkommenterad kod

Med relativt jämna mellanrum så stöter jag av någon anledning på bortkommenterad kod. Jag har aldrig förstått syftet med det, vill man ha tillbaka koden så finns den i versionshanteringssystemet. Jag antar att tanken är att det ska vara lättare att gå tillbaka till gammal kod men väldigt snabbt försvinner även den möjligheten då koden runt omkring fortsätter att utvecklas samtidigt som den bortkommenterade koden inte underhålls.
Det enda som bortkommenterad kod tillför är att den skräpar ned koden och gör den svårare att läsa så personligen brukar jag radera den, omgående.

Se upp med kommentarer

Det här kanske är lite kontroversiellt för vissa men i de absolut flesta fallen finns det ingen anledning att skriva kommentarer i koden. Med väl namngivna variabler och metodnamn blir en kommentar bara redundant information som måste underhållas tillsammans med koden.
Jag vet inte hur många gånger som jag blivit lurad av att någon ändrat koden men samtidigt inte ändrat kommentaren.
Men, tänker du, mitt projekt är så komplext att vi måste skriva kommentarer för att koden ska gå att förstå. Jag vågar dock påstå att du med största sannolikhet har fel, själv brukar jag tänka att om koden är så komplex att jag måste skriva en kommentar för att den ska vara begriplig så är det förmodligen koden det är fel på. Därefter ser jag över namnsättningar och refaktoriserar koden så att den ska bli mer läsbar. Som minst går det alltid att ”gömma” komplexiteten i en väl namngiven metod eller klass så att ”huvudflödet” inte drabbas. På så vis är det bara den utvecklare som verkligen ska ändra eller behöver förstå den komplexa kodsnutten som behöver bry sig, övriga behöver endast konstatera vad metoden gör.
Nedanstående kodsnutt skulle förmodligen få de flesta utvecklare att stanna upp, åtminstone en sekund eller två. Sannolikt skulle kodsnutten också ackompanjeras med en kommentar:

int sum = 0.25 * 365 * user.getAccount().getTotal();

Bryter vi istället ut det komplexa till en egen metod och använder genomtänkta namn så blir koden så lätt att läsa att kommentarer är överflödiga. På köpet får vi dessutom en metod, calculateTax(), som är lätt att enhetstesta:

int tax = calculateTax(user.getAccount());

I andra fall är kommentarer nästan en förolämpning. Hur dum tror personen som skrev koden att jag är, egentligen?

// Set the users name
user.setName(userName);

Blanda dock inte ihop kommentarer med Javadoc. Som ett absolut minimum bör alla publika klasser och metoder dokumenteras med Javadoc.

Förtydliga komplexa if-satser

Även när det kommer till if-satser så blir koden ofta betydligt mer lättläst om man väljer att bryta ut eventuella komplexiteter i egna metoder. Exempelvis stötte jag på följande if-sats i ett av mina tidigare projekt:

if (( d != null && referer.indexOf(d) != -1) && ( a != null && referer.indexOf(a) != -1)) {
// Referer is this article (d and a match). Do not update
...

Detta hade varit ett ypperligt tillfälle bryta ut if-satsen till en metod istället och koden blir genast mycket lättare att förstå:

if (isArticleInvalid()) {
//Now is even the comment unnecessary
...

Deklarera variabler där de används

Ta för vana att deklarera variabler så nära där de används som möjligt och inom det scope som de används i.
Titta på nedanstående pseudokod:

int sum = 10;
if (isValid()) {
// kod som använder sum
}
// sum används inte mer

Det som görs ovan är att signalera till läsaren att sum används någonstans senare i koden. För att tydliggöra att sum endast används i if-satsen så borde variabeln deklareras däri.

Det händer ibland att jag stöter på kod från, gissningsvis, gamla C-rävar. Dessa har för vana att deklarera alla variabler högst upp i varje klass vilket tvingar läsaren att gå igenom en mängd kod för att se var variabeln används. Dessutom är det väldigt lätt att missa att variabeln ”petas” på mellan deklarationen och där det är tänkt att använda variabeln så snälla, försök att undvika alla gamla C-laster.

Se upp med argument till metoder

Komplexiteten i en funktion ökar för varje argument så ur det perspektivet är metoden som inte tar något argument perfekt. Den blir lättare att testa och sannolikt även lättare att begripa. Sträva därför alltid efter att ha så få argument som möjligt. Självklart måste man i vissa fall skicka med en variabel eller två men börjar det blir fler än så tycker jag att man ska ta det som en varningsklocka. Dels är koden sannolikt för komplex och dels så gör den förmodligen mer än en sak. I enstaka fall, till exempel vid komplicerade matematiska beräkningar, så kan det ändå vara motiverat med både fyra, fem och sex argument. Det är dock troligt att argumenten i dessa fall har ett så tätt samband att de borde grupperas ihop till en eller två egna klasser.

Något annat som jag ofta ser är att det skickas in ”flaggor” till metoder där metoden, beroende på om flaggan är sann eller falsk, gör två helt olika saker. Här blir koden mycket mer läsbar om det skulle vara två separata metoder istället så mitt tips är att helt undvika sådana flaggor.

Sammanfattningsvis, lägg hellre ned några minuter extra när du skriver din kod för att den ska bli lätt att läsa och lätt att förstå. Annars är det med största sannolikhet ändå du som sitter och kliar dig i huvudet om några veckor och inte har en aning om vad koden egentligen gör.

Användarupplevelse, eller user experience (UX), var i fokus på årets upplaga av Öredev som hade många intressanta och underhållande föreläsningar att bjuda på. Att UX var i fokus märktes framför allt på konferensens keynotes som behandlade ämnen som vikten av att sätta användaren i fokus för att ett system ska bli framgångsrikt, hur regler påverkar hur vi kommunicerar med varandra och hur användargränssnitt har utvecklats fram till nu och vad vi kanske kan förvänta oss att få se i framtiden. UX var även ett av de 15 spår som man kunde följa under konferensen. Även om UX inte är min specialitet så måste jag säga att man hittat väldigt bra föreläsare och aktuella ämnen att ta upp och jag är faktiskt förvånad över hur mycket konkreta tips jag fick med mig hem att jobba vidare med.

Mitt fokus på konferensen låg dock inom 3 andra spår. Java, arkitektur och excellence. Excellence handlar om att kontinuerligt sträva efter att lära sig och bli bättre. Arkitekturspåret handlade till stor del om hur man kan optimera för att hantera förändring i system, vilket i min tolkning handlade mycket om att bättre kunna hantera arkitekturfrågor i ett agilt sammanhang. Java spåret innehöll blandade godbitar av teknisk natur, bland annat om Java EE 6, REST-services och MongoDB.

Två föreläsningar som i min mening var konferensens allra bästa gavs av Greg Young och Udi Dahan. Greg Young höll en föreläsning under med titeln How to get productive in a project within 24 hours som handlade om hur man kan utnyttja statistik ur versionshanteringssystem och code metrics för att effektivt hitta ställen i koden som kan vara potentiella problemområden. Kanske inte så mycket nytt, men en lite annorlunda tillämpning av informationen och framlagt på ett väldigt engagerat sätt.

Udi Dahan höll en väldigt intressant föreläsning med titeln Domain models and composite som handlade om vanligt förekommande problematik i domänmodeller och tankar om hur man kan tackla den typen av problematik. Kortfattat kan man säga att det handlade om hur relationer kan orsaka stora problem när en domänmodell förändras och hur men kan bryta ut relationer ur modellen och klargöra affärsmässiga behov för att kunna dela upp modellen i mindre och mer lätthanterliga bitar. Med relationena på behörigt avstånd kan man sedan jobba med kompositer av objekt när man bygger sin funktionalitet. Med andra ord föreslås en annan sorts normalisering än vad man oftast finner i våra system, för att bättre kunna hantera förändringar. En lysande föreläsning i min mening.

/Jonas Holmer

Vid vårt senaste virtuella ledarskapsseminarium för konsulter pratade vi om hur man fattar beslut. Jag inledde seminariet med beslutsverktyget som beskrivs nedan och handledde därefter en kollega på en beslutssituation från hans uppdrag. Timme två bestod av reflektion i gruppen runt modellen, caset och deltagarnas egna erfarenheter.

Verktyget för beslutsfattande består av nio frågor. Det låter kanske mycket med nio frågor för den otålige och jag håller med. Men ju svårare och mer komplexa besluten är desto mer material behöver vi mata in i medvetandet. Därför är nio frågor lämpligt.

Sen efter inmatningen – det här är viktigt – ska beslutsfattaren gå och bowla eller städa badrummet, det vill säga göra något annat, och låta det undermedvetna jobba i fred. Så fungerar beslutsfattande i komplicerade frågor: Mata in mycket information, gör något helt annat, vänta på besked inifrån. Större beslut fattas i det undermedvetna.

Enklare beslut däremot kan vi fatta med den tänkande hjärnans rationella delar, typ vad ska vi ha till middag eller hinner jag klippa gräset innan dotterns ridlektion är slut. Men de större sammansatta besluten sköter alltså intuitionen bäst utan intellektuell inblandning.

En sak till innan vi går in på verktyget med de nio beslutsfrågorna: Fråga dig om detta verkligen är en beslutssituation. Finns det något att besluta om, har du ett val här? Om du inte har ett val är det inte ett beslut, det är ett faktum. Och ifall det är ett faktum avgör din attityd hur du agerar på det. Det är viktigare än man först kan tro att klargöra huruvida beslutssituation föreligger; det fungerar som en mental uppvärmning.

Om det faktiskt är ett beslut, om du har ett val, är följande nio frågor ett verktyg att förse medvetandet med beslutsunderlag i många perspektiv och nyanser:

1. Vilka är alternativen?
2. Vem vinner på beslutet?
3. Vilka är riskerna?
4. Hur bra är tajmingen?
5. Vilken uthållighet har jag?
6. Vad blir konsekvenserna längre fram?
7. Vem ska jag rådfråga?
8. Vågar jag fatta beslutet?
9. Fattar jag ett bekvämt beslut?

Fråga 1: Vilka är alternativen? Alternativ gör att du ser mer, även det som inte andra ser. En väldigt bra chef jag hade tidigt i min militära karriär frågade ofta om vilka alternativ jag inte hade valt. Han ville försäkra sig om att jag hade övervägt mer än en väg och hans idé var att om man inte har alternativ kanske inte beslutet blir det bästa.

Ju fler alternativ desto mer kreativt kan du titta på situationen. Så skapa alternativ och gör det genom att tänka tidigt, ofta och utanför boxen (bortom dina vanemässiga tankemönster). Ja, det här är krävande men jag har aldrig sagt att ledarskap är enkelt.

Den här första frågan är för att du inte bara ska titta på alternativ till lösningar utan även på alternativa beskrivningar av problemet/situationen.

Fråga 2: Vem vinner på beslutet? Den här frågan berör ledarens syn på andras värde och attityden till sin uppgift här i världen. Om beslutet ensidigt gynnar en part är det, framför allt på sikt, ett dåligt beslut. Win-lose är aldrig bra men det är vanligare än win-win vilket är svårare att åstadkomma.

Förvånande många förväxlar win-win med win-lose. Jag har fått nypa mig i armen många gånger när folk beskriver ett win-lose-utfall som ömsesidigt förmånligt. De tror att om de själva vinner så är det win-win. Bli inte häpen om du möter den här uppfattningen för den är rätt vanlig trots att den är paradoxal och svår att riktigt förstå.

Nej, om andra har ett värde för dig driver du inte ett beslut så hårt att de blir losers. Du ger innan du tar, du söker att först förstå och därefter att bli förstådd, du värderar relationer och inser vad de betyder för ditt inflytande. Du lever med inställningen att den som tillför värde till andra får en tillfredsställelse i det – och får mer tillbaka.

Den här andra frågan är för att du ska kontrollera hur nyttan av beslutet fördelar sig, så att du höjer din medvetenhet om det. Ibland blir ett beslut negativt för vissa och då gäller det att ledaren är genomtänkt.

Fråga 3: Vilka är riskerna? Gå igenom vilka de negativa följderna kan bli av beslutet och för vem de skulle vara negativa. Vem kan förlora något? Vem kan komma att befara att den förlorar något? Vad är det värsta som kan hända efter beslutet?

Riskhantering – förlåt men nu kommer en fördom om administrativt lagda projektledare – uppfattas ibland som en tabell med saker som ska tas bort, deletas. Men riskhantering handlar om att hantera risker som fortsätter att finnas, inte om att eliminera dem. Som grodorna på Liseberg där man bankar ner en och då dyker det upp två nya ur andra hål och så håller det på.

Några användbara principer: Om du klarar att ta det värsta som kan hända, ta risken. Acceptera att alla kan känna sig missnöjda eller kränkta, det är alltid någon som misstycker oavsett vilket beslut ledaren fattar. Känn efter när det är nog. Ett citat av den tyske filosofen och missionären Albert Schweitzer är passligt: Om du äger något du inte kan leva utan äger du det inte, det äger dig.

Den här tredje frågan är för att du ska höja medvetenheten och beredskapen för eventuella negativa följder av beslutet.

Fråga 4: Hur bra är tajmingen? Tidpunkten för ett beslut är lika viktig som dess innehåll. Ett bra beslut vid fel tidpunkt resulterar i förvirring eftersom det inte borde hända just då. Ett dåligt beslut vid rätt tidpunkt däremot resulterar i motstånd. Men i motstånd finns energi ledaren kan kanalisera, bara tajmingen är rätt.

Jag har börjat ägna mig åt tajming mer och mer i min konsultpraktik och är än så länge bara i början av lärbanan. Men redan nu ser jag att tidpunkten för när något händer är en faktor som är enormt underutnyttjad av ledare. De flesta tajming-val ledare gör är sena snarare än tidiga; man skjuter på det. Tänk efter själv – hur vanligt är det att beslut kommer tidigare än väntat?

Som så mycket annat inom ledarskap kan tajming läras och det handlar om fantasi. Genom att träna disciplinerat fantiserande i simuleringar kan ledare utveckla sin känsla för tajming. Simulering är i grunden inget annat än påhittade berättelser. I Peter Senge’s klassiska bok The fifth discipline kallar han det microworlds och i militära stabsutbildningar kallas det war gaming. Fantasi alltså, grunden för kreativitet, innovation och tajming.

En bra tajming-regel hämtad från de gamla och kloka är topp-till-topp-principen. Den säger att när du är långt nere i en dal ska du inte fatta stora beslut, dem ska du fatta på toppen där du ser längre. När det är tungt och besvärligt kan det alltså vara läge att vänta med avgörande beslut till en tidpunkt då energin är högre och beslutskvaliteten bättre.

Den här fjärde frågan är för att du ska reflektera över vilken tidpunkt som är bäst för beslutet.

I nästa inlägg kommer fråga 5 till 9.

Det har varit Gartner ITXPO i Barcelona, läser jag i Computer Sweden. CS-reportern skriver om sju saker som ”CIO:n måste göra”, varav tre handlar om annat än teknik och en av dessa är om kompetensutveckling inom det vi på Altran kallar soft skills. Yes! Gartner har fattat, och vågar prata om det.

CS-reportern skriver att CIO:n måste lägga över hälften av fortbildningsbudgeten på ämnen som är samhällsvetenskapligt orienterade, som kognitiv psykologi, sociologi och antropologi. Jag måste nypa mig i armen, är detta ett trendbrott?

Enligt CS är skälet till omorienteringen i kompetensutveckling att det behövs för att hitta framtidens affärsmöjligheter. Ja det är nog ett trendbrott tänker jag. För var finns uppslag, behov och idéer till framtidens affärsmöjligheter, är det i teknikers hjärnor eller i den yttre verkligheten där människor går omkring och skjutsar barn och tjänar pengar? De finns där ute såklart.

”Där ute” kallas i samhällsvetenskapen för ”samhället”, därav namnet (jämför social science – societey). Hitta framtidens affärsmöjligheter, skriver CS, är vad CIO:n ska ha den samhällsvetenskapligt orienterade kunskapen till. Hur då? Jag tar ett exempel och länkar till en brittisk innovationsforskare, Keith Goffin, vars bok Hidden needs handlar om hur man gör för att hitta de dolda behoven, de som har stor innovationspotential.

Metoderna i Goffin’s bok är från etnografi, sociologi, lingvistik och psykologi men ska användas i tekniska sammanhang där innovativa produkter och tjänster utvecklas. Samhällsvetenskapen kommer alltså till tekniken; it-konsulten måste förstå människan.

Låt oss bli konkreta och tala om vilka delar av samhällsvetenskapen som passar och hur sån kunskap är nyttig för en it-konsult. Ett område är explorativt tänkande där konsulten behöver veta dels hur människan tänker och dels hur man stimulerar människor till kreativt tänkande: kognitiv psykologi och samtalsteknik.

Det finns många metoder för kreativt tänkande. Min favorit är enkel, som allt jag gör eftersom jag bara förstår enkla saker. Komplicerade saker är för andra konsulter, jag är en förenklare. Metoden är grundad på principen att riktigt bra idéer kommer från bra idéer vilka i sin tur kommer från ganska bra idéer – en kumulativ process. De riktigt bra idéerna kommer alltså inte ur tomma intet, de kommer när tänkande hjärnor utsätts för andra hjärnors idéer.

Så konsulten som vill få igång kreativt tänkande i en grupp kastar in ett par halvbra idéer och ber folk kommentera dem. Då får någon en annan idé, väckt av reaktionen på den idé konsulten kastade in. I sin tur får en tredje person en idé som bygger vidare på den förra och så är processen igång. Det viktiga är alltså processen i vilken idéer uppstår och konsulten ska först starta och sen hålla igång den genom att stimulera människor till att reagera på andras idéer.

Den här metoden kräver mod och trygghet hos konsulten eftersom processen innehåller så mycket kritik. Man får därför inte identifiera sig med sin idé utan i stället se till gruppens totala kreativa prestation. Svälj prestigen och låt någon annan få berömmet för snilleblixten du bäddade för.

Ett annat område är gruppdynamik, de flesta it-konsulter arbetar i grupper. Psykologin i en arbetsgrupp är komplex men med bra kunskaper i grupprocesser kan konsulten känna igen typiska drag och välja ansats därefter. Till exempel är det motigt att etablera spelregler och rutiner i ett team där folk ännu inte känner sig inkluderade och accepterade. En konsult som kan gruppdynamik, till exempel firo-modellen, vet detta och väntar.

Så nu när till och med Gartner snackar om soft skills är det dags för alla it-konsulter att skriva in en ny rubrik i cv:n: Soft skills (alternativt social science). Där under ska stå utbildningar och uppdrag som givit kunskaper på det samhällsvetenskapliga området. Internt på Altran finns till exempel kurserna presentationsteknik, improvisationsteknik, mötesteknik, kravhantering och ledarskap. Skriv skriv.

Vet du hur du ska skriva din kod för att förhindra en injektionsattack?

Är du systemutvecklare och har svarat nej på ovanstående fråga så föreslår jag att du genast släpper tangentbordet, tejpar fast knapparna på musen, ställer ned kaffekoppen och inte skriver en enda rad kod till innan du läst på. Annars är sannolikheten stor att du förr eller senare kommer att drabbas av en överraskning av det tråkigare slaget.

Organisationer som CERT, SANS och MITRE kommer med jämna mellanrum ut med rapporter om de största IT-relaterade säkerhetshoten och injektionsattackerna ligger ständigt i topp trots att de tämligen enkelt kan förhindras med lite kunskap och en gnutta sunt förnuft. Här kommer därför en fem minuters intensivkurs.

Vad är en injektionsattack?

I stora drag handlar det om att data med ursprung utanför ditt system, ofta något som en användare knappar in i ett inmatningsfält, skickas in i ditt system för att utföra uppgifter som du som utvecklare inte hade tänkt dig.

Den mest kända formen är SQL-injektion som handlar om att manipulera SQL-frågor mot databasen. Ett exempel på detta kan vara en fråga som kontrollerar om en användares lösenord är korrekt:

I Java skulle detta kunna skrivas:

String sqlQuery = "SELECT * FROM user WHERE username = '" + username + "' AND password = '" + password + "'";
Statement statement = connection.createStatement();
ResultSet result = statement.executeQuery(sqlQuery);

Antag att <USERNAME> och <PASSWORD> hämtas från två inmatningsrutor i din applikation och att en användare knappar in ” ’OR ’1’=’1’ ” i lösenordsfältet. SQL-frågan som körs mot databasen blir då följande:

SELECT * FROM user
WHERE username = ’<USERNAME>’
AND password = ’’
OR ’1’ = ’1’

Denna fråga kommer att ge ett riktigt svar och användaren blir därmed inloggad, utan att vare sig behöva ange korrekt användarnamn eller lösenord.

På liknande sätt går det även att genomföra injektioner med syfte att köras direkt på kommandoradsnivå i operativsystemet. Tanken med nedanstående kod är att användaren ska skicka in sökvägen till en katalog och få innehållet listat (i Windowsmiljö).

String dir = System.getProperty("dir");
Runtime rt = Runtime.getRuntime();
Process proc = rt.exec("cmd.exe /C dir " + dir);

Om någon som argument till ”dir” skulle skicka in ”dir1 & rd dir2 /S /Q” så skulle programmet först lista allt i katalogen dir1 och därefter radera hela dir2 inklusive filer och underkataloger. Nog kritiskt för att din chef ska sätta kaffet i halsen och för att du ska få jobba över i helgen.

Vad kan du göra åt det?

A och O när det kommer till att förebygga injektionsattacker är att ta kontroll över användarens input och sanera det från oönskat data. Förväntas användaren bara ange numeriska tecken så bör övriga tecken betraktas som ogiltiga:

För många av de vanligaste problemen finns det också färdiga API:er som med fördel bör användas. Ett exempel på detta är PreparedStatement som kan användas för att förhindra en SQL-injektion. SQL-frågan från exemplet ovan skulle då bli något i stil med:

PreparedStatement tar då hand om all sanering och det enda du behöver göra som utvecklare är att skicka in användarnamn och lösenord som parametrar istället.

Problematiken kring injektioner riktade mot Runtime.exec skulle också den kunna lösas med att sanera användarens input med ”Pattern.matches” men den generella rekommendationen är att undvika Runtime.exec om så är möjligt. Att lista filer i en katalog kan lika gärna göras med File.list()-metoden istället och denna lösning är då att föredra.

Med detta hoppas jag att du fått en snabb inblick i problematiken kring injektionsattacker och hur du kan tämja problemet. Injektionsattacker är dock bara ett av alla potentiella hot men lyckligtvis finns det en mängd bra källor, både i bokform och på nätet, med rekommendationer på hur du skriver säker kod.

Ett bra ställe att starta på är http://www.securecoding.cert.org.

Jag sitter på Heathrow, långt borta i ett hörn. Det är lördag eftermiddag och jag är på väg hem efter en ledarskapskonferens i Seattle. Inspirerad, glad och effektiv jobbar jag med bland annat vår introduktionskurs för nyanställda i början av december.

Introkursen är vår andra i år, Altran Sverige har aldrig slutat anställa och aldrig slutat tjäna pengar. Det talar för sig självt. Pengarna har jag ingen stor del i men relationer med de nyanställda får jag däremot mycket av. Det är ett privilegium att under ett intensivt dygn få lära känna dessa it- och verksamhetsproffs som är nya på Altran.  Att stå inför dem och känna in den kunskap de bär är en stark uppelvelse. Ibland räknar jag hur många års kunskap som finns i rummet, siffran gör mig ödmjuk och påminner mig om min obetydlighet vilket är bra för egot.

Nu när jag förbereder introkursen börjar jag med vad och inte med hur. Det är frestande att skriva en agenda först med olika moment som känns trygga och som jag vet brukar fungera på konferenser med företag – att börja med hur. Men så enkelt går det inte och jag har tre timmar innan planet till Göteborg så här ska tänkas disciplinerat.

”Begin with the end in mind” är en av Steven Covey’s mest kända principer, den är ett annat sätt att uttrycka kravanalytikerns princip om vad, inte hur. Men, trots att vi vet att det är rätt att definiera problemet/målet/uppgiften först och leta lösningar sen gör vi ändå alltför ofta misstaget att hoppa till lösningen direkt. Varför? Vi skippar det nu, jag är inte filosofisk idag utan inspirerad och effektiv.

Så, vad ska introkursen göra, vilka resultat ska vi ha när flocken nyanställda Altrankonsulter åker hem från konferensgården? Här är en lista med önskade resultat, de ska ha:

• ett eget nätverk av kontakter med minst 20 andra nyanställda kolleger
• en påbörjad personlig relation med företagets nyckelpersoner inom ledning, sälj, coach och kompetensutveckling
• en reflekterad egen uppfattning om Altrans värderingar och sätt att fungera
• en glad, varm och inspirerad känsla över att jobba här

Fyra resultat som vi ska uppnå – vad:et är definierat. Hur:et kan se ut på många sätt och vi ändrar ständigt upplägget. När jag nu väljer moment och placerar ut dem på agendan värderar jag dessas bidrag till de önskade resultaten.

Intervjun med vd till exempel, vilka frågor ska jag ställa för att de ska börja bygga en personlig relation med honom? Hur får jag honom att oförställt och på sitt eget sätt (han använder gärna färgstarka idrottsmetaforer) berätta om vad vårt uppdrag är och meningen med varför just vi finns som konsultbolag. Eller speed-datingen, hur utformar vi logistiken så att de får ut mesta möjliga kunskap och samtidigt hinner lära känna nyckelpersonen på varje station?

Reflektionen dag 2, hur mycket tid får den ta? Inte för länge för då hinner vi inte runda av och sammanfatta ordentligt. Men inte för kort för då går vi emot värderingen att lyssna till alla och bekräfta betydelsen av alla.

Det här är kul, jag kombinerar moment och lägger ut dem på en tidslinje. Ska det vara A, B, C eller B, C, A? Vad ger bäst effekt på de fyra önskade resultaten? Det är ett faktum att när man börjar med vad:et, det vill säga målen eller de önskade resultaten, så blir hjärnan kreativ. Då kommer idéerna av sig själva, drivna av kraften i målen. Men börjar man med hur:et, lösningen, blir tänkandet snävt och färglöst.

Det här handlar om tankedisciplin, en förmåga att göra det rätta trots frestelsen att ta den enkla vägen och gå på lösning direkt. Vad kommer disciplin ifrån? Från karaktär. En bra konsult har karaktär. Hur märker dina kunder att du har karaktär? Med vilka av dina handlingar visar du att du har disciplin?

”Moving Java Forward” var slagordet för årets JavaOne och med några dagars distans till det hela så är omdömet genomgående positivt. Om vi börjar med det praktiska så var fjolårets JavaOne lite av ett organiserat kaos efter att Oracle valt att flytta konferensen från San Franciscos stora konferenscenter Moscone till några närliggande hotell. Även årets JavaOne höll till på samma hotell men trots att det, enligt Oracle, var ungefär dubbelt så många deltagare i år så var känslan snarare att det var färre. Mer utrymme, fler sessioner och större föreläsningssalar gjorde att allt nu till största del flöt på relativt smidigt.

Vad det gäller själva utvecklingen av Java så är det positivt att denna nu tagit ordentlig fart igen. Under JavaOne presenterades en såväl hoppfull som tydlig roadmap som kan sammanfattas som följer:

Java 7, släpptes nu i somras med bland annat följande innehåll:

• Nytt API för filer vilket innebär att det nu är lättare att hantera kataloger och filer på disk. Exempelvis finns nu ”oneliners” för att flytta eller kopiera en fil:

  Files.copy(source, target);

• ProjectCoin, en mängd mindre ändringar som förenklad hantering av ”Generics” och ”MultiCatch”.

• InvokeDynamic, bättre stöd för alternativa JVM-språk.

• Fork/Join-framework, bättre stöd för parallellism och datorer med flera kärnor.

Java 8, släpps sommaren 2013 innehållandes bland annat:

• Project Lambda, stöd för closure-liknande syntax.

• Project Jigsaw, modularisering av Java-plattformen.

• Nashorn, ny Javascript-hantering.

• Nytt API för att hantera datum och tid.

Java 9, ska vara klar till sommaren 2015 och även om innehållet nog mest för tolkas som visioner så nämndes i alla fall bland annat följande:

• ”Self tuning JVM”

• Multitenancy – stöd för att köra flera applikationer i samma JVM

• Stöd för stora data (> 4Gb)

• ”Reification” – Bland annat genom att avskaffa ”Type erasure”.

Det talades också en hel del om JavaFX 2 som ska vara plattformsoberoende och utvecklingsspråket ska vara Java. Inget mer JavaFX-script eller liknande alltså. Vidare är det tänkt att JavaFX 2 ska släppas som en del av JavaSE 8 och kommer således vara tillgängligt från och med sommaren 2013. Det visades en demo på JavaFX och det ser helt klart spännande ut, både rent grafiskt men inte minst det faktum att de kunde köra på såväl Windows som Android och IOS.

Vad det gäller Enterprise-delarna av Java så låg fokus kring JEE7 och ”molnet”. JEE7 ska kunna erbjuda ”Platform as a Service” och därmed förbättrat stöd för exempelvis att köra flera olika applikationer samtidigt och även bättre skalbarhet.

Utan att gå in alltför djupt på innehållet i de över 400 sessioner som hölls så var det mycket fokus på bland annat modularisering (Jigsaw, OSGi med mera), JavaFX samt alternativa JVM-språk (som Scala, Groovy, Clojure, Mirah och Gosu).

//Magnus Sundström och Tobias Modig

Jag hade bilen på service. Kundmottagaren hade kollat vilket typ av service som behövdes eftersom bilen inte hade gått så många mil senaste året, och ringt tillbaka för att bekräfta. Snabbt, proffsigt, trevligt. Jag hade bett dem ordna en brist som fanns från deras tidigare reparation av en dörr: de hade inte limmat tätningslisten tillräckligt bra så den hängde lös. Han bekräftade, inga problem enkel grej.

Jag hämtade bilen, bra bemötande, bra verkstad. Dyr men bra. Stannade för att handla på väg hem, öppnade passagerardörren och listen fladdrade i löst vinden. Nej.

Ringde verkstan, tyvärr med tonfall färgat av besvikelsen. Liten brist men stort problem för mig som måste pilla in listen varje gång jag stänger dörren. Och här inträffar sanningens ögonblick där kundmottagaren kan ta kundens perspektiv om den vill, kan och får. Gör han det?

Han ber om registreringsnumret först av allt. Letar upp bilen i sin dator. Som om jag fanns i hans dator. Men hallå din kund finns i telefonen, inte i datorn, och är upprörd. Ta nu kundens perspektiv och stanna i min värld en minut; ta in min bild och min besvikelse, be mig beskriva vad jag ser just nu, var jag är, hur jag upptäckte att listen inte blivit limmad, hur jag hade lämnat av ärendet och fått bekräftelse, vilka problem jag nu står inför, hur jag känner mig nu.

Ställ intresserade frågor, var nyfiken på min värld, lyssna på svaren och fråga fler frågor. Du vet att det är klart när mitt taltempo går ner, då kan du gå in på lösningen.

Nej, han läser i sin dator och säger att limma tätningslist inte står angivet här så det är nog därför det inte blivit åtgärdat. Och hur mycket bryr jag mig om vad som står i ert dumma bokningssystem? Jag står här på en parkering med hängande dörrlist och är förtvivlad. Bekräfta mig! Stäng av datorn och fatta att bilarna ni lagar ägs och körs av levande människor som inte har tid att fnatta till verkstan hela dagarna.

Hade han gått över i mitt perspektiv och låtit mig prata av mig min besvikelse skulle jag ganska snart blivit mer mottaglig för förslag till lösningar, det är ju bara en gummilist vi pratar om i sak. Hade han intresserat sig för min upplevelse genom att intervjua mig om min världsbild en liten stund skulle det ha funkat bättre. Men han ägnade sig åt att förklara att eftersom det inte stod i bokningssystemet var det inte hans fel att listen inte blivit limmad. Hans intresse var att försvara sig mot det han trodde var ett angrepp så det höll han på med medan jag pratade om mitt. Det var inget bra möte mellan människor.

Efter en stund sade han att de skulle fixa listen om jag kom in till verkstan. Bra om jag kunde ringa en dag i förväg, helst lämna bilen en halvdag. Då ilsknade jag till och svarade att jag kan ringa dagen före och ange när jag kommer men förväntar mig att de limmar listen direkt utan dröjsmål. Då gick han och frågade sin chef. Hon kom till telefonen och sade att kom du så limmar vi, ring gärna lite i förväg så står vi klara när du kommer.

I skyltfönstret har verkstan affischer där det står om personligt bemötande, din personliga servicetekniker, kunden i centrum. Mekanikerna har varit på kurs i kundbemötande. Det fungerar nog så länge det är rutinärenden men så snart något stör rutinen glöms detta, då gäller egen säkerhet, komfortzon och definitivt inte den andres perspektiv.

Jag är så glad att jag har lärt mig detta med perspektivbyte och hittat enkla modeller att ha när jag hjälper klienter förstå samma sak. I ledarcoachning använder jag det hela tiden.

Tätningslisten? Den fladdrar. Jag har satt orange tejp i kryss över dörren och ser bilen som tredörrars så länge.