Prevzem obstoječega sistema od prejšnjega izvajalca

Zakaj prevzem sistema ni le nadaljevanje projekta#

Podjetja pogosto podedujejo informacijski sistem, ki ga je zgradil nekdo drug. Prejšnji izvajalec je morda prenehal sodelovati, spremenil smer poslovanja ali preprosto ni več na voljo, sistem pa mora delovati naprej. Prevzem takega sistema je drugačna naloga kot razvoj na novo, saj morate najprej razumeti odločitve, ki so že vgrajene v kodo, podatkovno strukturo in infrastrukturo. Šele na podlagi tega razumevanja lahko načrtujete nadaljnje spremembe, brez tveganja, da nehote podrete nekaj, kar je do zdaj delovalo.

Če se prevzem loti brez temeljitega pregleda, se tveganja pokažejo šele kasneje, ko je popravek že drag in časovno potraten. Nedokumentirane odločitve, skrite odvisnosti med moduli in nejasna lastniška struktura podatkov so pogosti vzroki, da nadgradnja traja dlje, kot je bilo pričakovano. Zato prevzem obravnavamo kot ločeno fazo z lastnim ciljem: ugotoviti, v kakšnem stanju je sistem, preden se zavežemo k rokom ali obsegu nadaljnjega dela, in preden naročniku podamo kakršno koli konkretno zavezo.

Epix lahko projekt prevzame v celoti ali kot posamezen projektni sklop, odvisno od tega, kaj naročnik dejansko potrebuje. V nekaterih primerih gre za prevzem celotnega vzdrževanja in nadaljnjega razvoja, v drugih le za konkreten modul ali funkcionalnost, ki jo je treba dograditi ali popraviti. Enak pristop velja tudi za sisteme, ki jih je prejšnji izvajalec pustil nedokončane – pred nadaljevanjem dela najprej pregledamo, kaj že obstaja, in šele nato predlagamo naslednje korake ter realen obseg dela.

Pregled obstoječega stanja pred prevzemom#

Preden prevzamemo odgovornost za sistem, ga pregledamo na štirih ravneh: izvorno kodo, arhitekturo, infrastrukturo in podatke. Namen pregleda ni ocenjevanje dela prejšnjega izvajalca, temveč ugotoviti dejansko stanje, na katerem bo temeljilo nadaljnje delo. Brez tega pregleda bi vsaka ocena obsega, rokov ali tveganj temeljila na predpostavkah, ne na dejstvih, kar poveča verjetnost nesporazumov in nepričakovanih zapletov med samo izvedbo prevzema.

Rezultat pregleda je osnova za odločitev, ali je smiselno obstoječi sistem nadgraditi ali dele zgraditi na novo. Nekateri deli sistema so lahko dovolj trdni, da jih le razširimo, medtem ko so drugi deli morda pisani na način, ki onemogoča varno nadgradnjo brez večjega posega. To razlikovanje je pomembno za naročnika, ker neposredno vpliva na to, kateri deli dela zahtevajo več časa, pozornosti in previdnosti.

Pregled infrastrukture je še posebej pomemben, kadar sistem podpira storitve, ki morajo delovati brez prekinitev, na primer pri javnem sektorju ali sistemih, ki se uporabljajo na več lokacijah hkrati. Pregledamo, kako je infrastruktura postavljena, kje so morebitna ozka grla in ali obstajajo ločena okolja za razvoj, testiranje in produkcijo. Ugotovitve iz te faze vplivajo na to, kako previdno je treba načrtovati prehod nadzora nad sistemom na novo ekipo.

• Izvorna koda: struktura projekta, kakovost in berljivost, morebiten tehnični dolg
• Arhitektura: kako so sestavljeni posamezni deli sistema in kako komunicirajo med seboj
• Infrastruktura: kje in kako sistem teče, kakšno je okolje za produkcijo, testiranje in razvoj
• Podatki: struktura, obseg in stanje podatkov, ki jih je treba ohraniti ali preseliti

Primopredaja: dokumentacija, dostopi in lastništvo#

Izvorna koda in podatki so last naročnika, ne izvajalca, ki jih je razvil ali upravljal. To načelo velja tudi pri prevzemu: ne glede na to, kdo je sistem prej vzdrževal, imate kot naročnik pravico do vpogleda in prenosa vsega, kar sistem sestavlja. Primopredaja zato ni le formalnost, temveč korak, s katerim se zagotovi, da nadaljnje delo lahko poteka neodvisno od tega, kdo je sistem vzdrževal prej.

Del primopredaje je tudi dokumentacija: opis delovanja sistema, odločitve, sprejete med razvojem, in navodila za uporabo ali administracijo. Kjer dokumentacija manjka ali je nepopolna, jo je treba dopolniti, preden lahko nadaljnje delo poteka brez nepotrebnega tveganja. Enako velja za dostope in gesla do sistemov, strežnikov, administratorskih vmesnikov in storitev tretjih ponudnikov – vse to mora biti del uradne primopredaje, ne le neformalnega dogovora med ekipami.

Če primopredaja ni popolna, se lahko zgodi, da del sistema ostane nedostopen ali da nihče ne ve, kje in kako je nastavljen. To pomeni izgubljen čas in dodatno tveganje, še posebej pri sistemih, ki obdelujejo občutljive podatke ali podpirajo ključne poslovne procese. Zato pred začetkom dela vedno preverimo, ali so vsi dostopi, gesla in dokumenti dejansko na voljo, in šele nato načrtujemo naslednje korake prevzema.

Ločena razvojna, testna in produkcijska okolja#

Po prevzemu sistema vzpostavimo ali preverimo ločitev med razvojnim, testnim in produkcijskim okoljem. Sprememba, ki se preizkuša neposredno v produkciji, predstavlja tveganje za delovanje sistema in za podatke, ki jih uporabljajo dejanski uporabniki. Ločena okolja omogočajo, da se sprememba najprej razvije, nato preizkusi v pogojih, podobnih produkciji, in šele na koncu objavi, ko je preverjeno, da deluje, kot je predvideno, in ne povzroča stranskih učinkov.

V testnem okolju ne uporabljamo pravih osebnih podatkov, saj bi to pomenilo nepotrebno tveganje za zasebnost in skladnost. Namesto tega uporabljamo testne podatke, ki po strukturi ustrezajo pravim, ne razkrivajo pa dejanskih informacij o uporabnikih ali strankah. To je še posebej pomembno pri prevzetih sistemih, kjer morda ni jasno, kako so bili podatki doslej obravnavani in kdo je vse imel dostop do njih v preteklosti.

Vsaka sprememba gre skozi pregled in testiranje, preden je objavljena v produkcijskem okolju. Pri prevzetih sistemih je ta korak še pomembnejši, ker spremembe vplivajo na kodo, ki je ni napisala naša ekipa, zato je potrebna dodatna previdnost pri oceni, kako sprememba vpliva na preostali del sistema. S tem zmanjšujemo tveganje, da bi popravek na enem mestu povzročil novo napako na drugem, morda nepovezanem delu sistema.

Testiranje in zagotavljanje kakovosti#

Preden začnemo spreminjati prevzeti sistem, moramo vedeti, kako se dejansko obnaša. Testiranje zato ni le zadnji korak pred objavo spremembe, temveč tudi del uvodnega razumevanja sistema. S testnimi scenariji preverimo ključne poti skozi sistem, ugotovimo, kje se obnaša nepričakovano, in to uporabimo kot izhodišče za nadaljnje odločitve o tem, kaj je treba popraviti, nadgraditi ali povsem na novo zgraditi.

Pri prevzetih sistemih je koristno, da testiranje izvaja ekipa, ki ni sodelovala pri prvotnem razvoju, saj tako lažje opazi odstopanja, ki bi jih izvirna ekipa morda spregledala. Kjer je smiselno, vključimo neodvisen QA, ločen od razvojne ekipe, ki rezultate dela preverja z drugega zornega kota. To velja predvsem pri večjih sistemih, kjer napaka v enem delu lahko vpliva na delovanje več povezanih procesov hkrati.

Rezultat testiranja je osnova za prevzemno odločitev: ali sistem izpolnjuje dogovorjena merila in ali je pripravljen za nadaljnje spremembe. Merila za prevzemno testiranje se določijo vnaprej, skupaj z naročnikom, tako da je jasno, kaj mora sistem izpolnjevati, preden odgovornost zanj formalno preide na novo ekipo. S tem se izognemo nejasnostim o tem, kdaj je prevzem dejansko zaključen in nadaljnje delo lahko steče.

• testni scenariji za ključne funkcionalnosti sistema
• ročno testiranje uporabniških poti in robnih primerov
• avtomatizirano testiranje (Playwright, Cypress)
• API in regresijsko testiranje
• testiranje v okviru CI/CD
• prevzemno testiranje po vnaprej dogovorjenih merilih

Projektno vodenje pri prevzemu#

Pri večjih prevzemih določimo projektnega vodjo, ki je naročniku ena kontaktna točka za ves potek dela. Projektni vodja usklajuje ekipe, spremlja napredek in skrbi, da so odločitve, sprejete med analizo sistema, dejansko upoštevane pri nadaljnjem delu. To je še posebej pomembno pri prevzemih, kjer je treba usklajevati več področij hkrati – od tehničnega pregleda do primopredaje dokumentacije in dostopov, ki jih je treba pridobiti od prejšnjega izvajalca.

Skupaj z naročnikom določimo odgovornosti posameznih ekip, roke za posamezne faze in način komunikacije ter poročanja o napredku. Jasna razdelitev odgovornosti je pri prevzemu pomembnejša kot pri razvoju na novo, saj je treba usklajevati delo na sistemu, ki ga naša ekipa še ne pozna v celoti. Redno poročanje omogoča, da naročnik ves čas ve, v kateri fazi je prevzem in kaj sledi v naslednjem koraku.

Enak pristop uporabimo tudi, kadar prevzemamo nedokončan sistem, ki ga je prejšnji izvajalec pustil na pol poti. Pred nadaljevanjem dela pregledamo, kaj je bilo že narejeno, kaj manjka in kje so morebitne nedokončane ali začasne rešitve, ki jih je treba dokončati ali odstraniti. Šele na podlagi tega pregleda predlagamo realen načrt nadaljevanja, namesto da bi nadaljevali delo brez jasne slike o tem, na čem dejansko gradimo.

Po uvedbi: nadzor delovanja in SLA#

Prevzem sistema se ne konča z uspešno primopredajo. Po uvedbi lahko prevzamemo nadzor nad delovanjem sistema, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj. Obseg podpore se določi glede na posamezen projekt, saj se potrebe med sistemi zelo razlikujejo – nekateri zahtevajo stalen nadzor, drugi le občasne posodobitve in odzivanje na prijavljene napake. Zato pred začetkom podpore skupaj z naročnikom natančno opredelimo, kaj podpora vključuje in kaj ostaja izven njenega obsega.

Znotraj podpore napake in zahteve razvrščamo po štirih razredih, kar omogoča jasno prednostno obravnavo posamezne prijave in preprečuje, da bi se manjše napake obravnavale enako kot izpad sistema.

Odzivni časi za posamezen razred se dogovorijo v pogodbi o podpori in so prilagojeni kritičnosti sistema ter potrebam naročnika – univerzalnih odzivnih časov v urah ne objavljamo, ker se ti med projekti razlikujejo. Razvrstitev v razrede naročniku omogoča, da vnaprej ve, kako bo obravnavana posamezna vrsta težave, in da lahko to uskladi z lastnimi pričakovanji glede razpoložljivosti sistema.

Za prevzete sisteme je jasna razvrstitev napak še posebej koristna, saj pogosto ni vnaprejšnjega zaupanja v to, kako stabilen je sistem, ki ga je vzdrževal nekdo drug. S postopno klasifikacijo napak in rednim poročanjem naročnik dobi pregleden vpogled v dejansko stanje sistema, namesto da bi se zanašal zgolj na začetno oceno, kakšno je bilo stanje sistema ob prevzemu odgovornosti.

• Razred 1 – izpad: sistem ali ključni del ne deluje; obravnava ima najvišjo prednost
• Razred 2 – motnja: sistem deluje, posamezna funkcija ne; obravnava po dogovorjeni prednosti
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje; uvrsti se v naslednjo objavo
• Razred 4 – zahteva: sprememba ali nadgradnja; obseg ocenimo in uskladimo termin

Ekipa in kompetence za prevzem sistema#

Prevzem sistema pogosto zahteva širši nabor znanja, kot ga potrebuje razvoj enega samega modula na novo, saj je treba hkrati razumeti obstoječo arhitekturo, infrastrukturo in podatkovni model ter načrtovati nadaljnji razvoj. Zato projektne ekipe sestavljamo glede na to, kaj konkreten prevzem dejansko zahteva – od tehničnega pregleda kode do dolgoročnega vzdrževanja in podpore po uvedbi.

Ekipo za prevzem sestavljamo znotraj Epixa in njegove specialistične partnerske mreže, saj obseg znanja, potreben za analizo in nadaljnje delo na različnih sistemih, presega to, kar lahko zagotovi ena sama ekipa. To pomeni, da lahko za konkreten prevzem povežemo ljudi z ustreznim tehničnim ozadjem, ne glede na to, ali gre za spletno aplikacijo, poslovni informacijski sistem ali sistem, ki podpira javni sektor.

Znotraj Epixa in specialistične partnerske mreže so prisotni tudi certificirani strokovnjaki na področju oblačnih storitev, varnosti in projektnega vodenja, prav tako pa se pri delivery strukturi upoštevajo mednarodni standardi kakovosti in varnosti. Certifikatov in standardov ne pripisujemo Epix Group d.o.o. neposredno, temveč jih razumemo kot del širše mreže, iz katere sestavljamo ekipo glede na zahteve posameznega projekta prevzema.

• senior inženirji
• solution architecti
• tehnični vodje
• full-stack razvijalci
• DevOps in cloud inženirji
• QA in test automation inženirji
• projektni vodje

Kako se določi obseg in cena#

Cene prevzema sistema ne moremo določiti vnaprej brez pregleda, saj je odvisna od tega, kaj konkreten sistem dejansko potrebuje. Namesto splošnih cenikov zato predlagamo krajšo analizo, ki obseg dela razdeli na posamezne sklope, tako da je vsak sklop mogoče oceniti in izvesti ločeno. To naročniku omogoča, da vidi, na čem temelji ocena, in da po potrebi prilagodi obseg dela glede na razpoložljiva sredstva.

Obseg dela pri prevzemu je odvisen od več dejavnikov, ki jih preverimo že v fazi analize in ki neposredno vplivajo na to, koliko dela je pred nami.

Ti dejavniki niso enako pomembni pri vsakem prevzemu. Pri sistemih, ki se uporabljajo v javnem sektorju ali obdelujejo občutljive podatke, imajo zahteve glede varnosti in skladnosti pogosto večjo težo kot pri manjših notranjih orodjih. Zato pregled prilagodimo vsakemu sistemu posebej, namesto da bi uporabljali enak postopek ne glede na to, kaj sistem dejansko počne in kdo ga uporablja.

Cilj analize je, da naročnik pred odločitvijo o prevzemu ve, kaj lahko pričakuje – ne v smislu končne cene, temveč v smislu tega, kateri sklopi dela so potrebni, kateri deli sistema so tvegani in kje je smiselno začeti. S tem se izognemo situaciji, v kateri bi se obseg dela med izvedbo bistveno spreminjal glede na to, kar je bilo dogovorjeno na začetku sodelovanja.

• obseg funkcionalnosti in število uporabniških vlog
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• količina in stanje podatkov, ki jih je treba prenesti
• zahteve glede varnosti, revizijske sledi in skladnosti
• obseg testiranja in ali je potreben neodvisen QA
• raven podpore po uvedbi in dogovorjeni odzivni časi