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, plan de preluare și 4-8 săptămâni de stabilizare. 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
Dacă te regăsești în 3+ din punctele de mai sus, probabil e momentul.
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 și cea nouă lucrează împreună 2-4 săptămâni. Echipa veche face knowledge transfer, iar cea nouă preia treptat. E cel mai eficient, dar 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
Primele 4-8 săptămâni după preluare sunt de stabilizare, nu de funcționalități noi:
- Săptămânile 1-2: Setup mediu de dezvoltare, rulare locală, înțelegerea arhitecturii
- Săptămânile 3-4: Fix-uri critice, setup CI/CD (dacă nu există), primele contribuții de cod
- Săptămânile 5-8: Refactorizare unde e necesar, primele funcționalități noi, cadență stabilă
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.
5 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.
5. Subestimarea efortului de preluare
Prevenție: planifică 4-8 săptămâni de ramp-up. Nu promite funcționalități noi în prima lună.
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
Am preluat zeci de proiecte de la alți furnizori. Procesul nostru:
- Consultare inițială gratuită — înțelegem situația și evaluăm fezabilitatea
- Audit de cod — analiză detaliată a codebase-ului existent, cu raport și recomandări
- Plan de tranziție — timeline, etape, responsabilități clare
- Stabilizare — 4-8 săptămâni de preluare, fix-uri critice și setup-ul proceselor
- Dezvoltare continuă — odată stabilizat, continuăm cu backlog-ul de funcționalități
Nu promitem că totul va fi simplu — dar promitem transparență completă: vei ști exact în ce stare e proiectul și ce efort necesită.
Ai un proiect pe care vrei să-l muți la o nouă echipă?