Blanka golv och nystrykta skjortor

Mamma, pappa och jag firar min 30-årdag i Dubai och första hotellet blänker fint. Vi är i gamla delen av stan och har just vandrat längs kanalen och ätit bakad potatis på ett litet gårdscafé. Det stora nya Dubai får vänta några dagar, först ska historien inmundigas. Imorgon ska vi träffa Bison och Olof på lyxrestaurang :)

Kattvakt rockar!

Denna veckan har jag äran att leka med Donna hur mycket som helst. Vi är nämligen sambos. Hon sover i min famn och spinner så fort jag kommer genom dörren. Och jag har lärt henne att dricka mjölk ur mitt glas på bordet.

Förbättringsförslag 10: Skriv förbättringsförslag!

När jag startade miniserien om förbättringar var jag så full av fikagnäll om vad som sköttes dåligt på mitt företag att jag trodde att materialet skulle räcka till 30 inlägg. Efter de här nio känns det väldigt krystat. Jag har några idéer kvar om fokus på flöden, eller Kanban, som det heter på toyotaspråk, men ju mer jag tvingar mig att leta efter fel och brister, ju fler bra och fungerande egenskaper hittar jag. Det gör att jag ser ett slut på det dåliga och kan fokusera på att lösa det. Jag har ringat in grundproblemen nu.

Uppkomsten till förbättringsförslag är ofta en oförmåga att förbättra eller att förstå. Efter jag började skriva förslagen har jag pratat med process- och förbättringsmänniskor på företaget och fått mycket givande feedback. Exempelvis medhåll på verktygsutbildningen, där vi kan vara för målfokuserade för att hinna lära oss. Anders Weitman (Saabare) bjöd på en bra insikt angående informell dokumentation:

- Man bör skilja på "framåtriktad" och "bakåtriktad" dokumentation. Den förra används för att driva utvecklingen framåt, vara ett stöd vid analys och design, men behöver inte nödvändigtvis underhållas. Det sistnämnda är "facit" som beskriver så här är systemet kravställt, designat, implementerat och testat. Det ger en "vattenfallsbild" av hur systemet är konstruerat (den faktiska utvecklingen var förhoppningsvis mycket mer parallell). Vi har en historia av att blanda samman dessa två typer av dokumentation oh hantera allt på ett mycket formellt sätt.

För mig har det varit nyttigt att synliggöra mina problem. Jag har tvättat bort gnället från hjärnan och fått det till handbegripliga åtgärder. Den mentala förändringen som sker när tankar konkretiseras och analyseras i grupp är en viktig förbättring i sig!

Förbättringsförslag 9: Starta med the Man in the Mirror

Det finns många kvalitetshöjande åtgärder som varje person kan göra för sig själv. Till exempel:

• Gissa inte! Ta reda på ett korrekt svar när någon fråga något, eller när du själv behöver veta.

• Håll deadlines, eller förklara tydligt och tidigt när det inte går.

• Ha en uppdaterad lista med vad du jobbar med. Då ser övriga när du är klar med saker och behöver inte störa.

• Lär dig ditt arbete grundligt.

Om du levererar korrekta svar, kvalitativa lösningar och rätt saker i tid och slutar lägga tid på att gnälla eller ha onödiga problem kommer ditt arbete bli dubbelt så roligt och din lön skjuter i höjden.

Eller som Pop-kungen säger: “If you wanna make the world a better place, take a look at your self and then make a change!”

Förbättringsförslag 8: Lär känna de ”där uppe”

På lunchen igår satt jag och chefen och pratade om vad som är svårt i vardagsarbetet. Båda konstaterade att det kan vara toppstyrt och de där uppe lägger sig i och sabbar. En tredje lunchdeltagare frågade: "Vem är det ni menar, vilka finns där uppe? Jag känner dem och de tycker inte alls att de lägger sig i."

Om man tar hierarkihissen upp någon gång om året och hälsar på de ”där uppe” och lär känna dem och ser vad de fattar sina beslut på, får man själv mycket enklare att hjälpa dem med besluten och att acceptera besluten. Vet man inte vilka personerna är skapas ett främlingsförakt och the blame game startar underifrån. Många chefstips handlar om att gå ner på golvet för att förstå vad arbetarna har för problem. Ingvar Kamprad är känd för detta. Men mitt tips är att golvet går upp till cheferna för att förstå vad de har för problem.

Förbättringsförslag 7: Informell dokumentation

Inom säkerhetskritisk mjukvaruutveckling är dokument en lika viktig leverabel som programmen. Vi har Subsystem Specification, Subsystem Technical Description, Software Requirements Specification, Software Detailed Description, Software Test Description, Subsystem Test Description för att nämna några. Inget av de här dokumenten är (primärt) till för att hjälpa utvecklaren att göra ett säkert system. De är till för att övertyga kund om att det är ett säkert system. Därför är dokumentation för programmerare lika sexigt som rapportskrivande för poliser.

Införs informell dokumentation där utvecklaren kan skriva ner sina tankar och skisser, buggar och arkitekturändringar, så kan detta vara underlag för den formella dokumentationen. Utvecklaren känner då ett mervärde i att dokumentera och risken för tankefel minskas.

Självklart är det utvecklarens ansvar att hålla reda på vad han gör för något men sparas inte denna informationen så försvinner den vid personalomsättningar och kvar finns bara en formell dokumentation som beskriver hur systemet fungerar, inte varför det gör det eller vilka luckor eller buggar som finns.

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.