Când lucrezi cu colegi din trei țări, pe două continente și trei fusuri orare, fiecare zi începe cu aceleași întrebări: ce s-a întâmplat peste noapte, cine preia mai departe, unde sunt blocajele și cum păstrezi un ritm comun de lucru între locații care nu împart același program, același context și, uneori, nici același mod de lucru. În astfel de echipe, organizarea nu mai este doar un avantaj, ci o condiție de funcționare.
În proiectul nostru din zona automotive, am abordat aceste întrebări prin modul în care am făcut tranziția de la livrare locală la shared delivery, adică un model de lucru distribuit între mai multe locații. Astăzi, echipa reunește aproximativ 20 de persoane din Germania, România și India, inclusiv oameni de produs de la client. Proiectul acoperă mai multe sub aplicații, arii funcționale diferite, precum și activități de dezvoltare și suport operațional, ceea ce face ca nevoia de coordonare să fie constantă. Totuși, provocarea principală nu a fost organizarea în sine, ci integrarea. Articolul urmărește acest parcurs în patru etape: pre-onboarding, onboarding, business as usual și dinamica echipei.
Pentru ca noul coleg să poată începe efectiv din prima zi, demersurile pentru accesuri au fost pornite imediat ce colegul era confirmat pentru proiect. Chiar și așa, au existat situații în care accesurile nu au fost complet pregătite la timp. De exemplu, doi colegi au stat șase zile fără acces la repository. Practic, erau deja în echipă, dar nu puteau scrie nicio linie de cod. În plus, pentru că integrarea lor fusese planificată cu sprijinul unor colegi mai experimentați, timpul acelor colegi a fost consumat mai degrabă pe blocaje administrative decât pe transfer real de context. În proiectele cu clienți externi, o parte din accesuri depind de client, iar o parte de procese interne, ceea ce poate prelungi integrarea. Impactul nu este doar operațional: încetinește echipa, generează frustrare și creează o impresie neprofesionistă, atât intern, cât și în relația cu clientul.
Tot în această etapă am organizat sesiuni comune, inclusiv cu clientul, pentru clarificarea diferențelor culturale relevante în colaborarea de zi cu zi, cu accent pe ariile de business. Scopul nu a fost unul teoretic, ci crearea unui cadru comun de înțelegere pentru situații concrete: cât de direct se oferă feedbackul, cum este percepută ierarhia, când este semnalată o problemă și cum influențează fusul orar ritmul de lucru. De exemplu, am clarificat că unele blocaje veneau din reținerea de a contrazice direct sau de a fi transparent și direct, iar altele din diferențe practice, precum alinierea după ora Germaniei sau importanța pauzei de prânz în India ca moment social petrecut împreună. Am discutat și faptul că, în Germania, feedbackul este încurajat încă din familie și din școală, ceea ce îl face mai firesc și mai direct în mediul profesional. În România și India, această practică nu vine întotdeauna la fel de natural, iar feedbackul trebuie uneori cerut și încurajat mai conștient.
După ce etapa de pre-onboarding a fost structurată mai atent, efectele au devenit vizibile. Accesurile și drepturile au fost pregătite mult mai devreme, de regulă chiar din primele zile după intrarea în proiect, iar blocajele de început s-au redus. Practic, am câștigat timp real de integrare. În loc ca primele zile să fie consumate pe clarificări administrative, ele au putut fi folosite pentru înțelegerea aplicațiilor, a contextului funcțional și a modului de lucru. În paralel, și înțelegerea diferențelor culturale a devenit mai bună pentru toți cei implicați. Inclusiv din partea clientului a existat feedback că anumite aspecte legate de cultură și de modul de lucru au devenit mai ușor de înțeles în acest context.
În etapa de onboarding, a fost important să fie evitată situația în care un coleg intră în proiect fără să știe clar de unde să înceapă. În primele onboardinguri au existat cazuri în care colegii noi petreceau chiar 3-5 zile întrebând cine se ocupă de ce, iar abia când începeau efectiv să lucreze descopereau că le lipsește un acces sau că anumite lucruri nu funcționează. Tocmai acest tip de început am vrut să îl evităm.
Din acest motiv, onboardingul a fost construit împreună cu clientul într-o formă practică, astfel încât etapele de intrare în proiect să fie mai clare și mai rapide: ce accesuri mai lipsesc, cine preia partea tehnică, cu cine colaborează direct și ce urmează în primele săptămâni. Primele zile erau folosite pentru familiarizarea activă cu zona funcțională și tehnică. Un coleg nou discuta mai întâi cum funcționează o anumită sub aplicație, apoi parcurgea cu un coleg mai experimentat zone relevante din cod și înțelegea concret fluxurile de lucru. În funcție de temă, sprijinul venea fie din partea unor colegi deja integrați în India, fie din partea unor specialiști funcționali sau tehnici din celelalte locații.
Acolo unde era necesar, onboardingul a inclus și familiarizarea cu modul de lucru Agile, bazat pe colaborare și livrare în pași scurți. Pentru colegii mai juniori, acest lucru a fost important pentru înțelegerea sprinturilor și a ritmului de colaborare din Scrum Team. Într-un proiect cu multe sub aplicații complexe, această claritate face diferența. La fel de important s-a dovedit și fusul orar: dacă o întrebare apare prea târziu, răspunsul poate veni abia a doua zi. De aceea alinierea se făcea de regulă după ora Germaniei, astfel încât noii colegi să înțeleagă mai repede cui se adresează și în ce interval pot obține clarificări.
Un efect vizibil al acestei abordări a fost reducerea timpului până când un coleg nou putea lucra mai independent. Dacă la început acest lucru dura adesea peste o săptămână, ulterior perioada s-a redus vizibil, în multe cazuri, la doar câteva zile. Primele activități concrete de lucru au fost preluate mai repede, iar numărul blocajelor cauzate de lipsa contextului a scăzut.
În această etapă se vede dacă shared delivery funcționează sau rămâne doar o idee bună la nivel conceptual. Pe măsură ce echipa a crescut, a fost introdus Scrum of Scrums, iar echipa a fost organizată în Feature Team-uri, adică echipe structurate în jurul unor funcționalități sau zone de produs. Un Feature Team includea aproximativ trei colegi, ceea ce a clarificat responsabilitățile și a redus dependențele greu de urmărit. În același timp, Scrum of Scrums a făcut vizibile blocajele, interdependențele și prioritățile comune și a redus numărul ședințelor pentru programatori, deoarece participa doar un reprezentant al fiecărei echipe. Modelul a susținut și transferul de cunoștințe, pentru că structura Feature Teamurilor se schimba de la un release la altul, încurajând colaborarea și distribuirea expertizei între echipe. De exemplu, un coleg care acumulase context pe o aplicație într-un release ajungea să lucreze în următorul cu alți colegi, pe o altă zonă, transferând mai departe cunoștințele dobândite.
Una dintre practicile care a susținut cel mai bine acest model a fost Follow-the-Sun Pair Programming, o formă de colaborare în care colegi din fusuri orare diferite lucrează succesiv pe aceeași activitate. Procesul începea cu o scurtă aliniere pe contextul funcțional și pașii tehnici, apoi continua între colegi din Europa și India, pe baza unui transfer clar al contextului, responsabilităților și pașilor următori. Practic, activitatea era preluată mai departe în alt fus orar fără să se piardă timp pe reexplicarea contextului. Acest lucru s-a văzut rapid și în practică: într-un caz, un coleg din India a preluat o activitate fără context complet, iar în locul unei abordări individuale a fost organizată rapid o sesiune de lucru în pereche. Activitatea a fost finalizată în aceeași zi, iar transferul de cunoștințe și context s-a realizat direct în lucru real, nu doar la nivel teoretic.
Feedbackul constant a devenit esențial, nu ca formă de control, ci ca mecanism de aliniere și claritate. Ca Scrum Master, am fost în contact continuu cu managerii din India, dar și cu experții și mentorii implicați, pentru a discuta rapid problemele, a adapta abordarea și a căuta soluții. În plus, lunar primeam din partea managementului din India un fișier Excel în care completam pe scurt observații legate de evoluție, blocaje și posibile ajustări. În unele cazuri, acest lucru a dus și la decizii concrete, inclusiv ajustări rapide în componența echipei atunci când anumite profiluri nu se potriveau suficient de bine cerințelor proiectului.
Într-o echipă distribuită, colaborarea nu devine naturală de la sine. Ea trebuie construită. S-a conturat rapid faptul că procesele și instrumentele nu sunt suficiente. Pentru o colaborare stabilă, oamenii trebuie să se cunoască și dincolo de taskuri. Un exemplu a fost introducerea unor discuții informale scurte înainte de întâlniri, workshopuri sau seri de joc online. Deși pot părea detalii minore, în timp au schimbat vizibil dinamica echipei și au contribuit la o comunicare mai deschisă între colegi.
Un element esențial în această dinamică a fost implicarea constantă a clientului. Într-o echipă distribuită, în care mulți colegi nu s-au văzut niciodată, armonia și colaborarea trebuie construite activ. Participarea constantă a oamenilor de produs din partea clientului la evenimentele Scrum a redus timpul de așteptare, a limitat interpretările diferite și a făcut comunicarea mai relaxată, cu întrebări adresate mai ușor și neclarități semnalate mai devreme.
Și aici au existat rezultate vizibile, chiar dacă mai greu de cuantificat. Dacă la început exista reticență față de colaborarea în acest model distribuit, în timp feedbackul din partea clientului și al echipei a devenit constant pozitiv. În mod orientativ, timpul până la semnalarea blocajelor a scăzut, iar interacțiunile dintre locații au devenit mai directe și mai puțin formale.
Pre-onboardingul (accesuri + aliniere culturală) reduce pierderea de timp și fricțiunea din primele săptămâni.
Onboardingul funcționează când este practic și orientat pe context real, nu doar pe documentație.
În shared delivery, coordonarea între echipe (Scrum of Scrums) și clarificarea responsabilităților (Feature Team-uri) scad dependențele și ședințele inutile.
Follow-the-Sun Pair Programming accelerează integrarea și transferul de cunoștințe prin lucru direct.
Într-un proiect complex, cu multe zone funcționale, activități de dezvoltare, suport și echipe organizate pe funcționalități, shared delivery nu funcționează doar prin proces, ci atunci când integrarea este tratată ca parte a livrării. În cadrul proiectului, acest lucru a însemnat claritate, feedback constant și investiție în partea umană a echipei, nu doar în procese și activități curente.
Shared delivery nu este definit de locul din care lucrează oamenii, ci de modul în care aceștia ajung să lucreze împreună. Literatura de specialitate susține aceeași concluzie: în echipele distribuite, performanța nu vine doar din structură, ci din practici concrete de colaborare, transfer de cunoștințe, handoffuri clare și feedback constant (Yap, 2010; Kroll et al., 2014). Dincolo de teorie, asta s-a văzut și la noi: chiar dacă mulți colegi nu s-au întâlnit niciodată în realitate și au venit din culturi diferite, în practică nu am simțit aceste diferențe ca pe o ruptură, ci mai degrabă ca pe ceva ce a trebuit înțeles și construit corect. În timp, am ajuns să ne cunoaștem, să înțelegem diferențele și să lucrăm natural împreună, deși mulți dintre noi nu s-au întâlnit niciodată față în față.
de Silvan Stan
de Dragoș-Ștefan Popescu , Andreea-Roxana Cotfas , Denisa-Vasilica Măgurean , Remus-Octavian Cîmpean
de Ovidiu Mățan
