Orden som kan signalera problem – del 1

Det finns vissa vanliga ord och begrepp som vi alla använder, men som också kan fungera som varningstecken som signalerar problem. Problemen kan sedan vara både synliga och osynliga och är i vissa fall så vanligt förkommande att personer som fokuserar på annat bara ser situationen som normal eller oundviklig. Jag och andra med mig kanske upplever samma saker som frustrerande , knasiga eller allvarliga och i så fall något som bör åtgärdas.

I den här och några artiklar till framöver tänkte jag ta sådana ord och beskriva vad det är för problem som kan dölja sig där bakom orden. Jag hoppas att vi alla kan hjälpas åt att hålla utkik och fundera på. På så vis kan vi tjäna både tid och pengar och dessutom ha roligare på jobbet.

Jag tänkte ta ett ord i taget, så det lär komma flera artiklar.

Då kör vi:

”Överlämning”

(engelska: ”handover”)

Överlämningar är inget konstigt alls, kan tyckas. När en person, en grupp, en avdelning eller ett helt företag jobbat klart med något och det ska tas över av andra så sker en överlämning. Det kan handla om så vitt skilda saker som ansvar, dokument, processer, produkter och system. Överlämningen kan också innefatta en överenskommen gränsdragning. Det blir ändå lätt problem.

När överlämningar fungerar som de brukar

Om en överlämning fungerar bra så är det väl bara bra  – eller?
Jo, men när när överlämningar fungerar normalt så brukar det ändå kunna dyka upp extra arbete. Det arbetet är ofta inte självklart, utan kunde ha undvikits, minskats i omfattning eller i alla fall planerats och förberetts bättre om överlämningarna inte var ett område med så mycket fallgropar.

När vi kikar närmare i detalj så kan problemet bero på flera olika saker. Det kan handla om att något inte kommunicerades alls eller inte kommunicerades tillräckligt tydligt – även om det var på det överenskomna sättet – och därför måste saker diskuteras och hanteras efteråt. Det kan också handla om större saker som att något visade sig inte riktigt vara klart för överlämning (enligt vems definition av ”klart”?), eller saker som inte gjorts alls för att det funnits missförstånd. Även här uppstår extra arbete för att lösa knutarna. Extra arbete eller fördröjningar medför ofta frustration eller negativa stämningar, vilket sedan i sin tur kan påverka saker som inte alls ingick i den lite misslyckade överlämningen.
Själva överlämningen tar också tid, även om den går bra. Saker måste diskuteras, det bokas möten och förklaras. Sedan kanske den mottagande parten inte har rätt personer på plats, inte har tid att ta emot informationen eller inte har samma prioriteringar. Då ska saker diskuteras igen, bokas om och kanske repeteras. I vissa organisationer är det dessutom lättare att undvika kritik från sin närmaste chef genom att överlämna en produkt med problem än att tidigt ta upp risker.

Det är vanligt att överlämningar som anses normala ändå medför extra arbete och en del frustration eller friktion. Aj då.

När överlämningar fungerar dåligt – och det är vanligt

Ibland uppstår större problem vid just överlämningar och det brukar kunna visa sig extra tydligt inom mjukvaruutveckling. En viktig faktor i den agila revolutionen som blev allmänt känd för ganska många år sedan var att minimera behovet av överlämningar genom att arbeta tillsammas tidigare.
Jag tänkte ge ett exempel ur verkligheten och sedan nämna några områden där jag sett att överlämningar kan skapa problem. Jag är rätt säker på att du som läser det här har egna exempel också.

Ett exempel ur verkligheten (anonymiserat av hänsyn till de inblandade)

Chefen ’C’ kom in som nyanställd för att leda en helt ny satsning i ett mycket tekniktungt bolag. Hen ansåg att just hens nya avdelning var den viktigaste och den därför skulle den döpas om och heta det som hela bolaget redan hette. Förvirring uppstod.
Bolaget hade kommit ganska långt med sin organisation och sina agila metoder och hade på det hela taget bra flyt i kravflöden, kvalitet och delegerat ansvarstagande, men nu skulle ju en ny avdelning byggas, så C ville ändra på en del saker. C byggde om sin avdelning så att roller, ansvar och arbetssätt fungerade efter hens egna synsätt. Det fungerade inte så bra tillsammans med det som redan fanns runt omkring. I samtal med bolagets utvecklingschef visade det sig att C inte hade några större kunskaper om systemutveckling eller agila metoder, men C var ändå säker på sin sak när hen sa till utvecklingschefen att:

”Vi bestämmer hur allt ska fungera och se ut.
Sedan lämnar vi över till er, så får ni
på tekniksidan ’programmera’ det.”

Utvecklingschefen försökte förklara att det inte alls var så som bolaget beslutat att arbeta i andra sammanhang och att det skulle innebära en mycket stor förändring  – en förändring som utvecklingschefen inte alls trodde på eller ville ställa sig bakom. C stod på sig och fortsatte att driva sin linje i några månader. Sex månader senare visade det sig att ledningen varit mycket undrande över C:s nya linje ett tag och att det sättet att arbeta dessutom inte alls fungerade som tänkt. C fick sparken. 60 personer fick nu uppleva ytterligare en omorganisation. Ytterligare ett par månader senare och efter massor av arbete och stora kostnader såg organisationen än en gång annorlunda ut och flödena tog fart igen.

Var felet låg? Framförallt var problemet att att C ville arbeta i separerade grupperingar som sedan skulle göra ”överlämningar” till varandra när något var ”klart”. Inom systemutveckling är det här arbetssättet direkt olämpligt, men det visste inte C.

Några områden där överlämningar kan skapa problem

Överlämning av krav

Det här är vad exemplet jag tog upp här ovanför handlade om. Frågan som är relevant att ställa är om det går att låta utföraren vara delaktig redan under framtagning av krav och för kravägaren att vara delaktig vid utveckling och implementation. Varför inte? Varför ska kravformulering och -uppföljning vara separata delar, hanterat av separata individer, istället för att ses som en del av den kedja som ska resultera i en bra slutprodukt?

Det brukar bli bättre om kraven ses som en integrerad, iterativ del av utvecklingen/framtagningen av en produkt eller lösning. Det gör att parterna får insikt i och förståelse för varandras vardag, vilket underlättar allt samarbete – även rent mänskligt. Behovet av synkmöten, statusrapporter, efterkontroller och felrättningar minskar kraftigt.

Rent praktiskt brukar det också betyda att det inte slösas lika mycket tid och pengar på att ta fram kravbeskrivningar som ändå visar sig vara otillräckliga, felsyftande eller orealistiska och på samma sätt gör det att kraven inte missförstås i samma grad under utveckling och att olika krav inte prioriteras felaktigt i förhållande till varandra under utveckling och implementation.

I det här fallet är överlämningar något vi helst vill bygga bort eftersom deras blotta existens inidkerar att arbetssätten inte är så bra som de skulle kunna vara.

Överlämning av källkod

Det här är en ständig källa till diskussion. Oavsett erfarenhet, kunskapsnivå, kodstandarder och teknikval så har varje utvecklare ett sätt att se på den kodbas som hen jobbar i eller ansvarar för. Det må vara rätt eller fel, men den personen har en tanke med att göra som den gör. Medvetet eller omedvetet så har den personen gjort ett antal val.

Den som inte är insatt i systemutveckling kanske tror att om alla bara skriver sin kod ”rätt” så behövs ingen överlämning när någon annan sedan ska ta över arbetet med en viss kodbas. I verkligheten blir källkoden aldrig perfekt och aldrig klar. Tekniska vägval, prioriteringar, åsikter, omständigheter och kunnande gör att det alltid finns saker att förklara för varandra; saker som annars kan skapa problem som tar tid att reda ut.

Samarbete under en tid är bäst vid överlämningar av källkod, men om det inte går att få till eller om överlämningen till nästa person inte är ovanligt bra så kommer den som tar över källkoden att få lägga mycket tid på att läsa, tolka, tänka och försöka förstå.

I det här fallet går överlämningar inte alltid att undvika, även om det vore bra. Då får vi samarbeta desto mera istället och se till att göra mycket väl genomtänkta överlämningar.

Överlämning av ansvar i allmänhet

Här kan det väldigt lätt bli fel. Menar vi organisatoriskt eller juridiskt ansvar? Rollbaserat eller delegerat ansvar? Otydlighet är lätt att skapa men svårt att bli av med. Vet den som tar över ansvaret vad det innebär? Är det verkligen tydligt?

Ska den som tar över ansvaret sköta saker på samma sätt som tidigare eller kan den personen se annorlunda på saker och ting men ändå ta över ansvaret, göra på ett annat sätt och ändå uppnå målet?

Tror den som tar över ansvaret att det bara handlar om ett teoretiskt ansvar (kallas även ’det yttersta ansvaret’), utan att något måste göras rent praktiskt? Det kan visa sig bli väldigt tokigt om något oförutsett händer.

Vet alla andra att det skett en förändring i ansvarsfördelningen och att det kan komma att innebära förändringar?

Eftersom allt inte går lika lätt att överlämna, vad är det som får stå tillbaka? Vad är det som inte blir sagt och inte gjort? Vilka delar av ansvaret tas över utan någon välgjord överlämning eller utan att mottagaren av ansvaret ens kände till det?

Hur många saker som helst kan gå tokigt här och det finns all anledning att tänka till och inte slarva.

Överlämning av driftsansvar

Om de som ska installera och drifta en mjukvara eller ett system inte har haft insyn och varit delaktiga under utvecklingen så kan det gå illa.

• Vad betyder det att mjukvaran eller systemet ”fungerar”? Vad är det den ska göra, hur gör den det? Hur dåligt får den fungera utan att det anses som ett fel?
• Hur förväntas den bete sig? Vad är att anse som normalt i olika situationer, till exempel vid hög last eller fel i andra system?
• Vad är ”hög” last,förresten? Vad är maxgränsen i olika avseenden för just det systemet? Om maxgränsen inte överskrids så finns det säkert ändå en nivå där saker inte fungerar så bra längre.
• Hur reagerar mjukvaran på problem och fel? Hur yttrar det sig? Går det ens att se? Av vem?
• Hur lätt är den att drifta egentligen? Hur kan den övervakas, automatiseras och spridas?
• Innebar överlämningen att driftsansvaret innefatta viss support? Var det tydligt? Vilken sorts support och till vem?
• När problem uppstår (inte ’om’), hur ska det hanteras och vilka behöver vara inblandade eller bli informerade? Hur var det med ansvaret, var det ”överlämnat”?
• Hur säker är den och hur fungerar säkerheten i den? Vem har ansvar för det som händer när säkerhetsproblem uppstår?

Hur vore det om vi istället för att överlämna driftsansvaret i ett sent skede ser till att de som ska drifta systemet också är involverade från början? Det vore det allra bästa och skulle i så fall kraftigt minska behovet av överlämningar och akuta diskussioner senare. Dessutom brukar det visa sig att det kan spara mycket tid och pengar genom att vi får färre sena ändringar, minskad mängd fel under drift och minskad arbetsinsats för att drifta slutprodukten.

Slutligen

”Lämna över” och ”överlämning” är vanliga ord i vardagligt språk, men vi bör tänka till när vi hör någon använda dem. Ibland vill vi kanske göra så mycket överlämning som möjligt, och göra det så bra som möjligt, medan vi i andra sammanhang istället helt bör bygga bort behovet av överlämningar.

När jag själv hör någon säga ”överlämning” känner jag alltid att riskradarn börjar snurra och jag vill ställa många frågor. Jag brukar också vara lite försiktig med att ta över ansvaret för något som ska starta efter en ”överlämning” – om jag inte fått vara med mycket tidigare i processen förstås, eller om jag haft möjlighet att ställa massor av frågor.
Förresten, det där med att ”ta över ansvaret”, exakt vad skulle det innebära? Nu var vi där igen.

Vi behöver förstå när överlämningar är en bra idé och när det inte är det.
Vi ska inte heller utgå från att överlämningar är oundvilkiga faktum
i samarbetet mellan människor, team, avdelningar och företag.

I nästa artikel i den här serien kommer jag att ta upp ett nytt ord att se upp med.

Lycka till!

/Björn