Uzroci kašnjenja u software projektima počinju prije faze razvoja. Počinju dok se sve tek slaže. Na početku sve izgleda jasno, postoji okvir što se želi napraviti i kako bi sustav trebao raditi. Sustav se još ne razlaže do kraja. Procesi su opisani jednostavno, bez varijacija koje postoje u stvarnom radu. Tada to još nije pogreška, već način da se dođe do dogovora.
Problem nastaje kada se ta pojednostavljena verzija počne koristiti kao osnova za razvoj. Pojavljuju se situacije koje nisu bile dio tog početnog opisa. Odluke više ne definiraju projekt, dio ponašanja sustava mora se izmijeniti putem.
Kako razvoj napreduje, projekt se postupno udaljava od početnog plana. Tijekom implementacije otkrivaju se poslovna pravila, iznimke i operativni scenariji koji nikada nisu bili dio početne specifikacije. Svaka nova spoznaja mijenja ranije pretpostavke, a razvoj se sve više prilagođava stvarnom načinu rada umjesto početnom planu.
Takvu smo situaciju više puta vidjeli tijekom razvoja poslovnih platformi. Primjerice, na projektu Officium WasteManager početni tijek poslovnih procesa izgledao je jasno definiran. Tek kroz radionice i svakodnevnu suradnju s operativnim timovima pokazalo se da različiti odjeli isti proces izvršavaju na različite načine, ovisno o lokalnim pravilima, vrsti korisnika i konkretnim situacijama na terenu. To nije bila pogreška u dokumentaciji, već dio poslovnog znanja koji nije bilo moguće u potpunosti prikupiti bez ljudi koji svakodnevno obavljaju taj posao.
Upravo zbog toga uzrok kašnjenja rijetko leži u samom razvoju softvera. Najčešće proizlazi iz nepotpunog razumijevanja svakodnevnih operativnih procesa prije početka implementacije, kako je objašnjeno u članku razvoj poslovnog software-a bez operativnog konteksta. Informacije izgubljene u toj fazi kasnije se vrlo teško i skupo nadoknađuju.
Zahtjevi se rijetko mijenjaju zato što su korisnici promijenili mišljenje. Mnogo češće mijenjaju se zato što početna definicija nije obuhvatila način na koji poslovanje stvarno funkcionira. Rani sastanci uglavnom su dovoljni da se postigne dogovor oko smjera projekta, ali rijetko otkriju sve operativne situacije koje će sustav kasnije morati podržati.
U početku to ne predstavlja problem. Svi imaju zajedničku sliku cilja projekta i dokumentacija djeluje dovoljno detaljno. Tek kada razvoj započne, isti zahtjev počinje značiti različite stvari različitim sudionicima projekta. Development tim ga promatra kao funkcionalnost sustava, management kao poslovni cilj, dok ga operativni timovi uspoređuju sa stvarnim načinom na koji svakodnevno obavljaju posao.
Sličnu smo situaciju imali tijekom razvoja platforme EUDoctor. Na početku je proces rezervacije termina izgledao relativno jednostavno. Kako je razvoj napredovao, postupno su se otkrivale razlike između država, regulatornih zahtjeva, dostupnosti liječnika, vrsta termina i načina provođenja konzultacija. Ti zahtjevi nisu nastali zato što se netko predomislio. Postali su vidljivi tek kada je sustav počeo odražavati stvarne procese rada u zdravstvu.
Zbog toga se timovi tijekom razvoja neprestano vraćaju na iste specifikacije i dokumentaciju. Ne zato što su bile loše napisane, već zato što su opisivale samo dio poslovne stvarnosti. Ono što je na početku izgledalo kao dovršen skup zahtjeva postupno se pretvara u niz dorada kojima se sustav usklađuje sa stvarnim načinom rada organizacije.
Tehnička analiza u ranoj fazi projekta izgleda stabilno. Sustav je opisan kroz komponente, tokove koji na papiru djeluju logično. Tek prilikom dublje razrade pojavljuju se ograničenja koja nisu bila vidljiva na početku.
Dio koji je u početnom planu bio jedna funkcionalnost kasnije se mora razbiti na više dijelova, ovisi o podacima iz drugih modula koji tada uopće nisu bili planirani u početnoj slici projekta.
Dijelovi sustava ne funkcioniraju neovisno. Izmjene donesene pod prisilom osiguravaju da se funkcionalnosti uopće mogu izgraditi. Tehnički model počinje utjecati na samu definiciju sustava.
Integracije se u praksi pokažu kao najveći izvor ograničenja. U počecima čine se kao standardni dio arhitekture. Povezivanjem sustava s vanjskim servisima i internim modulima, otkrivaju se novi potrebni koraci koji nisu bili dio početnog opisa.
Zamišljena direktna veza postaje niz međuzavisnih operacija. Brzina i predviđeni način implementacije se mijenjaju, jer se dio logike mora redefinirati.
Tehnička slika mijenja i sami redoslijed razvoja. Nova poslovna logika i tehničkih ovisnosti otkrivene tijekom analize mijenjaju prioritet među funkcionalnostima.
Početni plan i stvarnog redoslijeda izgradnje sustava nisu više u skladu, razvoj se prilagođava tehničkim ograničenjima. Sve to postaje urgentnije od punog opsega implementacije.
U razvoju software-a početne definicije rijetko ostanu dovoljne do kraja projekta. Pojavljuju se razlike između definiranog i onoga što sustav stvarno radi. Validacija tada postaje dio svakodnevnog rada. Svaka nova funkcionalnost vraća tim na ranije odluke.
U praksi se pojavljuju situacije koje nisu bile predviđene u početnom modelu. To nisu greške u fazi implementacije, to su razlike u načinu na koji se procesi stvarno odvijaju. Svaka od njih iziskuje promjenu, one proizlaze iz niza iteracija koje postupno usklađuju sustav s operativnim ponašanjem.
Validacija postaje mehanizam kroz koji se sustav prilagođava novim informacijama iz stvarnog okruženja. Svaka validacija mogla bi vratiti razvoj na stadij koji se smatrao stabilnim. Granice između razvoja software-a i provjere pomalo nestaju.
Male promjene u počecima izgledaju izolirano. Ponavljajući se kroz iteracije, one počinju mijenjati strukturu software-skog sustava. Ono što je bilo zamišljeno kao stabilan model, kroz iteraciju se postupno prilagodilo stvarnom ponašanju sustava u radu.
Kašnjenja software-skih projekata su akumulirana u pojednostavljenom načinu na koji se sustav definira u odnosu na stvarne radne procese.
Razlike se pojavljuju kroz izmijenjene zahtjeve, kroz nastala tehnička ograničenja u razvoju sustava, i iteracije koje nastaju kada sustav uđe u stvarne uvjete rada. Rokovi se pomiču zbog niza odluka koje nevjerodostojno prikazuju način rada sustava.
U toj ranoj fazi definicije sustava, nepovratno se gubi dio konteksta. Nepotpuna verzija prenosi se u način rada sustava, i postaje vidljiva kroz operativne posljedice; usporavanju rasta i stvaranju neefikasnosti u operacijama.
Tada projekt više ne prati početnu definiciju, već korekcije koje nastaju kroz stvarni rad sustava. Rokovi su probijeni sa naknadno usklađenim poslovnim realnostima.
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.
