Varför beslut i onboarding-fasen är viktigare än koden. Teknisk skuld beskrivs ofta som ett rent tekniskt problem. Vi talar om bristande kodkvalitet, stressade arkitekturval eller fel teknikval. Det är en bekväm förklaring, och ibland också en korrekt sådan. Men det är långt ifrån en fullständig förklaring.
I praktiken sätts många av förutsättningarna för teknisk skuld långt innan det handlar om kod. Den uppstår mycket tidigare, i onboarding-fasen. Den kommer från otydliga beslut, bristande ägarskap och outtalade antaganden som följer med in i arbetet. När detta senare visar sig vara det vi kallar «teknisk skuld» är den verkliga orsaken oftast både äldre och mycket svårare att åtgärda.
De flesta onboarding-program är uppbyggda kring ett tydligt och begripligt mål: att få igång systemen. Miljöer sätts upp, integrationer ansluts, användare kan logga in och go-live uppnås. Ur ett traditionellt projektperspektiv ser det här ut att vara en framgång.
Men under ytan finns det ett antal viktiga frågor som ofta förblir obesvarade:
Vem äger egentligen systemet när projektteamet drar sig tillbaka?
Vad betraktas som normal drift – och vad är avvikelser?
Vilka beslut fattades medvetet som tillfälliga och vilka var tänkta att vara permanenta?
Vilka antaganden låg till grund för förmågan att agera snabbt?
När dessa frågor förblir obesvarade innebär onboarding att det tillkommer osäkerhet utöver de nya systemen. Denna osäkerhet är osynlig till en början och skapar inte nödvändigtvis omedelbara händelser. Istället ligger den latent och dyker upp först senare, ofta i samband med förändringar, skalning, incidenter eller överlämningar mellan team.
I många onboardingprocesser dyker samma mönster upp om och om igen. Inte på grund av dåliga avsikter, utan på grund av tempo, press och skickliga människor som gör sitt bästa med begränsad tid.
Ofta är det långsiktiga ägandet inte tydligt definierat. Ansvaret är tydligt i själva leveransen, men vem som faktiskt har ansvaret efter onboarding förblir oklart. När utmaningar uppstår månader eller år senare läggs tid på att diskutera vem som äger dem snarare än hur problemet ska lösas.
I andra fall markeras besluten som tillfälliga från början. Genvägar, undantag eller provisoriska lösningar används för att hålla tempot uppe. Utan en tydlig plan för när dessa ska ses över riskerar «tillfälligt» att bli bestående.
Antaganden spelar en nyckelroll. Förväntningar om kapacitet, användningsmönster, supportmodeller och beroenden mellan integrationer behandlas ofta som allmän uppfattning, snarare än dokumenterade fakta. När antaganden inte skrivs ned förblir de inte flexibla – de hårdnar långsamt till verklighet.
Under tidspress uppstår också lösningar. Det som börjar som en praktisk lösning där och då slutar ofta med att definiera hur systemet används i flera år. Med tiden blir dessa lösningar normen, även om det aldrig var avsikten.
Slutligen ser vi ofta att onboardingprocessen är ensidigt fokuserad på go-live, medan det som händer efteråt förblir implicit. Optimering, stabilisering och överföring av ägande förutsätts snarare än planeras.
Detta är inte resultatet av dålig teknik. Det är ett naturligt resultat av att man rör sig snabbt utan att göra antaganden och beslut explicita.
När situationen så småningom kallas «teknisk skuld» är symptomen ofta bekanta. Det råder osäkerhet om vem som äger förändringar. Delar av systemet blir «riskzoner» som ingen vill röra vid. Manuella processer lever vidare utan att någon fullt ut förstår dem från början till slut. Förbättringar skjuts upp eftersom konsekvenserna är oklara.
Samtalen inleds med meningar som:
«Vi har alltid gjort på det här sättet.»
Vid det här laget verkar skulden vara djupt teknisk. För att betala av den krävs mycket mer än att städa upp i koden eller uppgradera plattformarna.
Många organisationer försöker ta itu med den tekniska skulden i ett sent skede, genom upprensningsinitiativ eller interna refaktoriseringsprojekt. Sådana åtgärder kan vara till hjälp, men de förhindrar sällan att samma utmaningar uppstår igen.
Den mest effektiva tidpunkten för att minska den tekniska skulden är tidigt, under onboardingfasen. Det kräver varken nya verktyg eller ett omfattande ramverk. I praktiken handlar det ofta om att göra några få grundläggande steg mer medvetna.
Øyvind Bredland - Team Lead Customer Onboarding, Cegal
Ägarskapet måste göras tydligt från början. Viktiga beslut bör dokumenteras, tillsammans med sammanhang och avvägningar. Antaganden ska skrivas ned och inte vara underförstådda. För interimsbeslut bör det finnas en tydlig förståelse för när - och hur - de kommer att omprövas. Och onboarding bör ses som början på verksamheten, inte slutet på leveransen.
I slutändan handlar detta om tydlighet.
Tekniken kommer att förändras. Kontexten kommer att förändras. Kraven kommer att utvecklas. Det som gör det möjligt för team att anpassa sig är inte frånvaron av skuld, utan närvaron av tydlighet. Tydlighet kring varför saker gjordes, vem som äger dem och vilka antaganden som fortfarande gäller.
Därför är teknisk skuld oftast inte teknisk. Det är resultatet av osäkerhet som introduceras tidigt och aldrig blir löst. Att minska den börjar sällan i koden. Det börjar med att vara tydlig i ett tidigt skede och villig att ompröva beslut innan de får genomslag.
Onboarding skapar förväntningar, vanor och gränser som lever kvar långt efter leveransen. När ägarskap, beslut och antaganden förblir implicita i det här skedet försvinner de inte. De dyker upp senare som friktion, osäkerhet och det som vi ofta kallar teknisk skuld.
Ju tidigare dessa saker klargörs, desto enklare blir allt som följer.