Izvajalec je odšel, sistem je ostal. Kaj zdaj?

Sistem dela. Nihče pa ne ve, kako.

Tipičen primer. Distributer ima interni sistem za naročila in cenike. Pred šestimi leti ga je naredil zunanji razvijalec. Sodelovanje je teklo dobro: pokličeš, čez nekaj dni je popravljeno. Potem so odgovori začeli prihajati čez teden dni. Potem čez mesec. Potem nič več. Razvijalec se je zaposlil drugje ali zaprl s.p.

Sistem medtem dela naprej. Dokler nekega ponedeljka ne preneha delovati uvoz cen iz ERP. Ali pa poteče certifikat in brskalnik strankam pokaže opozorilo. Ali računovodstvo potrebuje novo polje na izvozu, ki ga nihče ne zna dodati.

To situacijo vidim vedno pogosteje. Pri podjetjih brez lastnih razvijalcev je skoraj pravilo, da se prej ali slej zgodi.

Kaj to pomeni za posel

Dokler sistem dela, je problem neviden. Tveganje pa raste vsak mesec.

• Razvoj zamrzne. Vsaka nova potreba ostane neizpolnjena. Ljudje začnejo delati okoli sistema, najpogosteje v Excelu.
• Vsaka zunanja sprememba je lahko usodna. Posodobitev ERP, nova različica strežnika, sprememba pri ponudniku plačil. Sistem, ki ga nihče ne vzdržuje, se na to ne prilagodi.
• Izpad traja dneve, ne ure. Ko se kaj ustavi, novi razvijalec najprej išče, kje je koda in kako jo zagnati. Šele potem začne popravljati.
• Varnost se tiho slabša. Knjižnice in strežnik se ne posodabljajo. Sistem z dostopom do podatkov o strankah postaja vse lažja tarča.

To ni tehnična malenkost. Sistem, od katerega je odvisna prodaja, je postal tveganje, ki ga nihče ne obvladuje.

Zakaj se to sploh zgodi

Razvijalec, ki je odšel, običajno ni naredil nič hudobnega. Problem je v tem, kako je bilo sodelovanje postavljeno na začetku.

• Koda je na njegovem računu. Repozitorij je na njegovem GitHubu ali na njegovem računalniku. Podjetje nikoli ni imelo kopije.
• Strežnik in domena sta na njegovo ime. Plačuje jih on in jih zaračuna naprej. Dostopa nima nihče drug.
• Zunanje storitve se plačujejo z njegovo kartico. Pošiljanje e-pošte, SMS, zemljevidi. Ko kartica poteče, funkcija tiho preneha delovati.
• Dokumentacije ni. Vse je bilo v njegovi glavi. Dokler je bil na voljo, to ni bil problem.
• Pogodba ne ureja lastništva. Ali sploh obstaja pisna pogodba, ki pravi, da so avtorske pravice na kodi vaše?

Nič od tega ni vidno, dokler razvijalec odgovarja. Ko neha, pride vse na dan naenkrat.

Prvih štirinajst dni: kaj preveriti

Preden kdorkoli popravlja karkoli, morate vedeti, kaj sploh imate. Ta seznam lahko naredite sami, brez razvijalca.

1. Koda. Kje je? Kdo je lastnik repozitorija? Ali imate vi kakršenkoli dostop?
2. Strežnik. Pri katerem ponudniku teče? Na čigavo ime je račun? Kdo plačuje?
3. Domena in certifikati. Kdo je registrant domene? Kdaj poteče? Se certifikat obnavlja samodejno?
4. Varnostne kopije. Ali obstajajo? Kje so? Je kdo kdaj preveril, ali se iz njih res da obnoviti sistem?
5. Zunanje storitve. Katere plačljive storitve sistem uporablja in s čigavo kartico se plačujejo?
6. Gesla in dostopi. Do baze, strežnika, administracije, ERP vmesnika.
7. Pogodba. Kaj piše o avtorskih pravicah in predaji ob koncu sodelovanja?

Če razvijalec še odgovarja

Prosite za predajo zdaj, dokler je še dosegljiv. Pošljite mu celoten seznam naenkrat, ne po delih. Večina razvijalcev, ki so odšli korektno, bo predala vse brez zapletov. Pogosto so celo veseli, da jim ni treba več skrbeti za stari sistem.

Če ne odgovarja več

Začnite pri tem, kar je na vaše ime. Če strežnik plačujete vi, je koda tam, tudi če repozitorija nimate. Pri spletnih sistemih (PHP, JavaScript, Python) je koda na strežniku berljiva in jo novi razvijalec lahko prevzame. Pri domeni in strežniku na tuje ime se obrnite na ponudnika, ki ima postopke za prenos. Za pogodbo in avtorske pravice se posvetujte s pravnikom.

Prevzem: kako novi razvijalec spozna sistem

Prvi refleks novega razvijalca je pogosto: "To je treba napisati na novo." Redko je res. Sistem, ki šest let poganja naročila, ima v sebi šest let poslovnih pravil, ki jih nihče ni zapisal. Če ga želite napisati na novo, jih morate najprej odkriti.

Prevzem, ki deluje, gre po korakih:

1. Zavarovati. Kopija kode na vašem računu, delujoča varnostna kopija baze, dostopi na vaše ime.
2. Zagnati lokalno. Razvijalec mora sistem zagnati pri sebi, ločeno od produkcije. Dokler tega ne zna, ne sme spreminjati ničesar.
3. Postaviti spremljanje. Da izveste za napako, preden jo javi stranka.
4. Zapisati, kar najde. Kako so sistemi povezani, kje so nevarna mesta, kaj se dogaja ponoči.
5. Šele nato spreminjati. Najprej majhne, da se preveri, ali razvijalec sistem res razume.

Pri srednje velikem sistemu je to nekaj tednov dela. Prvi teden je najpomembnejši, ker odpravi največja tveganja.

Obdržati ali zamenjati?

Po prevzemu je čas za to odločitev, ne prej. Sistem se splača obdržati, če:

• dela tisto, kar posel potrebuje, in ljudje ga uporabljajo,
• je tehnologija še podprta in se da posodobiti,
• je koda dovolj urejena, da vsaka sprememba ne podre česa drugega.

Zamenjava ima smisel, ko je tehnologija mrtva ali ko je sistem tako zapleten, da vsaka sprememba traja tedne. Več o tej odločitvi sem napisal v članku zamenjava ali nadgradnja sistema.

Kako to preprečiti naslednjič

Ne glede na to, s kom boste sodelovali naprej, naj bodo ta pravila del dogovora od prvega dne:

• repozitorij s kodo je na vašem računu, izvajalec ima samo dostop,
• strežnik, domena in zunanje storitve tečejo na vaše ime,
• gesla so v vašem upravitelju gesel, ne v izvajalčevi glavi,
• dokumentacija je del dela, ne dodatna storitev,
• pogodba jasno pravi, da so pravice na kodi vaše,
• vsaj ena oseba pri vas ve, kje je kaj, tudi če ne zna programirati.

Dober izvajalec bo na to pristal brez oklevanja. Če se upira, je že to dovolj zgovorno. Na kaj še paziti pri izbiri, sem zbral v članku kako izbrati izvajalca za razvoj. Kakšna je redna skrb za sistem po prevzemu, pa opisujem v članku o mesečnem vzdrževanju sistema.