Articol publicat in: Corporate, Internet, Tehnologie
Ni se intampla adesea, noua, celor care lucram in internet, sa fim ipocriti si sa nu scoatem o vorba cand tuturor le e clar ca am gresit. In acelasi fel, nu ne gasim niciodata vinovati cand apare o problema, dar nu ne ferim din a-i trage de urechi pe cei care au avut vreo vina in sirul de intamplari nefericite care au provocat o problema. Sunt momente in care suntem supraoameni – ‘Errare humanum est’.
Mai mult, avem tendinta de a ne raporta la modelele de drept in domeniu, doar cu privire la ce e mai usor si mai inutil – cum aseaza un buton sau altul, nu cum se organizeaza pentru a produce niste servicii de succes.
Iata ca gigantii din internet – Facebook si Google – si mai micul Twitter ne povestesc despre problemele pe care le intampina pe bloguri sau pe siteurile de status:
Intai, problemele sunt normale. Tehnologiile sunt in plina expansiune, cresterile exponentiale ale celor mai cunoscute siteuri si companii din industrie determina noi si noi concepte si aplicatii – se lucreaza la marginea tehnologiei. Sistemele sunt complexe chiar daca sunt compuse dintr-un set de sisteme simple, interdependente. Iar sistemele complexe esueaza.
Facebook dezvolta pe ideea:
‘Move fast and break things!’
Isi incurajeaza inginerii sa se implice si sa vina cu idei. Cei buni au satisfactia de a vedea in productie ce au lucrat azi dupa urmatorul daily build, adica a doua zi. In plus, cu toate testele, cu deploy pt intern, apoi pentru in set de cateva mii de servere, in care totul pare in regula, surprizele pot fi neplacute la deployul global – lucrurile comise vor avea buguri sau vor incetini siteul.
In cazul lui facebook pierderile sunt probabil enorme si totusi exista politica asta. Ca inginer la facebook, probabil ca sentimentul de mandrie ca ai livrat ceva pentru jumatate de miliard de oameni e la fel de coplesitor cand ceea ce ai facut NU merge. Ce se intampla atunci: se scoate din productie ceea ce nu merge, dupa o serie de teste de regresie in care se determina ce loc in codebase genereaza problema. Apoi se cheama programatorul care a scris liniile respective ca sa rezolve problema. NICIODATA nu se cheama omul care a facut code review sau deploy.
De aici revenim la problema cu care am inceput. Opinia mea umila este ca daca apare un bug online sau se intampla ceva neprevazut, e mai bine sa nu disperi si sa nu ti consumi energia ca sa gasesti vinovati. Primul lucru pe care sa te concentrezi e rezolvarea problemei.
Una dintre cele 18 reguli ale lui Dalai Lama spune:
Cand iti dai seama ca ai facut o greseala, fa imediat ce trebuie ca sa o corectezi.
De aici “zero defects methodology”.
- sa-ti accepti esecul (din vreme si de fiecare data)
- sa vorbesti ca de la om la om
- sa ai un canal cunoscut de comunicare prin twitter, blog sau, si mai profesionist, printr-un public status dashboard
- sa fii autentic
- sa nu uiti sa povestesti despre
-
- momentul de inceput si momentul de sfarsit al incidentelor (cat a durat problema)
- ce a mers prost
- cine a fost afectat
- lectii invatate
Inca ceva:
Complaining is silly. Either act or forget!
(Am scris pe telefonul mobil, nu am diacritice, imi cer scuze!)
