Förbättringsförslag 6: Släpp fram kreativiteten

Det finns en skröna om en snickare som insåg att ritningen på ett bygge inte fungerade, så snickaren ändrade så att det skulle funka. När arkitekten såg detta ringde han byggherren som sedan skällde ut snickaren efter noter. Snickaren försvarade sig med att säga att han tänkte att om han ändrar lite så kommer inte huset att trilla ihop. Byggherren svarade med: ”Du ska inte tänka, du ska bygga!”

Mjukvaruutveckling är en lika kreativ syssla som snickeri. Många olika idéer behöver prövas innan en bra lösning finns. Gamla tankar måste kunna rivas upp för att testa nya lösningar. Lyckas man inte på de timmar man förutspått behöver man lägga fler timmar. Och utvecklaren måste ha tillåtelse för detta, annars framkommer den farliga attityden: ”Du ska inte tänka, du ska programmera”.

Känner utvecklaren att han vill bra saker men får svårt att motivera dem kanske han väljer att göra dåliga saker som inte behöver motiveras.

Förbättringsförslag 5: Lär av andra

Ibland möts man av en ”Not invented here”-filosofi. Det kan handla om dataprotokoll, kravspårning, dokumentinnehåll eller helt vanligt arbete. Vi är glada ingenjörer som gillar att lösa problem, så när vi ser ett problem så löser vi det, med tillgänglig kunskap.

Tillåter du dina utvecklare att läsa facklitteratur några timmar i veckan kommer deras kunskap öka och de kan snabbare känna igen standardproblem och veta hur dessa ska angripas med standardlösningar.

Jag lägger ca 2h arbetstid och 5h fritid i veckan på att läsa in mig på det jag jobbar med. Utöver det läggs 2h av fikaraster att diskutera vad som har lästs under veckan. Det har gjort att jag tycker att arbetet är avsevärt mycket roligare, jag använder standardlösningar och standardarbetssätt. Jag har dessutom insett att de problem vi har idag inom mjukvaruutveckling är samma som fanns på 70-talet, så vi kommer inte att kunna lösa dem med stressade quickfixar. Lär av andra och du får en avsevärt bättre inblick i ditt eget arbete.

Förbättringsförslag 4: Rätt person på rätt plats

Det här inlägget kan innehålla brist på insikt, och det kan vara därför jag blir förvånad när vi anlitar personer som läst industriell ekonomi, skickar dem på kurs i Las Vegas, och sätter dem på att programmera grafik.

Det kan vara så att storföretag inte kan rekrytera den personal de önskar utan får nöja sig med "the best of what's left" och då är det arbetsplatsens image som arbetsgivaren får jobba på istället.

Men visst är det något konstigt när vi anställer tekniska doktorer inom matematik, ger dem en fyradagars C++-kurs och sätter dem på att programmera hårdvara i en produkt. Eller för den delen tekniska fysiker som läst två kurser programmering på universitetet och som får samma behandling. Jargongen i matsalen är ”nej jag jobbar verkligen inte alls med det jag är utbildad för”. Andra säger ”jag måste byta, jag kastar bort mitt liv på att göra fel saker”.

Steve McConnell och Fred Brooks förklarar i sina böcker att skillnaden på en bra programmerare och en dålig är en faktor 10. Det en bra programmerare åstadkommer på en timme behöver en dålig programmerare 10 timmar på sig. All heder åt den tekniske doktorn som är en stjärna inom sitt område, som han dessutom får lön efter, men det är nog okej att kalla honom en dålig programmerare. En bra programmerare med lägre utbildning blir glad för samma lön som doktorn får, så vi kan räkna på samma timpeng, säg 1000 kr/h. Det doktorn gör på en månad kostar 160 000 kr. Detta gör den duktige programmeraren för 16 000 kr. Alternativt kan du se det som om du anställer rätt person till jobbet kan du friställa 10 andra som gjorde jobbet på fel sätt. Skrämmande att inget händer?

Image: Paul Martin Eldridge / FreeDigitalPhotos.net

Förbättringsförslag 3: Skapa bästa möjliga förutsättningar

Du har anlitat de absolut bästa snickarna, målarna, murarna men bygget står nästan helt stilla. Projektledarna piskar förtvivlat hur mycket Riesen de än trycker i sig. Vad är problemet, du har ju de bästa förutsättningarna? Väl?

Har alla tillgång till ritningen?

Har alla tillgång till bra verktyg?

Har ni en uppdaterad arbetsplanering?

Fixar ni hittade fel innan ni bygger vidare?

Håller ni reda på hittade fel i en lista?

Om inte är det kanske inte så konstigt att det inte går framåt.

Samma frågor bör man ställa inom mjukvaruföretag, och Joel Spolsky har skapat ett enkelt tolvfrågetest för detta. Får du inte 12 poäng gör du det svårt för arbetarna att arbeta.

Projektet jag jobbar i nu får 3 poäng. Till sitt försvar måste jag säga att vi har precis startat mjukvaruutvecklingen och tillsätter testare och fixar daily builds tex. Men det är ändå en viktig indikation på att fokus bör ligga på att skapa bästa möjliga förutsättningar innan vi börja skapa bästa möjliga mjukvara.

Förbättringsförslag 2: Skaffa utbildning på verktygen

Det räcker inte att köpa in en avancerad skruvdragare. Om snickaren inte vet hur den ska användas kommer han nyttja den som en dyr hammare och slår i spik istället.

Det är ungefär vad som hände när vi tog ett beslut att använda Rhapsody för modellbaserad mjukvaruutveckling. Rhapsody har sin styrka i modellering och tillståndsmaskiner. I början visste vi inte hur vi skulle modellera eller använda tillståndsmaskiner. Istället började vi använda Rhapsody som en väldigt dyr och tämligen värdelös programmeringseditor. Det hade i princip gått snabbare att skriva koden för hand på ett papper.

Efter att ha gått en utbildning i verktyget (och lagt ca 100h på egen hand) kan jag arbeta riktigt effektivt och jag kan visa andra hur det ska gå till. Utan kursen hade jag fortfarande använt skruvdragaren som en hammare.

Förbättringsförslag 1: Skaffa bra verktyg

Ibland ser jag konstruktionskonsulter som kostar 1000kr/timme som har fått en 19" skärm och en långsam dator för det är standardutrustningen hos oss. De har inte möjlighet att synka kalendern med telefonen och får inte automatiskt tillgång till snabba servrar.

Jag satt 30 minuter med chefen när jag ville ha 20” istället för 19” som kostar 50kr/månaden. Utan att få det. Jag satt 40 minuter med chefen för att övertala att jag behövde ett program att klippa och klistra i PDF-er, som kostar 100kr/månaden.

I min tidigare karriär som snickare förundrades jag alltid över förmannen som köpte snordyra Hiltimaskiner, specifika för varje tillämpning. Varje skruvdragare hade minst två batterier. Ibland 3. Det gick hur snabbt som helst att jobba med alla dessa verktyg. Roligt var det också.

Ge utvecklarna de verktyg de behöver utan att de ska behöva tjata om det. De ska använda sin energi på att utveckla era produkter istället!

Tillägg i efterhand: Idag har jag en härlig 24" skärm, en superbra Dell-laptop i aluminium, en roller-mouse, höj-och-sänkbart skrivbord, fria arbetstider, ny flashig Sony-Ericssontelefon. Allt är top of the line och varenda dag när jag kommer till jobbet och ser min arbetsplats blir jag glad och känner inspiration. Företaget satsar på mig och då vill jag satsa på företaget!

Image: Michelle Meiklejohn / FreeDigitalPhotos.net

Process improvement

Går jag på en fest i Linköping finns det alltid andra SAAB-are där, det bara är så. Det tar några timmar men förr eller senare börjar vi alltid diskutera möjliga processförbättringar. Vi diskuterar en stund om vad som är dåligt, hur det skulle kunna göras bättre och att vi är lite avis på Google och andra coola mjukvaruföretag. Detta kan vara tecken på två saker. 1) Antingen är vi väldigt asociala och vågar bara umgås genom att klaga på något vi har gemensamt, eller 2) Det finns väldigt många tänkande medarbetare som vill förbättra situationen, arbeta effektivare och få mer glädje i jobbet.

Som en miniserie av mjukvaruutveckling, projektstyrning, utvecklingsmiljö etc ska jag blogga varje dag i en månad om dessa diskussioner. Hjälper ni till att kommentera tankarna kan jag i mars sammanställa många fina förslag till chefen.

Förra året var jag på Toyota i Japan och tittade på helautomatiserade svetslinor, och helmanuella slutmonteringslinor. Jag frågade en minster på svenska ambassaden i Tokyo varför de inte automatiserar rubbet och ersätter alla arbetare med robotar. Svaret var briljant: "A robot doesn't think about the process."

Vågar inte stressa längre

Foto: Gunnar Lundmark/Scanpix

Det verkar inte bli någon överklagan av Kistadomen där en enskild konstruktör är den enda personen som straffas. Ingen kontrollant, chef, förman, tillverkare eller kvalitetsansvarig verkar vara ansvarig här inte.

Domen är lika intressant för mig som jobbar med säkerhetskritisk mjukvara som för säkerhetskritisk entreprenad: Designar jag rymningsskyddet fel i vårt obemannade flygplan ligger några städer farligt till. Om jag stressar och försöker ta genvägar för att projektet ska uppnå milstolpar är det alltså jag som straffas? När man skriver det så här känns det självklart men när projektledaren hävdar att produktledningen beslutat att ett första otestat program ska levereras om en vecka så är det väl deras ansvar om saker går snett? (fingerat exempel) Det hela ger mig en väldig olust att stressa i fortsättningen. Många studier visar att programmerare gör 30% fler fel om de är stressade, och kombineras detta med domen har jag väldigt mycket kött på benen att jobba vidare i normalt tempo hur mycket det än stormar runt omkring mig.

Snälla Gunnar Lundmark. Stäm mig inte för att jag använder din bild. Säg bara till så tar jag bort den =)

Checkpoint 30

Idag är ingen vanlig dag, idag är Anders födelsedag. Och ingen vanlig födelsedag, idag är Anders 30-årsdag. Känslan, jo alla frågar hur det känns så det är lika bra att jag nämner det, liknar känslan efter en lång och svår tenta: Jag har gått och oroat mig och bävat för att fylla 3-siffrigt och känt mig gammal, men nu är det klart och jag kan andas ut. Jag är där och behöver inte knorra mer om det. Men okej jag blev väldigt glad när kassörskan på systemet frågade om legitimation idag, så lite nojjig är jag fortfarande.