Ghid · 8 minute
Cum preiei un proiect software blocat fără să repeți greșelile
Prima urgență nu este să scrii cod nou. Este să recapeți controlul asupra accesului, datelor și deciziilor înainte ca presiunea să producă încă o soluție temporară.
Actualizat
Oprește pierderea de informație
Strânge repository-urile, backupurile, accesul la servere, domenii, baze de date, servicii de e-mail și conturile externe. Nu schimba imediat infrastructura; întâi verifică dacă backupul poate fi restaurat și notează cine are acces.
Păstrează o copie a versiunii care rulează și a bazei de date înainte de orice intervenție. Chiar și un sistem fragil este o sursă de adevăr despre regulile pe care utilizatorii se bazează astăzi.
Separă simptomele de cauze
O listă de erori nu este încă un audit. Echipa nouă trebuie să urmărească arhitectura, baza de date, dependențele, procesul de livrare, securitatea și modul în care cerințele au fost decise. Aceeași eroare repetată poate veni din lipsa testelor, din date inconsistente sau dintr-o regulă de business neclară.
Auditul trebuie să se încheie cu un document care poate fi înțeles și de persoana care decide bugetul: ce poate rămâne, ce este periculos, ce blochează lansarea și ce poate fi amânat.
Alege între reparare, refactorizare și reconstrucție
Decizia nu trebuie luată din preferința tehnică a noii echipe. Trebuie comparate riscul, timpul până la primul rezultat și costul de a menține două sisteme în paralel.
- Repararea este potrivită când arhitectura este sănătoasă și problemele sunt localizate.
- Refactorizarea păstrează comportamentul, dar înlocuiește treptat zonele care fac fiecare schimbare riscantă.
- Reconstrucția are sens când modelul de date, tehnologia sau securitatea fac recuperarea mai scumpă decât un nucleu nou.
- O variantă hibridă poate izola sistemul vechi și muta pe rând fluxurile importante, fără o oprire mare.
Construiește mai întâi o perioadă de stabilizare
Înainte de funcții noi, fă livrarea repetabilă: mediu de test, backup verificat, monitorizare, jurnal de erori și o cale de revenire. Adaugă teste în jurul fluxurilor care aduc venit sau pot pierde date.
Apoi alege puține probleme cu efect vizibil pentru utilizatori. Câștigurile rapide sunt utile numai dacă nu măresc datoria tehnică pe care tocmai încerci să o controlezi.
Predarea către echipa nouă
Stabilește o perioadă scurtă în care întrebările pot ajunge la echipa veche, dacă relația permite. Cere explicații despre decizii și excepții, nu justificări. Scopul este continuitatea afacerii, nu stabilirea vinovăției.
La finalul preluării trebuie să ai o hartă a sistemului, lista acceselor, pașii de publicare, planul de lucru și riscurile acceptate. Fără acestea, proiectul poate părea că a repornit, dar depinde din nou de memoria câtorva oameni.