top of page
Edument

Teknisk skuld - fem vanliga problem som uppstår




Ända sedan vi startade för 13 år sedan har vi hjälpt företag i olika storlekar och faser med deras mjukvara, arkitektur och val av teknik. Något som många av våra kunder har gemensamt är att de bär på en teknisk skuld och behöver hjälp. Du kanske har hört talas om begreppet och enkelt uttryckt kan man säga att programvaran är tungrodd där nyutveckling och produktförbättringar tar onödigt lång tid. Orsakerna kan vara många där kortsiktiga genvägar i mjukvaran har krävts på grund av exempelvis affärsmässiga och/eller strategiska beslut vid ett eller flera tillfällen. En verklighet som många företag lever i. Detta gör att det blir svårare för företaget att konkurrera på marknaden med den nu stelbenta mjukvaran. Så vilka problem brukar uppstå?


Fem vanliga problem vid teknisk skuld:

  • Procentandelen av tiden som läggs på underhåll och buggfixar är mycket hög, även om det finns en stor efterfrågan på nya funktioner.

  • Ingenjörer är rädda för att röra vissa delar av koden, eftersom det har blivit en "hemsökt kyrkogård" - en plats som folk har blivit vidskepliga över att förändra något i, det är för mycket risker involverade.

  • Svårt att anställa till er teknik och till ett rimligt pris, eftersom det är få som lär sig den tekniken från grunden nuförtiden. (Du har alltså en liten marknad med "experter med höga kostnader")

  • Teknikens passform för nuvarande behov har blivit svag -- teknikvalet matchade företagets behov för några år sedan, men verksamheten och/eller marknaden har förändrats, och nu ger inte tekniken rätt kapacitet (vilket innebär att man lappar ihop något halvt trasigt, ignorera problemet eller byter ut det)

  • Moralen faller eftersom personalen ser att deras karriärvägar minskar då deras kunskaper baseras på gammal teknik, och teamen med hög teknisk skuld tenderar andra utvecklare att undvika vid interna överföringar.


Känner du igen problemen? Då är det dags att se över er skuld och era alternativ för ta fram en strategisk plan. Finns det möjlighet för er att arbeta parallellt. Att samtidigt som ni arbetar bort den tekniska skulden utvecklar ni nya features? Eller är det kanske mest kostnadseffektivt att ta beslutet att bygga om mjukvara från början med ny teknik, arkitektur, dokumentation etc.?

0 kommentarer

Comments


bottom of page