Andra inlägget om samtalsteknik för kravanalytiker. Ju mer jag arbetar med kravhantering och ju fler människor jag träffar i krav- och innovationssammanhang desto säkrare blir jag på att detta med att ta den andres perspektiv, ställa bra frågor, lyssna aktivt och tänka explorativt är kärnan i kravanalytikerns kompetens.

Men inte bara det, jag märker också att den här domänen är nästan tom. Kravkurser berör intervjuteknik ganska ytligt och kravanalytiker är oftast tekniker eller superanvändare utan utbildning i samtalsteknik.

När jag hittade metoden Motivational Interviewing, MI, såg jag att den var rätt för kravanalytiker av två skäl: den handlar om att arbeta utforskande och den är begriplig. Enda nackdelen är att litteraturen inom MI är skriven för missbruksvård och friskvård, en helt annan värld. Därför behöver vi översätta vissa MI-ord till innovationsord. För övrigt passar MI som handsken, mer om det längre fram.

Förra inlägget handlade om den ena av två grundprinciper i MI, klientcentrering, som betyder att samtalet utgår från klientens uppfattningar, tankar, föreställningar, idéer och upplevelser. Klienten i centrum; konsulten tar klientens perspektiv och sätter sig själv i bakgrunden. Jag avslutade med några redskap för att träna klientcentrering.

Idag handlar det om den andra grundprincipen i MI: reflekterande nivå. En förutsättning för att samtal ska leda till nya insikter och idéer är att de förs på en reflekterande nivå där klienten med viss distans kan betrakta sig själv och sina föreställningar.

Vi använder begreppet det reflekterande rummet för att beskriva en plats mellan inre och yttre verklighet dit man kan förflytta sig i tanken. Här behöver klienten inte identifiera sig så starkt med sina egna tankar och handlingar utan är friare att tänka hypotetiskt eller prova idéer i tanken utan att det hotar egna uppfattningar och föreställningar.

Ett fysiskt föremål som står i rummet kan både konsulten och klienten titta på och prata om utan att behöva blanda samman sig själva med föremålet. På samma sätt går det att placera ut tankar, idéer och föreställningar i det reflekterande rummet som om de vore saker.

När en tanke finns ute i rummet mellan två samtalspartners är den skild från den som tänkte den. Klienten kan betrakta sin egen tanke där i det reflekterande rummet och tänka nya tankar både om tanken och om sig själv. Konsulten kan utmana med alternativa perspektiv eller fördjupande frågor utan att klienten upplever det hotande – det gäller ju något som är på utsidan. Det handlar om den där saken/tanken och inte om mig, tänker klienten.

Klienten får hjälp att lägga ut sin berättelse i det reflekterande rummet och dela den med konsulten. Det öppnar för nya insikter just för att klienten nu har berättelsen utanför sig själv, kan titta på den på ett nytt sätt och därefter ta in den igen, nu laddad med ny förståelse.

Det låter abstrakt, jag vet, så låt oss konkretisera: När du talar med en person som lyssnar uppmärksamt och intresserat på det du säger känns det ganska bra; uppmärksamhet och bekräftelse gillar vi. Då, mitt i samtalet, får du nya idéer bara genom att lyssna till dina egna ord. Lyssnaren behöver inte säga något, du får idéer ur ditt eget prat. Detta är det enklaste sättet att placera tankar i det reflekterande rummet.

Ett annat enkelt sätt för konsulten att hjälpa klienten lägga ut sin tanke i det reflekterande rummet är att upprepa ord klienten använt som verkar viktiga. Till exempel: “Du pratar om att strukturera och följa upp” eller “Du återkommer till att du är ny i det här jobbet”. Då får klienten höra sina egna ord fast sagda av en annan röst vilket kan väcka nya tankar.

Ett tredje sätt är att sammanfatta, jag återkommer till den teknikens detaljer längre fram. Konsulten kan med egna ord sammanfatta det sagda och på det sättet erbjuda en bearbetning av klientens berättelse. När klienten hör skillnaden mellan konsultens ord och sina uppstår möjlighet till reflektion och nya tankar.

En förutsättning för att klienten ska kunna röra sig ut i det reflekterande rummet är att konsulten också är där. Det är bara i det reflekterande rummet mellan parterna som konsulten kan hålla distansen till klientens berättelse. Dessutom är det bara där konsulten kan hålla isär klientens berättelse från sina egna uppfattningar om vad som är rätt eller fel i den. Och det är bara genom att stanna i det reflekterande rummet som konsulten kan få syn på egna impulser att påverka klienten om något, och hålla tillbaka dem.

Träna på att vara i det reflekterande rummet den kommande veckan. I samtal med andra ska du upprepa ord de använder som verkar viktiga (för dem, inte för dig). Gör så här:

• Lyssna noga till vad den andre säger. Vad vill den få fram? Vilken tanke har den på insidan?
• Hitta ord som återkommer. Hur betonar den andre dessa viktiga ord? Vilka fördröjningar eller tempohöjningar hör du runt dem?
• Svara tillbaka genom att upprepa ett eller ett par av de viktiga orden, neutralt och lugnt utan att värdera orden som bra eller dåliga – bara erbjud din observation

Om några dagar kommer nästa inlägg som handlar om samtalets struktur, fem faser. Klientcenteringen fordrar att samtalet går i ett tempo och en sekvens som passar klienten, oavsett hur ivrig konsulten är att komma fram till behoven. Där passar modellen om samtalets fem faser in. Vi hörs snart.

I februari 2011 skrev jag om generativa frågor och nämnde en samtalsteknik, Motivational Interviewing, som jag under året har fördjupat mig i och verkligen gillar. Äntligen har jag hittat en metodik som är begriplig och funkar i kravsammanhang! I en serie inlägg kommer jag här att skriva om den.

MI-tekniken är visserligen ganska enkel i sin beskrivning men den är krävande att använda. Så läs det här bara om du är intresserad av att jobba praktiskt med kundinvolvering på avancerad nivå. Det handlar om att våga tro på att faktorer utanför din kontroll arbetar för dig, så mycket kan jag säga.

Få samtalsmetoder lägger så stor vikt vid kommunikationens detaljer och deras psykologiska betydelse för klientens kreativa tänkande som MI. Därför passar samtalstekniken bra för kravanalytiker i deras arbete med kundinvolvering. Jag kommer att kalla samtalsparterna klienten och konsulten i hela det här materialet.

Empati eller teknik? För att du som kravanalytiker ska lyckas med kundinvolvering måste du vara intresserad av människor. Alla är inte intresserade av människor och måste inte heller vara det – bara de inte försöker arbeta som kravanalytiker eller ledare. Så för att du ska bli framgångsrik här måste du vara ärligt intresserad av den andres berättelse och ha en genuin önskan att hitta klientens behov.

Det är alltså ingen nackdel att vara skicklig i samtalsteknik, bara du använder den i ärliga syften. För kom ihåg, samtalsteknik utan människointresse är manipulativt och oetiskt.

Mysigt eller effektivt? Målet med intervjuer och möten i kravarbete är inte att det ska kännas naturligt och trevligt för klienterna, målet är att det ska kännas speciellt och resultateffektivt. Så klienterna får gärna märka att kravanalytikern använder en professionell samtalsteknik. Bara du förstår att det viktiga för kravanalytikern är empatin och människointresset, inte samtalstekniken som bara är ett redskap. Akta dig för att bli en intervjurobot.

Jag ser två grundprinciper i MI: klientcentrering och reflekterande nivå. Idag handlar det om klientcentrering, den svåraste för tekniskt utbildade människor som är vana att tänka lösningar.

Klientcentrering betyder att samtalet utgår från klientens uppfattningar, tankar, föreställningar, idéer och upplevelser. Samtalet begränsas till en början av de ramar klienten sätter och klientens egenaktivitet är central. Konsulten går över i klientens värld och låter klientens tankar vara viktiga, vilka de än är.

Konsulten är sällan experten men styr ändå i viss mån samtalet genom att leda det igenom en serie teman eller hypoteser, mycket mer om det längre fram. Konsultens främsta uppgift är att skapa en atmosfär av trygghet, tillit och frihet som underlättar för klienten att reflektera över sig själv och därmed upptäcka sina behov. Samtalet blir ett gemensamt projekt med likvärdiga parter, fast i olika roller.

Fördelen med klientcentrering är möjligheten att få tillgång till klientens resurser och att undvika motstånd eller tvekan. En möjlig nackdel, om man driver klientcentreringen för långt, är att behov konsulten ser men inte klienten förblir oupptäckta.

Balans alltså och klienten i centrum. Detta är det svåra, att ta den andres perspektiv och sätta sig själv i bakgrunden. Men konsulten är hjälpare, översättare, som utforskar behov tillsammans med klienten. Klienten har huvudrollen, konsulten har en biroll.

Träna på klientcentrering den här veckan. I samtal med andra ska du göra dig intresserad och nyfiken på den andre och hålla kvar det perspektivet så länge du kan. Ställ dig själv dessa frågor på insidan:

• Vad är viktigt för den andre just nu? Vilket behov finns bakom vad den säger?
• Hur ser världen ut för den andre i det här ögonblicket? Vad ser den som jag inte ser?
• Vad skulle den andre helst vilja göra nu? Om det inte går, vad skulle den tycka vore ett acceptabelt alternativ?

Reflektera efteråt över hur länge du stannade kvar i den andres perspektiv och vilken tanke som drog dig tillbaka till ditt eget. Värdera det inte, du ska vara en neutral observatör. Efter reflektionen har du fakta om två saker: a) hur länge du stannade i den andres perspektiv och b) vilken tanke som drog dig tillbaka.

Stå emot frestelsen att vara duktig och döma dina handlingar som bra eller misslyckade – bara öva och reflektera över de två variablerna a) och b) helt neutralt. Annars kommer du inte att lära dig så mycket inom samtalsteknik.

Snart kommer nästa del som handlar om reflekterande nivå, den andra grundprincipen. När du behärskar den har du ett magiskt instrument i din hand. Vi hörs om några dagar.

”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?