Alla vill vara effektiva och produktiva, ständigt förbättra och höja kvalitet. Men ofta går man vilse i sin strävan och i många fall blir förändringar till försämringar eftersom man fokuserar på fel saker, på fel nivå och har fel angreppssätt.
Fundera några ögonblick på hur du på effektivast möjliga sätt skulle förbereda ett stort brevutskick. Framför dig på bordet har du allt du behöver för att genomföra uppgiften; kuvert, utskrivna brev, frimärken och en penna. Hur blir du snabbast klar?
Om du föreslår följande lösning är du i gott sällskap; först viker du alla breven, sedan stoppar du alla de vikta breven i var sitt kuvert, därefter förseglar du alla kuverten, sätter på ett frimärke på varje kuvert och slutligen skriver du rätt adress som sista moment. De flesta skulle välja det här angreppssättet eftersom vi intuitivt tror att upprepning av samma aktivitet ett stort antal gånger gör oss bättre på den aktiviteten och det tillåter oss att göra den allt snabbare. Det är visserligen sant, men det vi inte tänker på är tidsförlusten som uppkommer då vi tvingas att sortera, stapla och flytta runt halvfärdiga kuvert på bordet. I den här typen av processorienterat arbete spelar produktivitet i en delprocess väldigt liten roll i förhållande till produktiviteten av det totala systemet. Därför är den motsatta metoden, dvs. den kontraintuitiva metoden att helt färdigställa ett kuvert i taget, den överlägset snabbaste, trots att den vid en första anblick verkar ineffektiv. Varje extra moment, hur litet det än är, ackumuleras och blir i slutändan till ett stort slöseri med tid.
Precis som i kuvertprocessen är det intuitivt lätt att tro att det är mest effektivt att organisera ett projekt i avgränsade celler i vilka respektive medlemmar i lugn och ro kan jobba på med sitt eget utan att låta sig störas av projektet i stort. Ofta placerar man kravingenjörer, utvecklare och testare var för sig i tron att de ska göra sina respektive arbetsuppgifter så effektivt som möjligt och sedan lämna över sitt resultat till nästa station. En generell insikt inom det vetenskapliga forskningsområdet systemteori är att om man effektiviserar en delprocess i ett system så kommer effektiviteten i hela systemet obönhörligen att minska. Man måste se till hela systemet om man vill få till en verklig effektivisering och inte bara en suboptimering. Det är också ett fundament inom Lean i allmänhet och de allt mer vanliga agila metoderna i synnerhet.
Om systemet är ett IT-projekt så har det som mål att producera mjukvara som tillgodoser kunders behov och ger dem ett mervärde. Systemet måste alltså struktureras, organiseras och konfigureras så att målet uppnås på ett så effektivt sätt som möjligt. Ett IT-projekt kan aldrig bli effektivt genom att effektivisera enskilda rollers arbete utan måste innefatta ett holistiskt tillvägagångssätt. Hela projektet måste dela samma vision och veta mot vilka mål man arbetar. Man måste dra nytta av en tvärfunktionell organisation och involvera hela teamet och kunder på samma gång. Inte sällan hör man utvecklare säga att man inte vill ha kundkontakt, man vill hellre bli tillsagd vad man ska göra och så gör man det. Kravingenjörer å sin sida tycker ofta att de är experter på att ta reda på vad kunderna behöver och vill ha. " Vad blir vår roll om utvecklarna börjar prata med kunderna?"
Att fjärma roller och arbetsmoment från varandra tenderar att göra projekt dokumentstyrda, oavsett om man jobbar sekvensiellt eller iterativt. I stället för att hjälpas åt och gemensamt utveckla lösningar så kommunicerar man genom att "göra sin del" och lämna över "färdiga" specifikationer. Men effektiv systemutveckling handlar inte om att optimera en viss process eller ett specifikt arbetsmoment, utan att så snabbt som möjligt gå från vision och idéer till en körbar produkt, validera den och dra slutsatser om man är på rätt väg mot visionen.
De grundläggande stegen i en effektiv utvecklingsprocess ser ut så här. Utgå från en produktvision; vilka är problemen som ska lösas eller behoven som ska tillgodoses? Utifrån visionen, jobba med en idé som ska realisera visionen. Omvandla idén till en körbar produkt. Låt potentiella kunder interagera med produkten, mät och analysera hur den tas emot. Dra lärdom och bedöm om idén (och/eller visionen) behöver modifieras, göras om eller kompletteras. Upprepa tills produkten uppfyller visionen.
Att höja produktiviteten i en systemutvecklingsprocess innebär att alla förbättringar ska göras med avsikten att hastigheten genom loopen blir så hög som möjligt. En utvecklare som inte vill automatisera acceptanstester på grund av att "det saktar ner mitt arbete" har inte förstått poängen, utan upplever enbart att den egna produktiviteten minskar. I själva verket ökar den totala produktiviteten i projektet kraftigt i samband med att man gemensamt definierar acceptanskriterier med kunder och andra roller i projektet.
Framgångsrika projekt arbetar redan på det här sättet. När ska du börja?
//Mats Wessberg, Inceptive - ett Nohau företag
mats.wessberg@inceptive.se