Ce am învățat livrând software sub GxP

Am petrecut o bună parte din carieră pe software care ajungea în spitale și laboratoare — sisteme clinice la Cerner, imagistică la GE Healthcare, sisteme de date de laborator la Waters. Toate sub cerințe de tip GxP.

Articolul ăsta nu e despre standarde. E despre ce mi-a rămas după, și de ce cred că a meritat chiar și pentru proiectele unde nimeni nu-mi cere conformitate.

Nu intru în detalii despre sisteme sau clienți — tot ce urmează sunt lecții generale de inginerie.

Ce m-a surprins la început?

Că nu puteam începe cu codul.

Veneam dintr-un mod de lucru unde primești un task, îl înțelegi din discuție, îl faci, îl arăți. Aici, înainte de prima linie de cod exista un lanț: cerință de sistem, cerință software, element de design. Mi s-a părut lent și inutil.

Mi-a luat ceva timp să văd ce cumpără de fapt încetineala aia: claritate despre ce construim, înainte să investim în construit. Jumătate din discuțiile pe care le am azi în proiecte comerciale — „păi eu credeam că trebuie să facă altceva“ — pur și simplu nu apăreau.

De ce „repar repede în producție“ nu există?

Într-un produs obișnuit, un hotfix e o victorie. Repari în douăzeci de minute, dai deploy, mergi mai departe.

Acolo, un hotfix înseamnă: analiză de impact, evaluare de risc, actualizarea documentelor afectate, retestare, aprobare. Nu pentru că cineva vrea să te încetinească, ci pentru că o schimbare făcută rapid într-un sistem care influențează un diagnostic poate face rău.

Efectul secundar a fost interesant: când știi că schimbarea e scumpă, investești mult mai mult în a nu greși de la început. Am scris mai puțin cod, dar l-am gândit mai bine. Și am ajuns să prefer asta.

De ce documentația la timp e mai ieftină?

Ăsta a fost cel mai contraintuitiv lucru.

Toți credem că documentația e o taxă plătită la final. În realitate, documentul scris în momentul deciziei costă zece minute. Același document reconstituit după șase luni costă o zi — și e adesea greșit, pentru că nimeni nu-și mai amintește exact de ce s-a ales varianta B în locul variantei A.

Ce am păstrat: scriu decizia când o iau, scurt. De ce am ales asta, ce alternative am respins, ce compromis am acceptat. Nu un document formal — câteva paragrafe. În proiectele mele de acum, ăsta e singurul „proces“ pe care mi-l impun singur, și e cel care se plătește cel mai vizibil.

Ce am dus cu mine în SaaS?

Patru obiceiuri, toate direct utile în produse nereglementate:

• Dependențe puține și cunoscute. Când fiecare bibliotecă terță însemna documentație și analiză, înveți să te întrebi dacă chiar ai nevoie de ea. Arborele meu de dependențe e și azi mic — nu din purism, ci din obișnuință.
• Build-uri reproductibile. Să pot reconstrui exact ce am livrat, oricând. Sună banal până în ziua în care trebuie să depanezi ceva ce rulează la client de trei luni.
• Bug-uri urmărite până la capăt. Nu „am rezolvat“, ci: ce l-a cauzat, ce altceva mai putea afecta, cum previn reapariția.
• Testele ca dovezi, nu ca plasă. Un test care trece dar nu e legat de o cerință îmi dă un fals sentiment de siguranță.

Niciunul dintre ele nu e specific domeniului medical. Toate sunt, pur și simplu, inginerie bună — doar că acolo nu ai voie să le sari.

Ce aș face altfel?

Două lucruri.

Aș argumenta clasificarea, în loc s-o aleg implicit pe cea mai strictă. Am văzut echipe alegând nivelul cel mai strict pe tot sistemul, din prudență. E o decizie care costă mult — și care, în plus, renunță la un argument pe care oricum trebuie să-l poți susține: cel de segregare. Efortul de a argumenta corect se întoarce, dar vine la pachet cu obligația de a-l apăra în fața unui auditor.

Aș cere mai devreme exemple de date reale. Multe surprize târzii vin din presupuneri despre cum arată datele în practică. O oră petrecută cu cineva care folosește efectiv sistemul valorează mai mult decât o săptămână de specificații.

Merită?

Dacă vrei viteză maximă și iterații rapide, nu e mediul tău. Dacă vrei să înveți să construiești lucruri în care poți avea încredere — da, și cred că te face un inginer mai bun oriunde ai merge după.

Eu am rămas cu o intuiție pe care mă bazez și acum: dacă nu poți explica de ce ai făcut ceva într-un anumit fel, probabil nu ai înțeles încă problema.