Decizia de a schimba echipa de dezvoltare nu se ia ușor. De obicei vine după luni de frustrări: termene depășite, calitate sub așteptări, comunicare deficitară sau pur și simplu nevoia de competențe pe care echipa actuală nu le are.
Problema: schimbarea furnizorului e un proiect în sine. Făcută prost, poți ajunge într-o situație mai rea decât cea de dinainte. Făcută corect, e un nou început solid.
Pe scurt: Tranziția de la un furnizor software la altul necesită un plan clar: audit de cod, documentare și plan de preluare. Cele mai mari riscuri sunt pierderea accesului la cod și subestimarea efortului de preluare. Asigură-te că deții toate conturile și repository-urile.
Când e momentul să schimbi furnizorul
Câteva semnale de alarmă:
- Termenele sunt depășite constant — nu o dată, ci sistematic, sprint după sprint
- Calitatea codului scade — bug-uri frecvente, regressions, cod fragil care se „sparge" la orice modificare
- Comunicarea e dificilă — nu primești răspunsuri clare, nu înțelegi ce se întâmplă, nu ai vizibilitate
- Echipa nu înțelege business-ul tău — implementează literal ce li se spune, fără să gândească
- Costurile cresc fără valoare proporțională — plătești mai mult, dar nu primești mai mult
- Lipsa de proactivitate — nu ți se semnalează riscuri, nu ți se propun alternative, nu se optimizează nimic
Pasul 1: Înțelege-ți propriul proiect
Înainte de a vorbi cu o nouă echipă, asigură-te că poți răspunde la aceste întrebări:
Tehnologii
- Ce limbaje/framework-uri sunt folosite? (ex: Flutter, React Native, Swift, Kotlin)
- Ce stack de backend? (Node.js, Laravel, Django, .NET, Go)
- Ce baze de date? (PostgreSQL, MongoDB, Firebase, etc.)
- Ce servicii cloud? (AWS, Google Cloud, Azure, Cloudflare)
Infrastructură
- Unde e hostată aplicația? (cloud, on-premise, PaaS)
- Există CI/CD pipelines? (GitHub Actions, GitLab CI, etc.)
- Cum se face deploy-ul? (automat, manual)
- Ce servicii terțe sunt integrate? (Stripe, Firebase, Twilio, etc.)
Proprietate și acces
- Ai acces la codul sursă? Acesta ar trebui să fie în repository-ul tău, nu al furnizorului
- Ai acces la conturile de hosting, domeniu, certificate SSL?
- Ai acces la conturile de App Store / Google Play?
- Documentația există? E actualizată?
Important: dacă nu ai acces la cod sau la infrastructură, rezolvă asta înainte de a anunța tranziția.
Pasul 2: Pregătirea documentației
Documentul ideal pe care îl predai noii echipe:
Obligatoriu
- Codul sursă — repository complet cu istoric de commit-uri
- Specificații de cerințe — ce ar trebui să facă aplicația (chiar și incomplete)
- Credențiale — acces la toate serviciile (hosting, API keys, baze de date, store accounts)
- Schema bazei de date — structura datelor și relațiile
- Fișiere de configurare — environment variables, deployment config
Ideal
- Documentație de arhitectură (cum sunt organizate modulele, cum comunică)
- Ghid de setup local (cum rulezi proiectul pe mașina de dezvoltare)
- Descrierea fluxurilor critice (autentificare, plăți, notificări)
- Bug tracker / backlog curent (ce e în lucru, ce e planificat)
- Design files (Figma, Sketch, Adobe XD)
Dacă nu există documentație
Nu e ideal, dar nu e neobișnuit. O echipă competentă poate face reverse engineering pe un codebase existent. Va dura mai mult și va costa mai mult — dar e fezabil.
Pasul 3: Auditul codului (Code Review)
Cea mai importantă etapă a tranziției. Noua echipă analizează codebase-ul existent și evaluează:
Ce verifică un audit de cod
- Calitatea codului — e structurat, lizibil, respectă convenții?
- Testare — există teste? Ce acoperire au?
- Securitate — vulnerabilități cunoscute, date sensibile hardcodate, dependențe cu probleme
- Performanță — queries lente, memory leaks, cod ineficient
- Datoria tehnică — cât de mult cod trebuie refactorizat vs. cât e reutilizabil
- Actualizarea dependențelor — versiuni vechi cu vulnerabilități, librării depreciate
Rezultatul auditului
Un raport structurat cu:
- Starea generală a codebase-ului (sănătos / necesită intervenție / critic)
- Probleme critice care necesită remediere imediată
- Datoria tehnică estimată (efort necesar pentru a aduce codul la standarde)
- Recomandări — ce se păstrează, ce se refactorizează, ce se rescrie
- Estimare de efort pentru preluare și continuare
Pasul 4: Planul de tranziție
Scenariul ideal: colaborare între echipe
Echipa veche face knowledge transfer, iar cea nouă preia treptat. Acest scenariu necesită cooperarea furnizorului vechi.
Scenariul realist: predare la cheie
Furnizorul vechi predă codul și documentația, noua echipă face audit și preia independent. Mai lent, dar funcționează chiar și fără cooperarea echipei vechi.
Scenariul dificil: zero cooperare
Furnizorul vechi nu cooperează sau dispare. Noua echipă lucrează exclusiv pe baza codului sursă și a accesurilor existente. Costisitor, dar fezabil dacă ai proprietatea asupra codului.
Pasul 5: Perioada de stabilizare
Nu încerca să „recuperezi" în primele săptămâni. O echipă care înțelege bine codebase-ul livrează mai rapid pe termen lung decât una care scrie cod haotic de la prima zi.
Lucruri care pot merge prost (și cum le previi)
1. Pierderea accesului la cod sau infrastructură
Prevenție: asigură-te că tu deții toate conturile (repository, hosting, store accounts). Nu furnizorul.
2. Cod nedocumentat și „spaghetti"
Prevenție: bugetează un audit de cod înainte de a semna cu noua echipă. Știi exact ce preiei.
3. Echipa veche sabotează tranziția
Prevenție: anunță tranziția profesional. Oferă o perioadă de tranziție plătită. Include clauze de cooperare în contract.
4. Noua echipă vrea să rescrie totul de la zero
Prevenție: e rar justificat. De cele mai multe ori, refactorizarea incrementală e mai eficientă. Cere argumente concrete pentru orice rescriere.
Aspecte legale de verificat
- Proprietatea intelectuală — contractul cu furnizorul vechi specifică clar că tu deții codul?
- NDA — echipa veche are obligații de confidențialitate post-contract?
- Licențe — software-ul folosit (librării, servicii) e licențiat pe numele tău sau al furnizorului?
- GDPR — dacă echipa veche a avut acces la date personale, există obligații de ștergere?
Cum facem tranziția la Brainic
În funcție de starea proiectului și de scopul agreat, colaborarea poate include:
- Discuție inițială — înțelegem situația și evaluăm potrivirea
- Audit de cod — analiză detaliată a codebase-ului existent, cu raport și recomandări
- Plan de tranziție — timeline, etape, responsabilități clare
- Stabilizare — preluare, fix-uri critice și setup-ul proceselor
- Dezvoltare continuă — după stabilizare, putem discuta continuarea cu backlog-ul de funcționalități
O evaluare tehnică poate rămâne un proiect de sine stătător. Prezentăm constatările, ipotezele și riscurile cunoscute; efortul estimat se poate schimba când apar informații noi.
Ai un proiect pe care vrei să-l muți la o nouă echipă?