Kā notiek sistēmu uzturēšana pēc izstrādes?
Sistēmas izstrāde nebeidzas ar palaišanu. Uzturēšana ietver kļūdu labošanu, drošības atjauninājumus, serveru uzraudzību, integrāciju pielāgošanu, lietotāju atbalstu un jaunu funkciju attīstību. Jo svarīgāka sistēma uzņēmuma darbam, jo nopietnāk jāplāno uzturēšanas process un atbildības.
Pēc sistēmas palaišanas sākas tās reālā dzīve. Lietotāji strādā ar datiem, rodas jauni scenāriji, mainās likumi, ārējās sistēmas atjaunina API, pieaug datu apjoms un vadībai rodas jaunas atskaišu vajadzības. Tāpēc uzturēšana nav formalitāte, bet daļa no programmatūras dzīves cikla.
Uzturēšanu var iedalīt vairākos līmeņos. Pirmais ir tehniskā stabilitāte: serveri, datubāzes, rezerves kopijas, drošības atjauninājumi un veiktspēja. Otrais ir kļūdu labošana: situācijas, kur sistēma nestrādā kā paredzēts. Trešais ir izmaiņas un attīstība: jauni lauki, atskaites, integrācijas, automatizācijas vai lietotāju lomas.
Svarīga daļa ir uzraudzība. Ja integrācija ar ārēju sistēmu pārstāj darboties, uzņēmumam tas jāuzzina ātri, nevis pēc klientu sūdzībām. Profesionālā risinājumā tiek glabāti kļūdu žurnāli, paziņojumi un tehniskā informācija, kas palīdz atrast problēmu cēloni.
Uzturēšana dod drošību, ka sistēma nepaliek novecojusi. Uzņēmuma procesi mainās, un programmatūrai jāspēj pielāgoties. Tas ir īpaši svarīgi individuālām sistēmām, CRM, klientu portāliem un e-veikaliem, kas ir tieši saistīti ar ikdienas darbu vai ieņēmumiem.
Biežākā kļūda ir uzskatīt, ka pēc palaišanas sistēma vairs neprasīs ieguldījumus. Pat ja funkcijas nemainās, tehniskā vide mainās: pārlūkprogrammas, drošības prasības, API, serveru komponentes. Otra kļūda ir veikt izmaiņas bez testēšanas un dokumentēšanas. Mazas izmaiņas kritiskā sistēmā var radīt lielas sekas.
Uzturēšanas apjoms jāpielāgo sistēmas nozīmei. Nelielai iekšējai formai pietiek ar minimālu atbalstu. Sistēmai, kas apstrādā pasūtījumus, klientus un maksājumus, vajadzīgs skaidrs reakcijas process. Uzturēšanas izmaksas ietekmē sistēmas sarežģītība, lietotāju skaits, integrācijas, hostings, drošības prasības un attīstības temps.
Devera sistēmu uzturēšanu skata kā ilgtermiņa sadarbību. Tas nozīmē ne tikai labot kļūdas, bet arī saprast, kā sistēma kalpo uzņēmuma darbam un kur nākamie uzlabojumi var dot izmērāmu ieguvumu.
Uzturēšanas modelim jābūt skaidram jau pirms sistēmas palaišanas. Jāzina, kur lietotāji ziņo par problēmām, kā tiek noteikta prioritāte, kādos gadījumos tā ir kļūda un kādos — jauna prasība. Bez šādas kārtības katrs jautājums kļūst par steidzamu izņēmumu. Svarīgi atšķirt incidentus no attīstības darbiem. Incidents nozīmē, ka esoša funkcija nestrādā paredzētajā veidā. Attīstības darbs nozīmē jaunu funkciju, jaunu atskaiti vai procesa izmaiņu. Šī atšķirība palīdz plānot budžetu un reakcijas laiku. Regulāri jāveic arī sistēmas veselības pārbaude. Tajā var iekļaut veiktspēju, kļūdu žurnālus, datubāzes apjomu, neizmantotas funkcijas, lietotāju tiesības un drošības atjauninājumus. Šāda pārbaude palīdz novērst problēmas pirms tās kļūst kritiskas. Uzturēšana ir arī zināšanu saglabāšana. Ja sistēma attīstās vairākus gadus, jāuztur dokumentācija par integrācijām, datu struktūru un būtiskiem biznesa noteikumiem. Tas samazina atkarību no atmiņas un padara nākamos uzlabojumus ātrākus.
Ieviešanas plānā jāiekļauj ne tikai izstrāde, bet arī uzņēmuma iekšējā sagatavošanās. Jānosaka procesa īpašnieks, jāapstiprina datu struktūra, jāizvēlas lietotāji testēšanai un jāvienojas, kā tiks pieņemti lēmumi par izmaiņām. Bez šīs pārvaldības pat tehniski labs risinājums var kļūt sarežģīti ieviešams. Pēc palaišanas jāparedz mērīšana un uzlabojumi. Sistēma jāvērtē pēc tā, vai tā samazina manuālu darbu, kļūdas un neskaidrības, nevis tikai pēc tā, vai funkcijas ir izstrādātas. Lietotāju jautājumi, kavētie procesi un apietie soļi ir vērtīga informācija nākamajām izmaiņām. Devera individuālas programmatūras projektos šādu pieeju izmanto, lai sistēma nebūtu vienreizējs IT projekts, bet ilgtermiņa darba instruments uzņēmumam.
Uzturēšanas plānā vēlams noteikt arī prioritāšu līmeņus. Kritiska problēma ir tāda, kas aptur darbu vai ietekmē klientus. Vidēja problēma traucē procesam, bet tai ir pagaidu risinājums. Zema prioritāte var būt neērtība vai neliels uzlabojums. Šāda klasifikācija palīdz abām pusēm saprast reakcijas kārtību. Sistēmas attīstības darbus ir lietderīgi apkopot periodiskos uzlabojumu ciklos. Lietotāji iesniedz idejas, vadība izvēlas prioritātes, izstrādātājs novērtē ietekmi, un izmaiņas tiek ieviestas kontrolēti. Tas ir daudz drošāk nekā nepārtraukta mazu izmaiņu veikšana bez kopēja plāna.