Neveiksmīgs problēmas risinājums nenozīmē, ka komanda ir izvēlējusies nepareizu tehnoloģiju vai strādājusi nekvalitatīvi. Bieži cēlonis ir agrāks. Tā var būt neprecīzi definēta problēma, nepilnīgi pieņēmumi par lietotāju vajadzībām vai nepietiekami pārbaudīti integrāciju riski.
IT projektos vērtīgākā retrospektīva sākas nevis ar vainīgā meklēšanu, bet ar jautājumu, kurā lēmuma punktā sistēma sāka novirzīties no sākotnējā mērķa. Atbilde palīdz novērst līdzīgus incidentus nākamajā izlaidumā.
Neveiksmi jāpadara izmērāmu
Frāze risinājums nestrādā ir pārāk vispārīga, lai to varētu izmantot diagnostikā. Vispirms jānosaka, kas tieši nav sasniegts:
- funkcija tehniski nedarbojas;
- lietotāji funkciju neizmanto;
- sistēma neatbilst veiktspējas prasībām;
- uzturēšanas izmaksas pārsniedz plānoto budžetu;
- integrācija ar citu sistēmu rada kļūdas;
- piegāde kavējas vai rada jaunus drošības riskus.
Šie scenāriji prasa atšķirīgu analīzi. Piemēram, stabila, bet neizmantota funkcija ir produkta un lietojamības problēma, nevis infrastruktūras incidents. Savukārt bieži 500. kļūdas paziņojumi liecina par nepietiekamu kļūdu apstrādi, jaudas plānošanu vai integrācijas testēšanu.
Salīdzini plānoto ar faktisko
.
Pirms projekta sākuma jādefinē mērāmi veiksmes kritēriji, piemēram, atbildes laiks, konversijas rādītājs, kļūdu īpatsvars, lietotāju aktivitāte vai manuālā darba samazinājums. Ja šādu kritēriju nav, pēc ieviešanas nav objektīva pamata secināt, vai problēmas risinājums ir izdevies.
Noderīgi dati retrospektīvai ir:
- serveru un lietotnes žurnāli;
- kļūdu monitoringa dati;
- lietotāju atbalsta pieprasījumi;
- analītikas notikumi;
- izmaiņu vēsture repozitorijā;
- incidentu laika līnija.
Fakti palīdz atšķirt sakni no simptoma. Lēna sistēma, piemēram, var būt nevis datubāzes problēma, bet neefektīvs API pieprasījums, kas tiek atkārtots katrā lietotāja darbībā.
Neskaidras prasības rada kļūdainu produktu
Viena no biežākajām kļūdām ir risinājuma izstrāde, pirms komanda ir precīzi sapratusi problēmu. Prasība jāizveido ātra pieteikšanās forma nepasaka, ko nozīmē ātra, kādi dati jāvalidē, kā notiek kļūdu apstrāde un kas notiek sakaru pārrāvuma gadījumā.
Laba prasība apraksta ne tikai funkciju, bet arī kontekstu:
- kas ir lietotājs;
- kādu uzdevumu viņš mēģina paveikt;
- kāds rezultāts ir sagaidāms;
- kādi ir ierobežojumi;
- kā tiks mērīta kvalitāte.
Ja sistēma apstrādā sensitīvus finanšu datus vai lēmumus, prasību neprecizitāte var radīt arī lietotājam būtiskas sekas. Piemēram, pakalpojumam, kas saistīts ar kredīts ar sabojātu kredītvēsturi, ir svarīgi saprotami validācijas paziņojumi, korekta datu apstrāde un skaidri definētas lietotāja plūsmas.
Validē pieņēmumus pirms izstrādes
Pirms pilnas funkcionalitātes izstrādes vērts izmantot prototipu, klikšķināmu maketu vai minimālu funkcionālu versiju. Tas ļauj ātri pārbaudīt, vai izvēlētā plūsma lietotājam ir saprotama un vai komanda interpretē prasības vienādi.
Šajā posmā īpaši svarīgi ir negatīvie scenāriji. Jānoskaidro, kas notiek, ja lietotājs ievada nepareizus datus, ja ārējais API neatbild, ja sesija beidzas vai ja darījums tiek pārtraukts pusceļā. Tieši šie gadījumi bieži netiek iekļauti sākotnējā plānā, bet vēlāk rada lielāko atbalsta pieprasījumu apjomu.
Integrācijas atklāj slēptos riskus
Mūsdienu lietotne reti darbojas izolēti. Tā izmanto maksājumu vārtejas, autentifikācijas pakalpojumus, piegādātāju API, e pastu, analītikas rīkus un mākoņpakalpojumus. Katrs ārējais komponents palielina kļūmes virsmu.
Tipisks kļūdains pieņēmums ir uzskatīt, ka veiksmīgs savienojums testvidē garantē stabilu darbību produkcijā. Reālā vidē atšķiras datu apjoms, tīkla aizture, piekļuves tiesības, sertifikāti, limitēšanas noteikumi un ārējo pakalpojumu pieejamība.
Testē kļūmes, ne tikai rezultātu
Integrācijas testos jāmodelē ne tikai veiksmīga atbilde, bet arī:
- API taimauts;
- nepilnīga vai negaidīta atbilde;
- piekļuves atslēgas derīguma beigas;
- pieprasījumu limitu pārsniegšana;
- dublēts pieprasījums;
- daļēji pabeigts darījums.
Sistēmai jāspēj kontrolēti degradēties. Tas nozīmē, ka nebūtiska funkcija var īslaicīgi nebūt pieejama, taču kritiskais process turpina darboties vai lietotājs saņem saprotamu paziņojumu.
Šāda pieeja ir svarīga arī plašāku infrastruktūras traucējumu laikā. Mācības pēc augusta vētras parādīja, ka elektroapgādes un sakaru pārrāvumi var vienlaikus ietekmēt arī kritiskus finanšu pakalpojumus. IT risinājumam jāparedz šādi atkarību ķēdes scenāriji.
Tehniskais parāds palielina kļūmju cenu
Tehniskais parāds nav vienkārši vecs kods. Tas ir apzināts vai neapzināts kompromiss, kura uzturēšanas izmaksas pieaug ar katru nākamo izmaiņu. Piemēram, īslaicīgs risinājums bez testiem var ļaut ātri piegādāt funkciju, taču vēlāk sarežģīt kļūdu labošanu un regresijas testēšanu.
Tehniskā parāda pazīmes ir viegli atpazīstamas:
- viena izmaiņa prasa rediģēt daudzus nesaistītus moduļus;
- komanda baidās izvietot jaunas versijas;
- kļūdu labojumi rada regresijas;
- dokumentācija neatbilst sistēmas darbībai;
- novecojušas bibliotēkas vairs nesaņem drošības atjauninājumus.
Parādu iekļauj piegādes plānā
Tehnisko parādu nevar efektīvi novērst tikai kad būs brīvs laiks. To jāplāno līdzās jaunai funkcionalitātei, piemēram, paredzot regulārus refaktorēšanas uzdevumus, testu pārklājuma uzlabojumus un atkarību atjauninājumus.
Drošības riskiem šeit ir īpaša nozīme. Automatizēta aizsardzība var būt noderīga, taču tā nav aizstājējs pārdomātai arhitektūrai, piekļuves kontrolei un incidentu procesiem. To labi ilustrē situācijas, kad kiberdrošības MI prasa pauzi, jo automatizācijai nepieciešama uzraudzība, kvalitatīvi ievaddati un cilvēka spēja kritiski izvērtēt rezultātu.
Retrospektīva bez vainošanas
.
Ja pēc ieviešanas ir radies incidents, komandai jāizveido laika līnija, kurā norādīta veiktā izmaiņa, pirmo simptomu parādīšanās laiks, incidenta pamanīšanas veids un pieņemtie lēmumi. Šāda analīze atklāj ne tikai tehnisko cēloni, bet arī procesa nepilnības.
Efektīvā retrospektīvā jāatbild uz četriem jautājumiem:
- Kas notika?
- Kāpēc tas bija iespējams?
- Kā to varēja pamanīt agrāk?
- Kāda konkrēta izmaiņa mazinās atkārtošanās risku?
Svarīgi, lai rezultāts nebūtu tikai dokuments. Katram secinājumam jābūt pārvērstam darbībā. Jāpapildina monitorings, jārada automātisks tests, jāprecizē prasību veidne vai jāmaina izvietošanas process.
Neveiksme kļūst par optimizāciju
Kvalitatīvs problēmas risinājums nav tas, kurš nekad nesaskaras ar kļūdām. Tas ir risinājums, kura kļūmes ir savlaicīgi pamanāmas, diagnosticējamas un labojamas bez nesamērīgas ietekmes uz lietotājiem.
No neveiksmīgas ieviešanas visvairāk var mācīties, ja komanda saglabā pierādījumus, pārbauda pieņēmumus un uzlabo procesu, nevis tikai labo redzamo simptomu. Precīzākas prasības, kontrolētas integrāciju kļūmes, tehniskā parāda pārvaldība un regulāras retrospektīvas pārvērš vienu neveiksmīgu izlaidumu par noturīgāku sistēmu nākotnē.