Onboardingul de dezvoltatori se măsoară de obicei prin cât durează primirea formală, iar acesta este capătul greșit al problemei. Numărul care contează este altul: cât trece până când un inginer nou poate schimba ceva și poate fi sigur că nu a stricat altceva. În majoritatea echipelor asta se măsoară în luni, nu în zile.

Întârzierea ține rareori de persoană. Ține de cât din sistem există doar în capul altora și de cât din primele două săptămâni se duce pe scoaterea lui de acolo, o întrerupere pe rând.

Singura măsurătoare care merită urmărită: cât trece până când prima lor modificare ajunge în producție. Nu primul commit, care poate fi o greșeală de tipar corectată, ci o schimbare care conta și care a intrat live. Dacă durează mai mult de o săptămână, obstacolul aproape niciodată nu este competența. Este un proces de instalare pe care nimeni nu l-a parcurs de la zero de curând sau o bază de cod ale cărei puncte de intrare nu pot fi găsite fără ghid.

Cu ce concurează onboardingul de dezvoltatori

Trei costuri, iar unul singur este timpul persoanei nou venite.

Timpul ei, cel vizibil și cel pe care toată lumea îl optimizează. Timpul echipei, pentru că fiecare întrebare întrerupe pe cineva care făcea altceva, iar postul acesta cântărește mai mult decât primul. Și costul întrebărilor niciodată puse, atunci când un inginer nou preferă să ghicească decât să deranjeze a cincea oară într-o dimineață, iar presupunerea este greșită într-un fel care iese la iveală abia peste două luni.

Al treilea cost este cel pe care un onboarding bun îl elimină cu adevărat. Documentația merită scrisă nu pentru că cititul ar fi mai rapid decât întrebatul, ci pentru că îi permite cuiva să afle răspunsul la unsprezece seara, fără să cântărească prețul social al încă unei întrebări.

Reparați mai întâi mediul de lucru

Factorul care decide cel mai mult prima săptămână este dacă proiectul pornește pe o mașină curată, fără ajutor.

Echipele subestimează asta constant, pentru că toată lumea are deja un mediu funcțional și nimeni nu a mai construit unul de doi ani. Între timp, documentul de instalare trimite la o versiune care a mers mai departe, omite variabila de mediu adăugată de cineva în primăvara trecută și presupune accesul la un serviciu pe care persoana nouă nu l-a primit niciodată.

Remediul nu are nimic spectaculos. Puneți următorul angajat să urmeze documentul exact, fără să schimbe nimic, și notați fiecare punct în care acesta cade. Lista aceea este procesul vostru real de instalare. Mai bine: reduceți-o la o singură comandă care produce un sistem pornit, cu date de test utilizabile, pentru că fiecare pas manual este un pas care va aluneca.

Accesele fac parte din mediu. Cineva care are codul, dar nu are drepturile pe depozit, credențialele de staging sau accesul în tracker nu este pregătit de lucru. Pregătiți conturile înainte de data de început, în loc să descoperiți golurile în prima dimineață.

Dați-le imediat o sarcină reală

Instinctul de a proteja o persoană nouă de munca reală timp de două săptămâni pornește din bune intenții și are efectul invers. Cititul unei baze de cod fără un scop învață foarte puțin, pentru că nu există nimic de care lectura să se agațe.

O modificare mică, autentică și livrabilă în ziua a doua sau a treia predă întregul drum până la livrare: unde stă codul, cum rulează testele, cum funcționează recenzia, cum se face deployul și cui trebuie spus. Exact acest drum îi trebuie cel mai mult unui inginer nou și tocmai el are cele mai mici șanse să fie scris undeva.

Alegeți ceva ce așteaptă un utilizator real, nu un exercițiu inventat. Oamenii simt diferența, iar diferența decide dacă vor lua feedbackul în serios.

Apoi lucrați împreună la ea. O oră alături de cineva care cunoaște sistemul transmite mai mult decât o zi de citit, iar cel care însoțește descoperă de obicei ceva despre propria bază de cod.

Ce merită scris și ce nu

Documentația se degradează, așa că scrieți doar ce rămâne adevărat și își plătește întreținerea.

Merită scris: cum se instalează și se pornește sistemul, cum se face deployul, ce formă are arhitectura și de ce este așa, deciziile care altfel ar fi rediscutate la nesfârșit și cine răspunde de ce. Ghidul nostru despre documentația tehnică tratează problema întreținerii mai pe larg.

Nu merită scris: tot ce spune deja limpede codul, parcursurile pas cu pas prin ecrane care se schimbă lunar și referințele API exhaustive întreținute manual. Acestea se învechesc cel mai repede și induc cel mai tare în eroare.

În majoritatea echipelor, documentul cu cea mai mare valoare este o scurtă privire de ansamblu asupra arhitecturii, care explică ce piese mari există și de ce au fost separate. Costă o după-amiază, se schimbă rar și răspunde întrebării pe care fiecare inginer nou își petrece prima săptămână reconstituind-o singur.

Onboardingul este un test pentru echipă

Tot ce îi dă bătăi de cap unei persoane noi este ceva ce echipa absorbea fără să vadă.

Dacă instalarea durează trei zile, costul acela a existat dintotdeauna, plătit în sume mici de toți cei care au refăcut vreodată o mașină. Dacă nimeni nu poate explica de ce există o componentă, ambiguitatea aceea costă decizii de mult. Dacă procesul de deploy are nevoie de o anumită persoană, dependența era deja un risc, și este același risc care iese la suprafață într-o analiză tehnică de tip due diligence și în orice plan serios de refacere.

Tratați deci primele săptămâni ca pe un audit gratuit. Rugați persoana nouă să țină o listă cu tot ce a derutat-o și citiți lista ca pe un backlog, nu ca pe o notă despre capacitatea ei. Este cea mai onestă descriere a sistemului vostru pe care o va produce cineva, pentru că după două luni nici ea nu va mai observa.

Mecanik intră în mod curent în baze de cod existente ca parte a activității noastre de dezvoltare software, ceea ce înseamnă că dăm acest test pe sistemele altora ca meserie. Echipele care integrează repede nu sunt cele cu cea mai bună documentație. Sunt cele în care cineva și-a refăcut de curând mediul de lucru și a reparat ce s-a rupt pe drum.

Întrebări frecvente

Cât ar trebui să dureze onboardingul de dezvoltatori? Măsurați timpul până la prima modificare semnificativă ajunsă în producție, nu durata primirii formale. Dacă trece mai mult de o săptămână, obstacolul rareori este competența. De obicei este un proces de instalare pe care nimeni nu l-a parcurs de la zero de curând sau o bază de cod ale cărei puncte de intrare nu pot fi găsite fără ghid.

Ce ar trebui să facă un dezvoltator nou în primele zile? O modificare mică, autentică și livrabilă, așteptată de un utilizator real. Cititul unei baze de cod fără scop învață puțin, pentru că lipsește punctul de sprijin, în timp ce o singură schimbare reală arată unde stă codul, cum rulează testele, cum funcționează recenzia, cum se face deployul și cui trebuie spus.

De ce durează atât de mult pregătirea mediului de lucru? Pentru că toată lumea are deja unul funcțional și nimeni nu a mai construit de la zero de ani buni, așa că documentul alunecă. Remediul este ca următorul angajat să îl urmeze exact, fără să schimbe nimic, și să noteze fiecare eșec. Lista aceea este procesul real, iar reducerea ei la o singură comandă îi oprește alunecarea.

Ce documentație merită întreținută pentru onboarding? Cum se instalează și se pornește sistemul, cum se face deployul, ce formă are arhitectura și de ce, deciziile care altfel ar fi rediscutate și cine răspunde de ce. Lăsați deoparte tot ce spune deja codul, parcursurile prin ecrane care se schimbă lunar și referințele API scrise de mână.

Ce arată despre o echipă un onboarding lent? Că acele costuri absorbite fără să fie văzute sunt reale. Trei zile de instalare se plăteau dintotdeauna în sume mici de toți cei care refăceau o mașină. O componentă pe care nimeni nu o poate justifica costă decizii de mult. Un deploy pe care doar o persoană îl poate face era deja un risc înainte să vină cineva nou.