Razvoj softvera se u mnogim tvrtkama i dalje promatra kroz cijenu i rok isporuke. Dugoročna održivost, integracije i način na koji će sustav raditi kada se poslovanje počne širiti često se ne uzimaju u obzir u ranoj fazi odluke.
Izbor se svodi na najbržu i najjeftiniju opciju. Rok i cijena postaju glavni kriteriji za izbor poslovnog partnera. Sustav tada funkcionira u početnoj verziji i izgleda stabilno u svakodnevnom radu. Tim isporučuje funkcionalnosti bez većih zastoja, pa odluka djeluje ispravna.
Prve promjene najčešće prolaze bez ikakvih poteškoća. Nove funkcionalnosti se isporučuju, proizvod raste i čini se da je početna odluka bila ispravna. Problem nastaje tek kada jedan poslovni zahtjev počne zahvaćati više dijelova sustava. Funkcionalnost koja se nekada mogla razviti u nekoliko dana odjednom zahtijeva tjedne rada, jer razvojni tim najprije mora razumjeti postojeće ovisnosti prije nego što može sigurno napraviti promjenu.
Upravo tada počinje izlaziti na vidjelo stvarni trošak "jeftinog" razvoja. Integracije, održavanje i organizacija podataka postaju sve složeniji za promjene. Softver i dalje radi, ali svaka nova prilagodba zahtijeva više koordinacije, više testiranja i više razvoja nego prije. Trošak više nije u izradi novih funkcionalnosti, nego u vremenu i resursima potrebnima za promjenu onoga što već postoji.
Najskuplji softver nije onaj koji je najviše koštao na početku. Najskuplji je onaj kod kojeg svaka buduća promjena traje dulje i košta više nego što bi trebala.
Tehnički dug se najčešće ne pojavljuje kao svjesna odluka. On je posljedica prioriteta koji su postavljeni u ranoj fazi razvoja. Brzina isporuke i manji početni trošak generiraju ga u softverskom rješenju jer ono mora odmah funkcionirati.
Sustav se ne gradi prema tome kako će izgledati za godinu ili dvije, nego prema tome da što prije uđe u produkciju. Određene stvari rješavaju se “privremeno”, s idejom da će se kasnije doraditi. U praksi se taj “kasnije” često nikad ne ostvari.
Privremena rješenja počinju utjecati na način na koji se razvijaju nove funkcionalnosti. Jednostavne promjene zahtijevaju sve više zahvata u postojećem sustavu, jer struktura nije bila optimizirana za dugoročni razvoj.
Tehnički dug prestaje biti tehnički problem i postaje poslovno ograničenje. Svaka nova funkcionalnost nosi dodatni sloj kompleksnosti koji nije vidljiv u početku, ali se s vremenom akumulira. To nije jedna poslovna odluka, to je niz manjih kompromisa tijekom razvoja.
U tom trenutku ništa još ne izgleda problematično. Projekt ima rok, funkcionalnosti moraju biti isporučene, a najbrže rješenje čini se ispravnim izborom. Dokumentacija se odgađa, arhitektonski kompromisi prihvaćaju se kao privremeni, a integracije se razvijaju prema trenutačnim potrebama umjesto prema dugoročnom razvoju sustava. Nekoliko mjeseci kasnije, kada na projektu paralelno radi više timova, upravo ti mali kompromisi postaju zajedničko ograničenje koje usporava svaku novu isporuku.
SaaS projekt je u ranoj fazi razvoja imao za cilj brzo izaći na tržište. Razvoj je bio organiziran kroz vanjskog partnera kako bi se smanjilo vrijeme do prve verzije proizvoda.
Fokus je bio na tome da osnovna funkcionalnost radi kako bi se sustav mogao demonstrirati korisnicima i investitorima čim prije. Struktura koda i način implementacije nisu bili prioriteti. Njih se planiralo “preurediti” kada se proizvod stabilizira.
Takva situacija česta je kod SaaS proizvoda kojima je prioritet što brži izlazak na tržište. Vanjski razvojni partner omogućuje brzu isporuku prve verzije proizvoda, ali se dugoročne posljedice najčešće pokažu tek kada interni tim preuzme daljnji razvoj. Novi developeri više vremena troše na razumijevanje postojeće arhitekture nego na razvoj novih funkcionalnosti. Poslovna pravila raspoređena su kroz više modula, dokumentacija je nepotpuna, a i jednostavne promjene zahtijevaju zahvate na više mjesta. Razvoj koji je u početku bio brz postupno postaje ograničen načinom na koji je sustav izgrađen.
Tehnički dug tada postaje konkretno ograničenje daljnje brzine razvoja i načina na koji se može raditi.
Racionalniji pristup u ovoj fazi bio bi prihvatiti sporiji početni razvoj u zamjenu za jasno vlasništvo nad rješenjem. Čak i ako je početni trošak viši i izlazak na tržište sporiji, dugoročni održivi model razvoja projekta pravi je put za ovu SaaS kompaniju.
U početnoj fazi razvoja trošak održavanja je minimalan. Sustav je nov i jednostavan pa ga je lako mijenjati. Fokus je tada na isporuci novih funkcionalnosti. Kada sustav krene u stvarnu upotrebu, održavanje postaje dio svakodnevice. Rade se stalne prilagodbe postojećeg sustava kako bi mogao pratiti nove zahtjeve poslovanja.
Jedna promjena počinje dirati više dijelova sustava. Vrijeme potrebno za implementaciju raste, iako se sama funkcionalnost softvera značajno ne mijenja. Održavanje više nije skriveni trošak, postalo je stalni dio razvoja i izravno utječe na brzinu kojom se isporučuju nove funkcionalnosti.
U operativi se često dogodi da jedan tim vodi podatke u Excelu, dok drugi koristi zaseban sustav. Razlike nisu vidljive odmah. Kada broj podataka naraste, počnu se pojavljivati odstupanja.
Takva situacija zatekla nas je u projektu s Officium WasteManager platformom.
Prije početka suradnje operativni podaci i poslovni procesi razvijali su se godinama kroz Excel tablice i nekoliko međusobno nepovezanih alata. Isti korisnik ili operativni zapis često je postojao na više mjesta s različitim vrijednostima. Prije donošenja važnijih odluka zaposlenici su najprije morali utvrditi koji je podatak zapravo točan. Kako je broj korisnika i operativnih aktivnosti rastao, te su provjere iz povremenih iznimki postupno postale sastavni dio svakodnevnog rada. U tom trenutku najveći problem više nije bio sam softver, nego fragmentirani poslovni proces koji se godinama razvijao oko njega.
U ranim fazama razvoja sustavi softvera često se grade kao zasebne cjeline. U trenutku uvođenja, svaki adresira zaseban problem, bez šire slike kako će funkcionirati kompletan povezani sustav.
Integracije tada nisu prioritet. Bitno je da svaka cjelina radi samostalno i isporučuje vrijednost u svojem dijelu poslovanja. Povezivanje dolazi s protokom podataka između odjela i alata.
Tada se pojavljuje pravi problem. Sustavi koji su bili razvijeni ne govore istim jezikom. Podaci nisu usklađeni, a svaka promjena u jednom dijelu zahtijeva prilagodbu u više drugih dijelova sustava.
Integracije postaju razlog dodatnog rada i ograničenje za daljnji razvoj. Umjesto da ubrzavaju procese spajanjem sustava, one ih počinju usporavati. Svaka nova funkcionalnost mora proći kroz više točaka prilagodbe.
Svaka nova funkcionalnost zahvaća više dijelova sustava nego što se u početku očekivalo. Razvojni tim sve više vremena troši na razumijevanje postojećeg koda prije nego što uopće može započeti razvoj nove funkcionalnosti. Promjena koja je nekada utjecala na jedan modul sada zahtijeva izmjene u više servisa, integracija i poslovnih pravila. Projekt ne usporava zato što developeri rade sporije. Usporava zato što razumijevanje postojećeg sustava postaje najveći dio svakog novog razvoja.
U jednom e-commerce sustavu prodaja je koristila CRM alat, dok je skladište radilo u zasebnom sustavu za inventar. Podaci o dostupnosti proizvoda nisu se sinkronizirali u realnom vremenu, a naručeni artikli morali su se naknadno ručno ispravljati.
Proizvod prikazan kao dostupan u prodaji nije postojao na skladištu u zalihi. S rastom obujma poslovanja svakodnevne korekcije stanja postale su dio prakse, umjesto povremenih iznimki. Dio vremena koji je trebao biti uložen u obradu novih narudžbi odlazio je na ručne provjere i ispravljanje podataka.
Softverska rješenja ne dolaze do potpunog prepisivanja zbog jedne velike pogreške. Takve odluke posljedica su godina manjih kompromisa koji su postupno ugrađivani u sustav. Svaka nova prilagodba sustava riješila je trenutni problem, ali i povećala složenost budućih promjena.
Sustav dolazi do točke gdje je održavanje postalo preskupo, a brzina poslovanja znatno usporila. Problem više nije pojedina funkcionalnost nego način na koji je sustav izgrađen. Dodatna ulaganja u postojeće rješenje ne uklanjaju ograničenja i svaki novi razvojni ciklus troši sve više vremena i resursa.
Prepisivanje sustava nameće se kao poslovna nužnost. Cilj je uklanjanje ograničenja koja su se godinama akumulirala unutar postojećeg rješenja. Najveći trošak jeftinih odluka sa početka projekta pojavljuje se godinama kasnije. Sada je potrebno ponovno ulagati u sustav koji je već jednom plaćen.
Mnogi problemi opisani u ovom članku počinju puno prije prve linije koda. Dio njih nastaje već tijekom odabira razvojnog partnera i definiranja projekta. Više o najčešćim pogreškama u procesu čitajte u članku pogreške pri odabiru softver partnera.
Problemi u arhitekturi softvera ne nastaju od jedne odluke. Nastaju kroz niz kompromisa u ranoj fazi razvoja. Sustav tada radi i djeluje kao racionalan izbor zbog nižeg početnog troška.
Kako sustav raste, svaka nova promjena počinje zahtijevati više vremena i više koordinacije između dijelova koji nisu bili dizajnirani za dugoročni rad zajedno. Održavanje postaje dio svakodnevnog razvoja, a ne zasebna aktivnost.
U tom trenutku trošak više nije u razvoju novih funkcionalnosti, nego u održavanju postojećeg stanja. Integracije i promjene prestaju biti linearne i počinju ovisiti o postojećim ograničenjima sustava.
Najskuplji sustavi nisu oni koji su najviše koštali na početku, nego oni koji usporavaju rad kako poslovanje raste. Kada se to dogodi, dodatna ulaganja u isti sustav više ne uklanjaju ograničenja, nego ih samo produžuju.
Ako se ova tema odnosi na projekt koji planirate, možete nam se javiti izravno ili proći kroz project estimation flow za strukturiranu prvu procjenu.
