Sistemul tău funcționează excelent. Atâta timp cât lucrează persoana care știe de ce.
Imaginează-ți o companie care are un sistem în funcțiune de șapte ani. A fost construit treptat. La început l-a dezvoltat o firmă de software. Apoi o parte a fost preluată de un freelancer. Mai târziu o altă echipă a adăugat un modul B2B. Următoarea agenție a conectat CRM-ul. Altcineva a integrat plățile.
Sistemul funcționează.
Compania câștigă bani datorită lui.
Angajații îl folosesc zilnic.
Clienții nici nu știu câte procese se întâmplă în fundal.
Doar că există o problemă.
Nimeni nu mai știe exact cum funcționează totul.
Documentația este parțial în Confluence. Ceva a rămas pe Google Drive. Câteva informații se găsesc în ticket-uri. O integrare este descrisă într-un mail de acum patru ani.
Iar lucrul cel mai important „probabil își amintește Łukasz”.
Doar că Łukasz a plecat acum trei ani.
Și timp de trei ani nu s-a întâmplat nimic.
Până într-o dimineață de marți oarecare.
Sistemul funcționează. Deci totul e în regulă?
Acesta este unul dintre cele mai insidioase stări în care se poate afla un sistem de companie.
Funcționează.
Nu sunt erori.
Utilizatorii sunt mulțumiți.
Vânzările folosesc aplicația.
Comenzile trec.
Datele ajung în CRM.
Rapoartele se generează.
Deci reacția naturală este: Să nu-l atingem. La ce să ne complicăm cu ceva ce funcționează?
Și, desigur, nu există motiv să schimbi un sistem funcțional doar pentru că se poate.
Problema este că sistemul poate fi stabil tehnic și, în același timp, foarte instabil organizațional.
Poate funcționa azi, dar nimeni nu știe ce se întâmplă dacă trebuie schimbat serverul, furnizorul API, domeniul, o bibliotecă, modul de autentificare sau o parte din procesul de business.
Poate fi eficient, dar dependent de o singură persoană.
Poate fi sigur, dar nimeni nu știe unde sunt toate cheile de acces.
Poate fi în dezvoltare, dar doar de către omul care cunoaște istoricul tuturor deciziilor.
Și aici apare conceptul de bus factor.
Câte persoane pot dispărea înainte ca proiectul să aibă probleme?
Bus factor este un concept foarte simplu, deși dur.
Întrebăm: Câte persoane trebuie să nu mai fie disponibile pentru ca proiectul să nu mai poată fi întreținut eficient?
Dacă răspunsul este: „Una”, avem o problemă.
Dacă răspunsul e: „Două, dar amândouă lucrează în altă companie”, avem o problemă și mai mare.
Nu e vorba, desigur, de dispariția literală a oamenilor.
Dezvoltatorul poate pleca din firmă.
Freelancerul poate încheia colaborarea.
Firma de software poate înceta să deservească clientul.
Administratorul poate schimba locul de muncă.
Persoana responsabilă de o integrare anume poate fi mutată într-un alt departament.
Deținătorul cunoștințelor poate pur și simplu să se îmbolnăvească sau să fie indisponibil câteva săptămâni.
Dacă odată cu el dispare capacitatea de a înțelege sistemul, compania nu are o problemă de personal.
Are o problemă de business.
Codul nu spune întotdeauna de ce ceva funcționează
Se poate spune: „Avem cod sursă. Dacă e cazul, un nou programator îl va citi.”
Teoretic, da.
În practică, codul răspunde în primul rând la întrebarea: cum face sistemul ceva.
Nu răspunde întotdeauna la întrebarea: de ce face asta într-un anumit fel.
Și aceasta este o diferență enormă.
În cod poate exista o condiție: „Dacă clientul are un anumit tip de cont, execută operațiunea X.”
Un developer nou o poate găsi.
Dar de unde să știe de ce?
Poate fi o cerință de business.
Poate fi o rămășiță a unei integrări vechi.
Poate fi o protecție împotriva unei erori a unui API extern.
Poate fi ocolirea unei probleme care apărea acum cinci ani.
Poate fi soluția unui caz atipic pentru unul dintre cei mai mari clienți.
Poate fi acolo dintr-un motiv foarte bun.
Sau din niciunul.
Fără context e greu de evaluat.
De aceea documentația sistemului nu ar trebui să se limiteze la instrucțiuni:
„click aici, apoi aici”.
Cea mai valoroasă documentație descrie adesea deciziile și dependențele, nu doar cum se utilizează funcțiile.
Cea mai periculoasă cunoaștere este cea care există doar în mintea cuiva
Companiile au foarte des documentație. Doar că documentația nu este întotdeauna același lucru cu cunoașterea.
Putem avea descrierea unui API — dar fără a ști de ce folosim tocmai acel API.
Putem avea instrucțiuni de deploy — dar fără o listă a tuturor locurilor unde trebuie schimbată configurația.
Putem avea descrierea unei integrări — dar fără a ști ce se va întâmpla dacă furnizorul extern schimbă metoda de autorizare.
Putem avea lista de servere — dar fără a ști care dintre ele este critic pentru un anumit proces.
Putem avea acces la repository — dar nu avem acces la contul unde este infrastructura de producție.
Acestea sunt tocmai elementele care pot transforma o schimbare aparent simplă într-o anchetă de câteva zile.
O integrare care funcționează de cinci ani rămâne o dependență
Unul dintre cele mai ignorate domenii sunt serviciile externe;
- Plăți.
- SMS.
- E-mail.
- CRM.
- ERP.
- Hărți.
- Sisteme de curierat.
- Platforme de marketing.
- Sisteme contabile.
- Servicii cloud.
- API-uri externe.
- Biblioteci open source.
Fiecare astfel de element este parte dintr-un ecosistem mai mare.
Dacă un sistem folosește zece servicii externe, nu avem un singur sistem. Avem sistemul plus zece dependențe. Și fiecare dintre ele se poate schimba.
Un furnizor poate schimba API-ul.
Poate opri serviciul.
Poate modifica modelul de prețuri.
Poate deprecia o versiune veche.
Poate introduce noi cerințe de securitate.
Poate fi achiziționat de o altă companie.
De aceea din ce în ce mai importantă devine cunoașterea originii componentelor și a dependențelor software. NIST subliniază, între altele, importanța SBOM (Software Bill of Materials) — o listă formală a componentelor folosite pentru construirea software-ului. Un astfel de inventar ajută la înțelegerea din ce este compus sistemul și la evaluarea mai rapidă a impactului unei vulnerabilități sau a schimbărilor din lanțul de aprovizionare.
Pentru business asta se reduce la o întrebare foarte simplă:
Acum imaginează-ți schimbarea firmei de software
Este unul dintre momentele în care toate lipsurile ies la lumină.
Compania a colaborat ani de zile cu un furnizor. Dintr-o dată colaborarea se încheie. Motive pot fi multe: schimbare de strategie, buget, achiziția agenției, probleme organizaționale, lipsa competențelor pentru dezvoltare ulterioară sau pur și simplu dorința companiei de a lucra cu un alt partener.
Noul software house întreabă:
„Unde este repository-ul?” — Este.
„Unde este infrastructura?” — Există.
„Cum facem deploy în producție?” — „Nu știm, acesta îl făcea echipa precedentă.”
„Cum funcționează integrarea cu ERP-ul?” — „Probabil prin acel server.”
„Care sunt cheile API?” — „Ar trebui să fie într-un mail.”
„Care API-uri sunt producție?” — „Nu știm.”
„Care procese sunt critice?” — „Trebuie întrebat Łukasz.”
Łukasz nu mai lucrează acolo...
Și tocmai de aceea transferul unui proiect nu este doar transferul codului. Trebuie transferată și cunoașterea.
Documentația nu este un cost. Este o poliță
În multe companii documentația este tratată ca ceva ce se face „când va fi timp”.
Adică de obicei niciodată.
Sau la sfârșitul proiectului.
Sau când cineva întreabă.
Aceasta este greșeala.
Documentația este unul dintre mecanismele care limitează riscul operațional. Nu generează direct vânzări. Nu crește conversia. Nu arată spectaculos într-o prezentare.
Dar într-o situație de criză poate face diferența între: „rezolvăm asta azi”
și: „mai întâi trebuie să găsim persoana care își amintește cum funcționa”.
În noile ghiduri NIST privind planurile de securitate, confidențialitate și gestionarea riscului lanțului de aprovizionare software, documentarea scopului sistemului, a stării sale, a controalelor și a responsabilităților și comportamentelor persoanelor care îl gestionează este tratată ca element al unei administrări organizate a sistemului.
Aceasta arată clar schimbarea de gândire.
Documentația nu este exclusiv un instrument pentru developer.
Este un element al continuității operaționale a organizației.
Ce ar trebui documentat?
Nu este vorba de a crea o documentație de 800 de pagini pe care nimeni nu o va deschide.
O documentație bună ar trebui să răspundă în primul rând la întrebările care apar atunci când ceva se schimbă sau încetează să funcționeze.
- Cine este proprietarul sistemului?
- Unde se află codul?
- Unde este producția?
- Cum arată procesul de deploy?
- Care sunt mediile?
- Care sunt integrările critice?
- Ce servicii externe folosim?
- Cine sunt furnizorii lor?
- Ce contracte și conturi avem?
- Unde sunt cheile și datele de acces?
- Cine are permisiuni?
- Cum arată backup-ul?
- Cum se restaurează sistemul?
- Ce componente open source sunt folosite?
- Care biblioteci sunt depășite?
- Care sunt cele mai importante decizii arhitecturale?
- Care elemente sunt critice pentru business?
- Ce se întâmplă dacă un anumit serviciu extern încetează să funcționeze?
Aceasta nu este documentația „pentru programatori”.
Este harta dependențelor businessului de tehnologie.
„Funcționează, deci nu-l atingem” poate fi o strategie. Dar trebuie știut costul ei
Nu orice companie are nevoie de refactorizarea unui sistem vechi.
Nu orice sistem legacy este rău.
Nu tot codul vechi trebuie rescris.
Dimpotrivă — uneori un sistem stabil, mai vechi, este o soluție mult mai bună decât o migrare costisitoare făcută fără un motiv clar.
Problema nu este vârsta sistemului.
Problema este lipsa cunoașterii stării sale.
Dacă știm cum funcționează sistemul, de ce depinde, unde sunt riscurile și cine îl poate întreține, putem decide în cunoștință de cauză:
- să-l păstrăm,
- să-l modernizăm,
- să rescriem un fragment,
- să migram,
- sau să nu facem nimic.
Dacă nu știm asta, decizia „nu facem nimic” nu este o strategie.
Este un pariu.
Cum arată un audit al unui sistem moștenit?
Când un software house preia un sistem existent, primul pas nu ar trebui să fie: „Să-l rescriem.” — Mai întâi trebuie înțeles.
Un audit bun ar trebui să includă, între altele, arhitectura aplicației, codul sursă, baza de date, infrastructura, procesul de deploy, dependențele, integrările, securitatea, accesul la servicii și documentație.
Dar la fel de important este înțelegerea businessului;
- Care procese sunt critice?
- Ce funcții sunt folosite zilnic?
- Ce module generează venit?
- Ce elemente pot fi oprite fără consecințe?
- Ce se întâmplă dacă o integrare specifică încetează să funcționeze?
- Care elemente sunt cele mai riscante?
Abia după combinarea perspectivei tehnice cu cea de business se poate spune ce trebuie cu adevărat schimbat.
Auditul nu trebuie să se termine cu o revoluție
Uneori rezultatul auditului este surprinzător de simplu.
Sistemul e în regulă, trebuie doar:
- Completată documentația.
- Puse ordine în accesuri.
- Actualizate câteva biblioteci.
- Transferată proprietatea conturilor.
- Descris procesul de deploy.
- Adăugat monitoring.
- Stabilit backup.
- Introducerea unei a doua persoane în ariile cunoscute doar de un developer.
Și brusc bus factor-ul se schimbă de la 1 la 3.
Nu este nevoie să rescrii toată aplicația.
Nu este nevoie să arunci șapte ani de muncă.
Nu este nevoie să reconstruiești totul de la zero.
Uneori cea mai mare problemă nu este tehnologia.
Este lipsa unei hărți.
Sistemul ar trebui să supraviețuiască oamenilor care l-au creat
Aceasta este probabil regula cea mai importantă: un sistem bun ar trebui să poată supraviețui plecării unui dezvoltator.
Să supraviețuiască schimbării unui administrator.
Să supraviețuiască schimbării firmei de software.
Să supraviețuiască reorganizării companiei.
Să supraviețuiască câtorva ani de dezvoltare.
Nu înseamnă că fiecare programator trebuie să înțeleagă fiecare linie de cod. Înseamnă că cunoașterea critică pentru funcționarea businessului nu poate exista exclusiv în mintea unei singure persoane.
Pentru că angajatul poate pleca.
Freelancerul poate încheia colaborarea.
Agenția poate dispărea.
Furnizorul poate schimba serviciul.
Iar compania trebuie în continuare să funcționeze.
Tehnologia ar trebui să fie proprietatea organizației, nu memoria unei singure persoane
Acest lucru este deosebit de important pentru sistemele construite pe parcursul mai multor ani.
Dacă o companie plătește pentru software, ar trebui să știe nu doar unde se află codul.
Ar trebui să știe:
- ce deține,
- de ce depinde,
- cine are acces,
- cine îl poate modifica,
- cum poate fi pus în producție,
- cum poate fi restaurat,
- cum poate fi transferat către o altă echipă.
NIST, în materialele actuale despre due diligence al furnizorilor, atrage atenția, între altele, asupra originii, rezilienței, practicilor de securitate cibernetică și dependențelor din lanțul de aprovizionare. Asta arată o direcție mai largă: organizațiile ar trebui din ce în ce mai mult să știe nu doar cine a livrat sistemul, ci și din ce este compus și care sunt riscurile asociate întreținerii lui.
Acesta nu mai este doar un subiect pentru departamentul IT.
Este o chestiune de management al riscului de business.
Cel mai prost moment să-ți cunoști sistemul este o defecțiune
Poți dedica câteva zile pentru audit.
Poți pune ordine în documentație.
Poți verifica dependențele.
Poți descrie arhitectura.
Poți verifica accesurile.
Poți stabili cine este cu adevărat responsabil pentru fiecare domeniu.
Poți reduce bus factor-ul.
Sau poți aștepta.
Până în momentul în care sistemul se oprește.
Atunci întrebările vor fi exact aceleași.
Doar că presiunea va fi mai mare, utilizatorii vor aștepta, vânzările pot fi oprite și fiecare oră va costa bani.
De aceea merită să-ți pui o întrebare înainte de a apărea problema: Dacă mâine ar dispărea persoana care cunoaște cel mai bine sistemul tău, am ști în continuare cum să îl întreținem?
Dacă răspunsul este „nu”, asta nu înseamnă încă că sistemul este prost.
Înseamnă că compania are un risc ascuns pe care până acum nu a fost nevoită să-l activeze.
La Web24 preluăm nu doar codul
Preluarea unui proiect existent este o muncă complet diferită față de începerea unui sistem nou de la zero.
Mai întâi trebuie să înțelegem ce există deja.
Ce funcționează.
Ce este critic.
Ce este o dependență.
Ce este o problemă.
Ce este doar o rămășiță a unor decizii anterioare.
Și, mai presus de toate — unde se află cunoașterea fără de care sistemul nu poate fi dezvoltat în siguranță.
Abia atunci se pot planifica acțiunile ulterioare.
Uneori va fi modernizare.
Uneori dezvoltare.
Uneori ordonarea infrastructurii.
Uneori preluarea mentenanței.
Iar uneori pur și simplu crearea unei hărți corecte a sistemului, pe care nimeni nu a avut-o timp să o pregătească de ani de zile.
Pentru că un software house responsabil nu ar trebui să construiască o tehnologie care funcționează doar atunci când persoana potrivită stă la calculator.
Sistemul trebuie să fie mai mare decât memoria unei singure persoane.
Și businessul trebuie să aibă certitudinea că, dacă cineva pleacă, tehnologia nu pleacă odată cu el.
