distributed teams

De cand o ard freelancer, cu exceptia proiectelor in care ma duc cateva zile la client sa fac cate o chestie punctuala, lucrez in echipe distribuite pe proiecte la distanta:

  • eu si cu oamenii de la client
  • eu, alti freelanceri si oamenii de la client

Ce inseamna distribuit? Pai ca fiecare suntem pe unde ne nimerim si facem treaba impreuna. Fiecare cu ce stie mai bine cand e super mult de treaba, sau fiecare cum e mai liber sau cand e ceva de depanat si trebuie sa ne punem capetele la contributie.

Cel mai important in toata treaba asta e sa ne sincronizam cu ce facem, ce planuri avem etc. Pentru ca nimeni nu poate tine minte tot ce-a zis, sau ce-o sa facem sau cum, mai ales cand nu ai mintea intr-un singur loc tot timpul, dar chiar si-asa.

Ce merg ca si tool-uri pentru asta:

  • Slack (in mare parte) pentru conversatii in timp real care sa ramana si scrise, snippet-uri de configuratii sau cod, iar in ultima vreme chiar si pentru conferinte. Skype e o idee super proasta pentru ca mai pierde mesaje, clientul se misca super greu cand sunt multi oameni care scriu (cel putin ala nou de pe mobil e o retardare crunta).
  • Skype/Hangouts in mare parte pentru conferinte. Desi pe Skype merge cu clientii corporate ca nu-i lasa politicile de firma pe Slack. In principiu merge orice solutie de videoconferinta care permite si screen-sharing.
  • JIRA. Urmarirea task-urilor, “accountability” in sensul de cine ce-a facut si cand. Exista si alte sisteme de ticketing, insa pe unde m-am dat doar JIRA era.
  • Google Docs pentru prezentari, scris documente in echipa (ocazie cu care am ajuns sa urasc mailurile alea cand se plimba un document pe la fiecare sa mai scrie ceva in el si dupa aia ala de trebuie sa le puna cap la cap se sinucide subit).
  • Confluence (unde e) pentru documentat procese, arhitecturi, howto-uri si alte cele. Acum mai nou (de anul asta) stie si asta de editare concurenta, ceea ce e foarte misto. Daca nu e confluence, atunci Wiki-ul din GitHub. Sau orice altceva tip Wiki unde sa ai mereu informatia la zi.
  • GitHub pentru cod. De obicei scripturi sau chestii de configuration management. Merg si solutiile hosted precum GitLab, da tre’ sa ai grija de ele :))

Ca toata treaba asta sa mearga bine, e nevoie de doua componente esentiale:

  • Comunicarea (duh). Adica sa fii la curent la ce lucreaza membrii echipei, sa spui cand te apuci sa faci ceva sa nu se trezeasca altul ca i-ai restartat masina pe care lucra, iar in cazurile sensibile sa explici ce vrei sa faci si de ce ca sa elimini erorile de gandire. Ca desi poate ai o idee buna, aplicand-o strici mai multe decat repari.
  • Procesul. Adica treaba de mai sus sa zici ce faci, tichete prin care se poate urmari progresul si documentarea operatiunilor sau, dupa caz, adaugarea de comentarii utile in cod sau pe commit-urile de git. E foarte important aici sa n-o arzi “cowboy style” ca se duce totul pe pula super repede.

Periodic, o data pe saptamana sau mai rar/des in functie de volumul de munca si de cati sunt in echipa, niste teleconferinte de sincronizare fac minuni. E ca terapia in grup: fiecare spune la ce lucreaza, raspunde la intrebari de la altii ca sa inteleaga lumea mai bine lucrurile, se formuleaza planuri, se dezbat si se trag concluzii.

Este de remarcat faptul ca in functie de cat de OK este echipa si de cum se raporteaza membrii echipei unii la altii, cu atat mai productive sunt aceste teleconferinte. Suna a truism, dar daca raportul de forte este dezechilibrat, rezultatele nu vor fi chiar cele asteptate.

Lucrul asta merge super bine cand te cunosti cu aia cu care vorbesti, si bine cand nu te cunosti dar esti “on the same page” sau la acelasi nivel de cunostinte. Si prost, evident, cand nu exista deloc aliniere intre oameni, cunostinte si proiect.

Ce nu merge prea bine e cand faci lucruri remote si nu te-ai vazut niciodata cu oamenii cu care lucrezi si exista intelegeri diferite asupra aceluiasi lucru. Treaba asta am rezolvat-o prin a ma duce sa ma vad cu oamenii, sa vorbim, sa discutam si de alte chestii in afara de munca si atunci lucrurile se imbunatatesc.

Fara un pic de “personal touch” nu prea merge treaba asa cum ar trebui, si prin asta se elimina multa neintelegeri si sincope in colaborare.

Evident, sunt si lucruri care nu merg distribuit daca co-echipierii nu au experienta cu ceva anume si este si greu sa explici cum vrei sa arate lucrurile de la distanta. Oricate desene ai face, nimic nu se compara cu dusul la fata locului si explicat/aratat ce si cum. Dar aici se aplica treaba cu vizita la fata locului descrisa mai sus.


Ziceam la inceput ca “fiecare pe unde e”. Asta poate insemna mai multe lucruri:

  • fiecare e in acelasi timezone sau +/- o ora, maxim doua.
  • fiecare e pe continente diferite.

Pentru proiectele care necesita lucru cu clientul in timpul programului lui de lucru, atunci e  bine sa nu fii la prea multe ore distanta fata de client; ca nu e nici o distractie sa ai conferinte la 4 dimineata sau la 12 noaptea, sau sa incepi programul la 17 si sa termini la 02. Sau sa incepi la 4 dimineata sa apesi butoane. Cel mai important aspect fiind ca-ti futi tot ritmul circadian si o sa fii mereu defazat fata de restul societatii, da daca esti mai “special” e ok, nu pierzi nimic :))

Pentru proiecte cu activitati asincrone si fara restrictii, cum ar fi tichete care trebuie rezolvate/implementate oricand, atunci orice loc cu ceva Internet e suficient, ca poti fi si +/- 11 ore fata de client ca n-are importanta.

Astea fiind zise, cand lucrezi distribuit sau solo, ideal ar fi sa ai numai clienti care nu necesita sa fii si tu treaz cand sunt ei la munca, si in felul asta sa poti sa te plimbi peste tot in lume ca n-ai nici un impediment. Sau mai bine zis, asta ar fi “the perfect work/life balance” ;)

2 thoughts on “distributed teams

  1. Vis-a-vis de faza cu “plimbat documente”, acum 1000 de ani, cand facea plopu’ pere si rachita micsunele, toata lumea avea Windows 3.11 si WGPO-uri iar toate companiile erau strict ierarhice, exista in MS Word o chestie care se numea “Add routing slip …”.
    Chestia aia te lasa sa alegi gigei din organizatie si sa trimiti un fel de mail care se ducea *pe rand* pe la gigeii din lista si cand trecea de ultimul, se intorcea la tine. Pentru ca era Microsoft Mail, avea si un formular frumos care era afisat fiecarui gigel (pe rand, cum ziceam) si care continea optiunile “Am modificat documentul, uite versiunea noua”, “Documentul e de cacat, te rog fa-l dinnou”, “Documentul e bun asa cum e, da-l mai departe”.
    Primul si ultimul buton faceau mesajul si documentul sa se duca la urmatorul gigel, cel din mijloc facea sa se intoarca la tine tot.

    Chestia asta cuplata cu “Track changes/Show changes” in MS Word era cam ce face Google Docs/MS Office 365 acuma :) Si se intampla cam prin ’93-’95 asa ;-)

    1. Atunci mergea la nivel de organizatie, cand infrastructura client/server era omogena si aveai procese bine puse la punct. Acum cand fiecare are MUA-ul preferat, OS-ul preferat…

Leave a Reply

Your email address will not be published. Required fields are marked *