Digitalna transformacija i tehnički dug: Lekcije iz prakse

Autor: Nedžad Junuzović

Tokom svojih karijera, uvjeren sam, postoje trenuci kojih se i nakon mnogo vremena živo sjećamo. Za mene je jedan takav bio prvi sastanak razvojnog tima od kojih smo preuzimali posao. Sjećam se pitanja klijenta, snažnog britanskog naglaska: ,,Kako mislite treba vam tri mjeseca da razvijete samo jednu jednostavnu funkcionalnost? Radimo više od godinu dana i prvi put čujem da imamo nekakav tehnički dug? Zašto mi to do sada niko nije rekao?”.

Muk u zvučnicima trajao je nekoliko sekundi, dok ga nije prekinuo glas jednog od programera: “Upozoravali smo na to, ali svaki put je bilo važnije raditi nove funkcionalnosti i stizati rokove nego rješavati tehničke probleme“. Bio je to prilično kratak sastanak.

U pitanju je bila velika, internacionalna, kompanija koja je proizvodila alate za obradu metala. Odlučili su krenuti putem digitalne transformacije i prije gotovo dvije godine su krenuli sa realizacijom prvih projekata iz svog portfolia. Vjerujem da je dosta vas, koji se bavite poslom razvoja softvera, bilo u sličnoj situaciji.

Tehnički dug: Nevidljivi neprijatelj razvoja

Prije nego nastavim priču, vrijedi razjasniti pojam tehničkog duga. Tehnički dug označava akumulirane posljedice brzih, ali neoptimalnih tehničkih odluka donesenih radi brže isporuke funkcionalnosti. Poput pravog duga, on se s vremenom akumulira i ako se pravovremeno ne vraća svaki naredni razvoj postaje sporiji i teži, sve dok dug ne postane prepreka za dalji napredak.

Zašto je prvi tim imao probleme?

Bilo je sasvim jasno da se od novog tima očekivalo nastaviti sa projektom samo brže i bolje, do konačnog uspjeha u vidu razvijenog i isporučenog softverog rješenja sa hiljadama oduševljenih korisnika. Dvojica iskusnih softverskih inženjera, koji su se par sedmica prije mene priključili projektu, su već uradili tehničku analizu koda, evidentirali postojeće probleme, sve dokumentovali zajedno sa prijedlogom rješavanja identifikovanih tehničkih problema. Drugim riječima, evidentiran je nastali tehnički dug sa prijedlogom da se isti što je mogće prije rješava. Moj zadatak, kao voditelja projekta, je bio prije svega ispitati razloge zbog kojih je prvobitni tim uopšte došao u probleme kako bi mogli nastaviti dalje.

Nakon nekoliko razgovora sa ključnim akterima na projektu, uvida u kolaboracijske alate i ostale činjenice postalo je jasno, kao i nebrojeno puta do sada, da je problem sistemske prirode i ako mu se ne pristupi upravo na sistemski način to će i novi tim, vrlo brzo, imati isti problem sa neispunjenim očekivanjima.

Rezultat provedene analize nam je pokazao da je Product Owner bio pod pritiskom rokova isporuke projekta koje je postavljao marketinški tim kompanije. Posljedično, nastojeći da ispuni očekivanja marketinškog tima, vršio je dodatni  pritisak na članove razvojnog tima u smislu veće produktivnosti. Veći pritisak je uticao da se tim više fokusira na veći kvantitet razvijenih funkcionalnosti dok je tehnički kvalitet bio u drugom planu. Navedena praksa je pozitivno djelovala u smislu povećanja broja isporučenih funkcionalnosti što je svakako uticalo na manje odstupanje od utvrđenih rokova. Sa druge strane,  akumulacija tehničkog duga tokom vremena je posljedično zahtijevala sve više vremena za razvoj novih funkcionalnosti i otklanjanje grešaka. Što su odstupanja od rokova bila veća, to je rastao i pritisak na članove razvojnog tima a time i tehnički dug koji je doveo do situacije u kojoj dalji razvoj novih funkcionalnosti nije bio moguć. Ova sistemska dinamika prikazana je na našem dijagramu, koji jasno oslikava međuodnos pritiska, ponašanja i rezultata.

Kako smo riješili problem?

Svjesni strukture koja je generisala trend kašnjenja i uočene probleme u smislu komunikacije, ponašanja i očekivanja to smo na samom početku, po preuzimanju projekta, ključnim akterima predstavili potpuniju sliku čitavog sistema. Pod strukturom sistema ne mislimo samo na organizacionu strukturu projekta ili kompanije već na obrazac međuodnosa između glavnih elemenata sistema kako je to prikazano našim dijagramom. Struktura sistema može uključivati hijerarhiju i komunikacijske procese, ali također i uvjerenja, stavove, kvalitet softvera, načine donošenja odluka i mnoge druge faktore.

Nakon zajedničkog razumijevanja i otvorenog razgovora dobili smo priliku dizajnirati i implementirati novu softversku arhitekturu i plan za rješavanje tehničkog duga. Rezultat? Stabilniji razvoj, održiva brzina isporuke i zadovoljan klijent.

Važnost sistemskog razmišljanja

Ovaj slučaj naglašava važnost prepoznavanja uzroka problema na sistemskom nivou. Sistemsko razmišljanje često čini razliku između uspjeha i neuspjeha. Jer, kako kaže gospodin Han iz filma Karate Kid III: “If you think only with your eyes, you are easy to fool.

Ako prepoznate da vaš tim ili organizacija imaju slične izazove, pozivam vas da odabarete vrijeme za razgovor. Zajedno možemo istražiti rješenja i podijeliti iskustva.