De la enterprise la SaaS pe cont propriu: ce se transferă și ce nu

Zece ani am lucrat pe sisteme enterprise și medicale — C++, cod legacy, software reglementat. Baze de cod mari, cicluri de release lungi, alți oameni responsabili pentru părțile de care nu răspundeam eu.

În ultimul an am construit mai multe produse cap-coadă, singur: arhitectură, backend, frontend, deployment, tot. Ăsta e un inventar al ce s-a transferat, scris pentru inginerii care se gândesc la aceeași mișcare — și împotriva celor două povești care se spun de obicei despre ea, amândouă greșite.

Prima poveste: experiența enterprise e balast, numai proces și zero livrare. A doua: e o superputere, ai văzut sisteme reale cât ceilalți făceau CRUD. Niciuna nu supraviețuiește contactului cu munca.

Ce se transferă aproape intact

Raționamentul despre modurile de eșec. Cel mai valoros lucru pe care ți-l dă un deceniu pe sisteme care nu au voie să cadă e reflexul de a întreba „ce se întâmplă când asta e indisponibilă / lentă / greșită / apelată de două ori“. Întrebarea e independentă de domeniu, e diferența dintre un demo și un produs și e obiceiul pe care îl văd lipsind cel mai des în codul scris de oameni care au construit numai pe teren gol.

Integritatea datelor ca element de proiectare, nu ca funcționalitate. În software reglementat nu poți lipi calea de audit la sfârșit; îți schimbă schema. Dus în produs, instinctul ăsta înseamnă că proiectezi pentru „cine a schimbat asta și când“ de la prima migrare, în loc să descoperi în luna a opta că nu poți răspunde la întrebarea unui client.

Cititul de cod străin. Munca în enterprise e în bună măsură arheologie. Deprinderea se dovedește a fi exact ce-ți trebuie când o bibliotecă se poartă neașteptat și documentația tace — te duci și o citești, ceea ce majoritatea tratează ca ultimă soluție, nu ca primă.

Scrisul. Într-un mediu reglementat scrii raționamentul pentru că ești obligat. Lucrând singur, îl scrii pentru că peste trei luni nu vei mai ține minte de ce ai respins abordarea evidentă — iar tu-cel-de-atunci e acum singurul arhitect pe care îl ai.

Disciplina de testare acolo unde contează. Nu procente de acoperire. Să știi care eșecuri sunt scumpe și să le testezi pe alea. Judecata asta se construiește în ani și supraviețuiește complet trecerii.

Ce nu se transferă

Plasa de siguranță — și e mai mare decât crezi.

În enterprise, altcineva	Pe cont propriu
QA găsește ce ai ratat	Găsești tu sau găsește un client
DevOps deține pipeline-ul și serverele	Tu deții deploy-ul, reînnoirea TLS, backup-urile
Un arhitect pune veto pe ideea proastă	Nu pune nimeni veto pe nimic
Un PM definește „gata“	Îl definești tu și, la început, îl vei defini prost
Review de securitate înainte de release	Propriul review, cu propriile unghiuri moarte
Un specialist știe frontendul	Tu ești acum specialistul de frontend

Șocul real e lățimea, nu volumul de muncă. Zece ani de profunzime într-o singură zonă valorează enorm — și nu valorează absolut nimic când problema e că managementul de stare din React e un haos sau că nginx-ul tău lasă să treacă un header care n-ar trebui. Treci de la a fi cu adevărat expert la a fi, în cel mai bun caz, competent în cinci zone simultan, iar asta e inconfortabil într-un fel despre care nu te avertizează nimeni.

Al doilea șoc e că nu definește nimeni „gata“. În enterprise, scope-ul vine din afară; poți să te cerți cu el, dar există. Singur, „gata“ e ce decizi tu, ceea ce înseamnă că se poate extinde la nesfârșit — și o va face, pentru că mereu mai e ceva ce ar fi mai bine.

Ce încurcă activ

Asta e partea pe care inginerii de enterprise o subestimează, eu inclusiv, din plin.

Inginerie pentru o scară pe care n-o ai. Am proiectat prima versiune a unui produs pentru tipare de tenancy și un debit care n-aveau să fie niciodată solicitate. Nu din prostie — pentru că în enterprise ești la scara aia, deci instinctele sunt corecte acolo. Aplicate unui produs cu o mână de clienți, au costat săptămâni și n-au adus nimic. Soluția nu e „construiește prost“; e să construiești cusăturile care îți permit să scalezi mai târziu și apoi să te oprești.

Așteptarea specificației. Nu există specificație. Există un client cu o problemă și o descriere parțial greșită a ei. Reflexul din enterprise — clarifici cerințele, apoi construiești — devine paralizie când cerințele pot fi descoperite doar construind ceva și uitându-te la cineva cum îl folosește.

Greutate de proces fără beneficiu de proces. Ceremonia din domeniul reglementat există dintr-un motiv și n-aș sări peste ea într-un produs reglementat. Aplicată unui site de prezentare, e mascaradă. Păstrează obiceiurile care se plătesc la scara ta — igiena în controlul versiunilor, review pe orice atinge securitatea, backup-uri pe care chiar le-ai restaurat — și renunță la cele care se plătesc doar cu douăzeci de oameni și un auditor.

Perfecționarea invizibilului. Un model de domeniu superb factorizat pe care niciun client nu-l va observa vreodată, în timp ce fluxul de onboarding e confuz. În enterprise, calitatea aia internă e legitim treaba cuiva. Singur, fiecare oră investită are un cost de oportunitate pe care îl plătești tu.

Ce a fost cu adevărat nou

Ops nu e o disciplină separată pe care s-o amâni. Prima dată când expiră un certificat sau când un deploy pică site-ul la o oră nepotrivită, înveți că „merge pe mașina mea“ era un lux oferit de alți oameni. Pentru mine asta a fost surpriza cea mai plăcută — dar e muncă reală și e o zonă întreagă pe care n-o aveai în CV.

Viteza de decizie e o deprindere în sine. Într-o organizație mare, deciziile sunt lente, iar lentoarea e distribuită — mulți oameni, multe opinii. Singur, deciziile sunt instantanee și în întregime ale tale, ceea ce e mai rapid și mult mai ușor de greșit. Contramăsura la care am ajuns e aceeași care funcționa când conduceam o echipă: decide, scrie raționamentul și numește ce te-ar face să te răzgândești. Face deciziile rapide reversibile, nu doar rapide.

Partea grea nu e codul. Zece ani m-au învățat că dificultatea unui proiect stă în complexitatea lui tehnică. Nu stă. Stă în a decide ce să nu construiești și în onestitatea necesară ca să abandonezi ceva în care ai investit deja. Experiența enterprise nu-ți dă antrenament la niciuna — scope-ul era mereu problema altcuiva.

Aș recomanda trecerea?

Cu o rezervă: nu te aștepta ca fondul enterprise să fie avantajul. E un avantaj, exact în locurile enumerate mai sus — moduri de eșec, integritatea datelor, disciplina de a fi precis când spui de ce crezi că ceva funcționează. Sunt reale și se văd în produse.

Dar deprinderea care decide dacă livrezi e disciplina de scope, iar un deceniu de inginerie enterprise ți-a dat aproximativ zero din ea. Să știi asta dinainte e cea mai mare parte din valoarea acestui articol.

Celălalt lucru care merită spus direct: cele două nu se opun. Rigoarea învățată pe sisteme clinice e motivul pentru care proiectez criptare și audit trail într-un produs de la început, în loc să le lipesc ulterior. Ritmul învățat construind singur e motivul pentru care produsele alea există. Niciunul n-ar fi fost de ajuns singur.

Dacă faci o trecere similară și vrei să compari însemnări cu cineva aflat la un an de la ea, discut cu plăcere.