Scalarea echipei de dezvoltare cu ingineri externi fără a pierde calitatea codului

Introducere

Concluzii cheie

1. Folosiți ingineri externi atunci când planul dvs. de acțiune este prea încărcat pentru echipa dvs. de bază.
2. Stabiliți reguli simple de calitate și un proces de livrare de bază înainte ca aceștia să se alăture echipei.
3. Integrați dezvoltatorii externi cu o listă de verificare clară și un coleg de referință.
4. Aplicați un set comun de reguli, evaluări și indicatori pentru toți inginerii.
5. Bazați-vă pe actualizări scurte scrise pentru a menține aliniată o echipă mixtă în creștere.

De ce ar trebui să vă extindeți echipa de dezvoltare cu ingineri externi?

Ar trebui să vă extindeți echipa de dezvoltare cu ingineri externi atunci când planul dvs. de acțiune este plin și propriii angajați nu pot ține pasul într-un mod sănătos. Ideea principală este simplă: inginerii externi ar trebui să adauge viteză și competențe fără a scădea standardele de calitate. Dacă vă ajută să livrați un produs stabil, ușor de întreținut, această configurație are sens. Dacă adaugă doar stres și schimbări aleatorii, momentul nu este potrivit.

Mulți lideri din companiile de produse simt aceeași presiune. Backlog-ul crește, termenele limită se prelungesc, iar angajarea de ingineri puternici în orașul dvs. durează mult timp. În acel moment, începeți să vă gândiți la extinderea echipei de ingineri cu ajutorul unor colaboratori externi. Puteți lua în considerare o echipă de dezvoltare externalizată dintr-o altă regiune sau un grup mai mic, mai aproape de fusul dvs. orar. Adevărata întrebare nu este dacă puteți apela la ajutor extern, ci când acesta vă va sprijini planul de acțiune, în loc să ascundă probleme mai profunde.

Un motiv pentru a invita ingineri externi este accesul la competențe pe care nu le ai în prezent în cadrul companiei. Poate ai nevoie de sprijin pe termen scurt în domenii precum date, aplicații mobile sau noi configurații cloud. Poate nu vrei să construiești o echipă complet nouă în jurul fiecărui subiect nou. În acest caz, extinderea echipei de dezvoltare software îți poate oferi un nivel flexibil de sprijin în jurul grupului tău principal. Păstrați cunoștințele și direcția de bază în cadrul companiei dvs. și utilizați ajutorul extern pentru segmente de lucru clare și concentrate. În viața de zi cu zi, acest lucru seamănă mai mult cu adăugarea unui expert calm într-o echipă ocupată decât cu crearea unei a doua companii.

Există, de asemenea, un aspect foarte simplu legat de timp și costuri. Angajarea de oameni puternici pe cont propriu poate dura multe săptămâni sau chiar luni, iar în acest timp, volumul de muncă restante nu se oprește. Aici puteți vedea clar avantajele extinderii personalului IT. Puteți aduce forță de muncă suplimentară pentru o perioadă și un domeniu de aplicare definite, în timp ce continuați să vă gândiți la angajări pe termen lung. Pentru unele echipe, această opțiune atenuează vârfurile de cerere, în loc să forțeze o creștere semnificativă a numărului fix de angajați. Acest tip de configurare vă permite să testați ce efect are capacitatea suplimentară asupra produsului dvs. înainte de a vă schimba definitiv întreaga structură.

De asemenea, puteți alege diferite modele pentru modul în care aceste persoane se alătură echipei dvs. Într-un model de suplimentare a personalului, adăugați ingineri externi în propria echipă, iar liderii dvs. le ghidează munca în fiecare zi. Într-o configurație de echipă de dezvoltare nearshore, oamenii se află într-un fus orar apropiat și pot participa la apelurile și discuțiile dvs. în timpul programului normal. Multe companii colaborează cu un partener experimentat în dezvoltarea de software, care știe deja cum să realizeze dezvoltarea de software nearshore și să se integreze cu echipele interne. Cu cât cultura, fusul orar și instrumentele sunt mai apropiate, cu atât este mai ușor să faceți ca multe persoane să se simtă ca o singură echipă, chiar dacă contractele diferă. Această bază comună este cea care face ca munca externă să pară naturală, în loc de fragilă.

Cum pregătiți codul sursă și procesele înainte de a adăuga o echipă de dezvoltare externă?

Vă pregătiți pentru o echipă de dezvoltare externă stabilind o bază clară și simplă pentru modul în care construiți și livrați produsul. Aveți nevoie de reguli comune, instrumente de bază și un mod vizibil de lucru înainte de sosirea noilor oameni. Fără această bază, fiecare schimbare depinde de stilul personal și de memorie, iar noii oameni nu au cum să ghicească calea corectă. Cu această bază, chiar și ochii noi se pot mișca într-un ritm sigur și constant.

Puteți considera această bază ca fiind un sistem de protecție a calității codului. Acest sistem de protecție constă în verificări simple pe care fiecare schimbare trebuie să le treacă, indiferent de cine a scris-o. Acestea pot acoperi modul în care denumiți lucrurile, modul în care formatați fișierele și ce înseamnă „terminat” pentru orice mică parte a muncii. Când sistemul de protecție rămâne același pentru toată lumea, produsul dvs. pare stabil chiar și pe măsură ce echipa crește și se schimbă. Acest lucru face mai ușor să aveți încredere în întregul flux, nu doar în persoanele pe care le cunoașteți deja.

De asemenea, aveți nevoie de o integrare continuă de bază și de un canal de livrare. Această frază lungă descrie o idee simplă. De fiecare dată când cineva modifică codul, sistemul efectuează verificări și ajută la transferul acelei modificări către utilizatori în pași mici și siguri. Acest pipeline poate funcționa pe platforme comune și poate rula la fiecare push către magazinul principal de cod. Un pipeline funcțional transformă multe editări mici într-o linie clară de progres, în loc de o grămadă de lansări mari și înfricoșătoare. Noii angajați pot învăța această cale o singură dată și apoi o pot urma fără speculații suplimentare.

Testele sunt o parte esențială a acestei căi. Testarea automată în CI/CD înseamnă că testele dvs. se execută singure de fiecare dată când cineva partajează un cod nou. Puteți începe cu verificări simple care acoperă cele mai utilizate căi din produsul dvs. În timp, puteți adăuga mai multe teste pe măsură ce observați unde tind să apară bug-urile. Chiar și un set mic de teste stabile vă oferă mai multă siguranță decât o listă uriașă de verificări manuale pe care nimeni nu le execută la timp. Această abordare menține lucrurile reale și sprijină atât inginerii interni, cât și cei externi.

De asemenea, este util să examinați părțile mai vechi ale sistemului dvs. înainte de a le cere altora să le modifice. Aici intervine gestionarea de bază a datoriei tehnice. Datoria tehnică este o modalitate de a descrie codul care funcționează, dar care este greu de modificat fără riscuri. Puteți marca zonele care sunt sigure pentru persoanele noi și zonele care încă necesită atenția personalului dvs. cel mai experimentat. Când știți unde se află părțile riscante, puteți îndruma mai întâi echipa de dezvoltare externă către zonele mai sigure. Acest lucru vă protejează produsul și ține persoanele noi departe de capcanele ascunse.

Ultima parte a bazei este simpla siguranță și acces. Un ciclu de viață sigur al dezvoltării software-ului pare greu, dar se bazează pe pași clari. Oferiți oamenilor doar accesul de care au nevoie, păstrați în siguranță datele reale ale utilizatorilor și tratați cu atenție cheile secrete. De asemenea, notați ce trebuie făcut atunci când ceva nu merge bine, chiar și la scară mică. Când siguranța face parte din activitatea normală, inginerii externi se pot alătura procesului dvs. fără a genera noi temeri. Echipele dvs. juridice și de securitate văd, de asemenea, că această creștere urmează un plan, nu o soluție rapidă.

Cum arată un plan sigur de integrare pentru dezvoltatorii externi?

Un plan de integrare sigur pentru dezvoltatorii externi le oferă context, instrumente și pași inițiali clari, fără a-i arunca în apă adâncă. Ar trebui să fie ca o cale ghidată, în care fiecare zi are un scop simplu și real. Când planul este clar, noii angajați pot aduce valoare în câteva săptămâni, nu luni, iar echipa ta nu se simte epuizată de întrebări constante.

Integrarea dezvoltatorilor externi începe cu o viziune comună asupra a ceea ce trebuie să învețe mai întâi. Aceasta include produsul dvs., utilizatorii dvs. și modul dvs. normal de lucru. O listă de verificare pentru integrarea dezvoltatorilor poate cuprinde toate aceste elemente într-un singur loc. Poate fi un document simplu, pe care ambele părți îl pot deschide și modifica. O listă de verificare vizibilă transformă „Cred că le-am spus deja asta” în „Știm exact ce s-a făcut și ce urmează”. Această mică schimbare elimină o mare parte din stresul ascuns pentru toată lumea.

Iată o listă simplă care funcționează adesea bine ca bază pentru o astfel de listă de verificare:

1. Acces la cod, tracker de lucru și camere de chat principale.
2. Pași pentru rularea produsului pe un laptop sau un server de testare.
3. Un ghid scurt pentru utilizatori, fluxuri principale și reguli cheie de afaceri.
4. Numele persoanelor cărora le puteți adresa întrebări despre produs, cod și instrumente.
5. Două sau trei sarcini mici și clare, gata pentru o primă schimbare reală.

De asemenea, este util să se numească o persoană de contact clară. Un șef tehnic sau un inginer senior poate acționa ca un partener de integrare în primele săptămâni. Această persoană poate revizui toate modificările inițiale, răspunde la întrebări și explica de ce alegerile din trecut arată așa cum arată. Verificări scurte zilnice, chiar și de cinci minute în chat, pot menține lucrurile pe drumul cel bun. Un coleg calm și puncte de contact constante contribuie mai mult la integrarea în siguranță decât o discuție importantă în prima zi. În timp, puteți trece la comunicarea asincronă pentru echipele de dezvoltare, cum ar fi note scurte scrise.

Din ceea ce am observat, cel mai mare risc în timpul integrării este confuzia tăcută. Noii angajați se tem să pună prea multe întrebări, iar membrii vechi ai echipei speră că lucrurile se vor „potrivi” de la sine. Un plan clar pentru integrarea dezvoltatorilor externi și un singur responsabil pentru acel plan schimbă această situație. Când o singură persoană este responsabilă de acest proces, poți identifica tiparele, remedia punctele slabe și face ca fiecare rundă de integrare să fie mai ușoară. În câteva luni, planul devine un atu repetabil, în loc să fie o nouă provocare de fiecare dată când se adaugă cineva.

Cum mențineți calitatea codului într-o echipă de dezvoltare mixtă atunci când gestionați dezvoltatori externi?

Mențineți calitatea codului într-o echipă de dezvoltare mixtă utilizând aceleași reguli simple, verificări și cifre pentru toată lumea. Standardele dvs. trebuie să se aplice tuturor inginerilor dacă doriți ca produsul să fie perceput ca un sistem curat și sigur. Odată ce împărțiți regulile în funcție de tipul de contract, împărțiți și încrederea și claritatea în echipa dvs.

O echipă de dezvoltare mixtă este un grup în care inginerii interni și externi lucrează la același produs. Ei pot lucra în locuri diferite, dar împărtășesc un singur backlog și un singur magazin de cod. Acest mix poate fi foarte puternic, deoarece combină cunoștințe aprofundate în domeniu cu perspective noi. Poate fi însă și fragil, dacă fiecare grup își urmează propriile obiceiuri. Fără o îndrumare clară, acest mix se transformă în grupuri de cod care par diferite și între care este dificil să se facă trecerea. Acesta este momentul în care calitatea și viteza încep să scadă.

Cele mai bune practici simple de revizuire a codului sunt de ajutor în acest caz. Fiecare modificare trebuie să fie revizuită de cel puțin o altă persoană, indiferent de cine a făcut-o. Revizuirile trebuie să vizeze claritatea, siguranța și compatibilitatea cu restul sistemului, nu doar stilul. Puteți sprijini acest proces cu instrumente ușoare care scanează codul în căutarea problemelor comune. Aceste rutine mențin calitatea codului dezvoltatorilor externi la același nivel cu restul echipei dvs. într-un mod calm și repetabil. Oamenii învață unii de la alții și construiesc o viziune comună asupra a ceea ce înseamnă „bun”.

De asemenea, puteți urmări un set mic de indicatori ai echipei de dezvoltare software. Aceștia pot arăta cât timp durează finalizarea unei lucrări, câte probleme ajung la utilizatori și cât de des livrați. Nu aveți nevoie de zeci de cifre. Aveți nevoie doar de câteva pe care le puteți citi și discuta cu ușurință. Când aceste metrici rămân stabile sau se îmbunătățesc în timp ce gestionați dezvoltatorii externi și creșteți echipa, știți că configurația dvs. susține calitatea. Dacă acestea scad, aveți un semnal timpuriu pentru a revizui regulile, domeniul de aplicare sau combinația de sarcini.

Modelele de comunicare sunt la fel de importante ca regulile și cifrele. Multe echipe de dezvoltare mixte sunt considerate echipe agile distribuite, deoarece oamenii lucrează din mai multe locuri sau fusuri orare. Acestea au nevoie de comunicare asincronă pentru echipele de dezvoltare, astfel încât progresul să nu depindă de apeluri lungi. Actualizările scurte scrise, notele clare privind sarcinile și etichetele simple pentru stare sunt de mare ajutor. Actualizările scrise bine scrise facilitează participarea tuturor inginerilor, urmărirea și îmbunătățirea produsului în timp. Discuțiile live sunt în continuare importante, dar nu mai sunt singurul loc în care se iau decizii.

Modul în care atrageți persoane din exterior influențează, de asemenea, calitatea. Dacă le tratați ca pe un flux separat, cu obiective neclare, acestea nu vor simți că dețin în totalitate produsul. Dacă le adăugați în echipele existente, sub un set de reguli, acestea pot acționa ca orice alt membru al echipei. Unele companii utilizează pentru aceasta o configurație de extindere a echipei, în care combină persoane interne și externe sub o singură conducere. Obiectivele comune, instrumentele comune și evaluările comune contribuie mai mult la calitatea codului în dezvoltarea de software decât orice document de control riguros. De-a lungul timpului, puteți ajusta combinația de persoane și sarcini, dar cadrul comun rămâne același.