Category: English

Att ha “för mycket att göra” är något som belönas i många sammanhang. Det ser helt enkelt rätt snyggt ut att ha mycket att göra, och en kort stund kan det kännas ganska bra också.

Tyvärr är “för mycket att göra” även ett utmärkt sätt att skjuta produktiviten i sank både för sig själv och för de man samarbetar med. Tråkigt nog (eller turligt nog, beroende på hur man ser på saken) brukar eventuella negativa sideffekter inte vara lika tydliga som svetten som stänker från den mer än fullt sysselsattes panna. De små, frekventa, och kanske lite imponerande stånken om att “det är så otroligt mycket just nu” gör också sitt till för att dölja det faktum att mycket är på gång men bara lite blir gjort.

Arbetsdagens längd varierar, men dygnet har exakt tjugofyra timmar, för åtminstone alla jag känner. Den som säger sig ha ont om tid menar alltså egentligen att det finns för mycket att göra. Någon gång då och då kan väl det problemet lösas med hjälp av en längre arbetsdag, men för de allra flesta producerar nog övertid mer magsår än affärsresultat.

Vad är alternativet till att jobba mer? Det är att lära sig hantera sin arbetsbelastning på ett sätt som ger resultat trots att tiden är begränsad.

Att lära sig hantera sin egen arbetsbelastning kräver två verktyg. Det ena är en personlig insikt om att den kortsiktiga nytta det innebär att “ha många bollar i luften” alldeles för ofta resulterar i långsiktig ineffektivitet. Det andra är förmågan att prioritera.

Lyckligtvis är inte båda dessa rekvisit lika svåruppnåeliga. Det ena av dem är faktiskt ganska lätt: att göra en prioriterad lista.

Varför göra en prioriterad lista? Tänk så här. Det är osannolikt att alla de saker du “måste” göra är lika viktiga. Alltså är vissa saker mindre viktiga än andra (dööh). De sakerna hamnar långt ned på listan.

Vad hamnar långt upp på listan? Längst upp på listan hamnar de saker som ger mest fyrverkerier för minst krut. Vissa kallar dessa saker lågt hängande frukt. Jag kallar dem ninjagrepp. Alla vet ju att de fruktade ninjorna (se upp för dem!) besitter kunskap om enkla grepp med dödlig effekt. Liten insats, hög verkningsgrad, eller på corporate-speak: bra nytto-kostnadsrelation.
Varför är det så effektivt att göra en prioriterad lista? Två saker gör metoden effektiv.

Här kommer den första: du kommer förmodligen ändå inte hinna göra allt du trodde du var tvungen att göra. När tiden är slut vill du självklart hellre ha gjort viktigare saker än mindre viktiga saker.

Här kommer den andra: när du gör en, rak och stilig, prioriterad lista så tvingas du göra svåra val. Två saker på en prioriterad lista kan nämligen aldrig (aldrig!) vara lika viktiga. Du måste välja. När vi verkligen måste välja tvingas vi tänka efter, och när vi tänker efter får vi mer kunskap om vad som är viktigt. Då ökar sannolikheten att när dagen eller projekttiden är slut, så har vi faktiskt åstadkommit något av värde både för oss själv och för andra.

In the past, I have worked some with web content management systems. Both as a developer, and as a user. The state of the art can be summed up like this: web content management systems are typically crap. They seem to be written by developers for developers, not for fast and efficient publishing.

At Citerus, we still use a seemingly powerful but painfully unusable and inefficient CMS, for historical reasons. I have been looking around for an alternative for some time, but most of what I’ve tried so far suffers from the same issues: complicated user interface design.

I am now evaluating the Ruby on Rails-based Radiant. So far, things look good. Though it seems to lack well-written documentation, its simplicity makes it easy to get started with. It seems to have come about when the developers of the new ruby-lang site discovered that they, too, could not find a sensible content management system.

Det sägs att vi svenskar är svåra att lära känna, men att när man väl lärt känna oss är vi lojala vänner. Inget större fel med den approachen, slutresultat verkar ju bli bra. Ett problem finns dock. När vi är på jobbet har vi inte alltid flera månader eller år på oss att bygga upp relationer med varandra.

Bristen på tid, upplevd eller verklig spelar ingen roll, leder till ibland märkliga situationer. Som när en person i ledande befattning, något försenad såklart, stormar in i ett konferensrum och hälsar på en handfull människor han aldrig träffat förut med orden: – “Låt mig börja med att berätta hur vi ska göra saker på det här bygget”.

Kanske inte det bästa sättet att etablera en mänsklig relation. Kanske får vi inte alltid det gensvar vi förväntar oss när vi inleder nya relationer på ett sätt som förnekar vårt behov av djupare kontakt.

Låter det flummigt? Borde man inte kunna förvänta sig av relationer på jobbet att de är sakliga och professionella, snarare än djupa? Nej, ibland kanske man kan önska att det vore så, men jag tror inte man kan förvänta sig det. Jag tror inte ens att det är önskvärt.

Så måste man vara kompis med alla sina kollegor?

Nej, jag tror inte det. Men jag tror inte heller att man klarar sig helt utan djupare kontakt.

Genom sig själv känner man andra, lyder ordspråket. Tänk efter – hur reagerar du själv när någon du inte känner kommer till dig och ber dig om något? När en projektledare du aldrig träffat presenterar sig kortfattat, och berättar att du ska jobba med serverkoden, ger dig inloggningsuppgifter och försvinner?

Å andra sidan: hur reagerar du om någon du inte känner gör en uppenbart ytlig ansats att “intressera sig för dig”?

Personligen kräks jag lite lätt på båda tillvägagångssätten. Det första är kallt och obehagligt, det andra är sliskigt och beräknande.

Så vad är mellanläget? Vad är ett avslappnat sätt att lära känna sina kollegor, utan att det känns krystat och tillgjort?

Här är två saker som jag tycker fungerar ganska bra, och som du kan dra nytta av redan idag och utan att be om tillstånd.

För det första, och jag kommer inte ihåg var jag först hittade denna sköna slogan, men den är bra: “Warm-up is never wasted.” Inget möte blir bättre av att man hoppar över de inledande 2-3 minuterna småprat, hälsa (med handslag) på varandra, säga hej. Tvärtom, efter lite uppvärmning slappar gruppen som möts av, och resten av mötet blir effektivare.

För det andra: etablera relationen idag. Vänta inte tills du absolut måste. Hugg någon vid kaffemaskinen och prata en stund. Fråga vad de heter och vad de jobbar med. Kan de någon teknik du är nyfken på, eller har ni kanske gemensamma bekanta? Var har de pluggat?

Nysta lite. Krysta inte fram det, men var beredd på att du kanske måsta sträcka dig lite utanför komfortzonen, det måste i varje fall jag. Fråga om det du skulle vilja att någon frågade dig om.

Intressera dig för dina kollegor, så går arbetet lättare. Dessutom gör du en insats för att bryta legenden om svensken som svår att lära känna. Bara en sån sak.

I det snudd på magiska ordet varför ryms ett otroligt kraftfullt sätt att lära sig mer om vad som helst.

Det berättas ibland sedelärande historier om chefer hos biltillverkaren Toyota som kommer till insikt om sina egna bristande inköpsdirektiv när de frågar varför det finns en oljefläck på golvet. De lyckas helt enkelt härleda det stora från det lilla, med den frigörande frågan: “Varför?” Det visar sig att de själva är ansvariga för oljeläckaget, eftersom de stipulerat inköp av oljefilter från den billigaste leverantören, som tyvärr också visade sig vara den sämsta.
Själv brukar jag använda mig av ett ganska praktiskt verktyg som ibland kallas varför-hur-trappan [1]. Har man tillgång till något att rita på ritar man helt enkelt en liten trappa, och lägger gärna till en pil som pekar upp för trappan med texten “Varför”, och en pil som pekar nedåt med texten “Hur”. Sen är det bara att skriva in det vi vill lära oss mer om någonstans mitt på trappan, och sedan följa trappstegen i endera riktningen. Tar vi ett steg uppåt frågar vi oss varför, går vi nedåt frågar vi oss hur.

Så här till exempel: vi borde börja skriva fler automatiska tester, skriver vi på mitten av trappan (eftersom någon just föreslagit det efter att ha läst MVKJG 1. Sen frågar vi oss varför, och skriver in svaret på steget ovanför: så att vi effektivt kan fånga och ta bort fler fel. Steget ovanför kommer nästan av sig själv, vi vill såklart bygga en felfri produkt, och anledningen till att vi vill det är förstås att vi vill ha fler kunder.

Vi kan gå nedåt också, genom att fråga oss hur. Varför inte rekapitulera från toppen? Vi vill ha fler kunder. Hur kan vi få det? Genom att ha en felfri produkt. Hur kan vi få en felfri produkt? Genom att hitta och eliminera så många fel som möjligt. Hur då? Genom att skriva automatiska tester som hjälper oss i testarbetet!

Sen kan vi fortsätta ännu längre ner förstås. Hur ska vi skriva automatiska tester? Genom att lära oss hantera ett ramverk för att skriva och aggregera tester. Hur ska vi lära oss ett sånt ramverk? Genom att köpa in böcker och planera in tid för lärande i vårt arbete.

Den här enkla modellen är vansinnigt användbar när man planerar ett projekt eller en iteration. Genom att placera in bitar av planen i trappan kan vi känna om de ligger på rätt nivå. Är de lagom konkreta, lagom målorienterade?

När jag hjälper till att planera iterationer vill jag till exempel att de funktioner och kvaliteter vi planerar i ska uttryckas så att utvecklingsteamet själva kan välja hur man vill uppnå dem. Blir vi konkreta för tidigt riskerar vi att låsa in våra tankar och eliminera möjligheter. Är vi för abstrakta blir det svårt att se om det vi planerar verkligen är genomförbart.

Proffsteknik: låt trappan evolvera till ett träd av orsakssamband som sprider sig i alla riktningar. Det finns ju alltid fler sätt att förklara orsaken till något, precis som det finns fler sätt att åstadkomma ett visst resultat.

Ett varningens ord på vägen dock. Konsulten och författaren Gerald Weinberg har pekat ut [2] att en fortsatt undersökning av ett problem ofelbart leder fram till problemets källa, som med största sannolikhet är din uppdragsgivare. På Toyota pratar man om fem varför. Jag brukar kalla metoden för “fråga varför tills du får en smäll på käften”. Det återspeglar bättre den sanna potentialen i denna grovt underskattade teknik.

—-

[1] Jag lärde mig verktyget i den suveräna “Att sälja och ta betalt för kunskap” av Britt-Marie Ahrnell och Rolf Edman.

[2] Se till exempel den roliga Secrets of Consulting, Gerald Weinberg.

För en tid sedan påminde jag några utvecklare om hur användbart och effektivt det är med automatiska tester. Jag tyckte att jag intog en ganska pragmatisk inställning, och tipsade (för att vi skulle komma igång med testskrivandet) om följande introduktionsupplägg.

Under den kommande iterationen kunde vi för varje bugg vi hade uppdrag att fixa först se efter om det verkade gå att skriva ett automatiskt test som återskapade buggen. Om det å ena sidan verkade gå kunde vi helt enkelt skriva testet. Om det å andra sidan inte verkade gå kunde vi skriva ned några anteckningar om varför det inte gick, och sedan tillsammans gå igenom vad som gjorde det svårt att skriva tester.

Ganska moderat upplägg, om jag får säga det själv. Svaret kom dock rätt snabbt: – “Vi har hört det här förut”. Och det hade de naturligtvis. Idag är det svårt för en utvecklare att missa alla uppmaningar om att man måste skriva sina egna automatiska tester, och som ofta när trycket i en riktning blir högt kommer ett mottryck som ett brev på posten. I det här fallet resulterar det i att inga tester skrivs.

En missuppfattning som kanske bidragit till att skrämma upp många är tron att vi måste skriva tester som täcker in alla möjliga felfall. Det är sällan möjligt, eftersom antalet möjliga kombinationer som måste testas ökar så snabbt i en framväxande mjukvara. Istället måste vi sätta oss in i hur vi kan testa för att få maximal avkastning på våra tester. Att börja med att skriva tester som varnar när en tidigare fixad bugg dyker upp igen är till exempel otroligt väl investerad tid.

Många har förklarat och argumenterat för att utvecklare skriver automatiska tester för sin egen kod. Jag har inga nya argument att tillföra, utöver detta: idag verkar de bästa utvecklarna i världen samstämmigt skriva under på att automatiska tester är viktiga, nyttiga och till och med ganska roliga, och att de ska skrivas av utvecklaren själv. Kanske kan detta åtminstone få dig lite nyfiken?

De är definitivt något du kan börja med idag, utan större investering i vare sig pengar eller tid.

*) Men Vad Kan Jag Göra?

Sitter du fast i ett projekt som också sitter fast? Har du tappat hoppet för mänskligheten (eller bara för den del av mänskligheten som utvecklar mjukvara)? Håll ut: det finns hopp. Du behöver inte förändra världen, eller ens ditt projekt, med ett svepande hugg. Du kan göra saker bättre ett litet steg i taget, helt på egen hand.

I min ficka har jag samlat inte mindre än 99 tips om vad du kan göra redan idag för att börja förbättra ditt projekt. Helt utan att be någon annan om tillstånd. Utan någon större investering. Utan att behöva anlita en hord av RUP-konsulter. Det finns ljus i tunneln. Ett steg i taget bara. Ett steg i taget.

Why not spend fifteen lovely minutes and try Ruby, courtesy of “Why, the Lucky Stiff”. Great idea, great implementation. What will be the next thing we can try out on the net?

Får du ont i huvudet av o-eleganta lösningar? Det får jag. Därför gillar jag Ruby. Och Ruby on Rails, och ja, det är precis så bra som alla säger, verkar det som hittills i varje fall.

Plus, varför är inte alla tutorials lika underbara som den här, om Ruby? (Tips: om du följer denna tutorial, och har svårt att få IRB att funka med {,\ och andra roliga tecken, tänk på att du även måste sätta HOME-variabeln till din hemkatalog, där du lagt .inputrc).

Ruby on Rails verkar vara ett intressant initiativ. Pröva på tekniken med hjälp av Curt Hibbs snabba introduktion “Rolling with Ruby on Rails”.