Să lucrezi de acasă este poate visul multor programatori. Indiferent de locul unde trăiesc și lucrează. Cum este să lucrezi în acest mod și cât de flexibil poate fi programul zilnic în Crossover?
Gelu Vac: Eu cred că este visul multor persoane active, care nu au neapărat meseria de programator.
Dar, într-adevăr, munca remote presupune extrem de multă disciplină. Este foarte ușor să-ți pierzi concentrarea și, în consecință, randamentul, care are efect direct în calitatea livrabilului, oricare ar fi el.
Și de aici pornește un cerc vicios ... Business ownerii nu vor să riște calitatea și făcând reverse-engineering, ajung să refuze ideea de muncă remote.
Gelu Vac - Software Engineering Manager @ Crossover
Dar adevărul este undeva la mijloc. Compromisul trebuie făcut din ambele direcții, iar o relație bazată pe încredere se construiește greu și se pierde instant.
Pe de o parte, Business ownerii trebuie să devină mai metricizați, respectiv să își descrie targeturile în segmente mai mici și măsurabile individual. Și mai ales realizabile. Pe de altă parte, angajații trebuie să devină mai responsabili în raport cu munca depusă și să înțeleagă faptul că targeturile asumate au legătură directă cu remunerarea. Practic, trebuie să încetăm să gândim în paradigma vindem timp, chiar dacă modalitatea uzuală de plată este tariful orar.
În mod cu totul particular, programul Crossover de lucru începe în fiecare săptămână lunea la ora 00:00:01 și se termină Duminică la ora 23:59:59. Interval în care trebuie să fie livrată o rată fixă de 40 de ore, adică norma săptămânală universală. Deci, în teorie, orele respective pot fi livrate absolut oricând, cu maxim de flexibilitate. Este important de accentuat că orice produs cu nivel de universalitate ridicat nu poate fi livrat de către o singură persoană. Întotdeauna există o echipă în spatele lui. Iar munca în echipă presupune multă comunicare. Directă sau offline, fiecare cu o anumită pondere.
De exemplu, o escalare și un show stopper trebuie servite instant, ceea ce presupune implicarea directă a membrilor echipei (analiza - dezvoltare - testare - livrare patch), în vreme ce un feature nice-to-have poate fi procesat prin procesarea offline. Pornind de la aceste premise și făcând reverse engineering, ne dăm seama că flexibilitatea se îngustează în umbra ședințelor de verificare și coagulare ale echipei.
De ce coagulare? Deoarece "chimia" dintre membri echipei există și în echipele remote. Acesta ar fi contextul general al premiselor muncii remote.
Până la urmă, Crossover este o firmă de software expusă celor două mari variabile: oamenii și tipologia proiectelor. Ca atare, flexibilitatea îmbracă influențele celor două variabile, modificând structural noțiunea de flexibilitate. La extreme, ar fi echipe în care se lucrează 90% obligatoriu program normal de luni până vineri, între 09-17 pe un anumit fus orar. Așadar, aceia de pe alt fus orar ar putea fi nevoiți să lucreze în intervalul de timp 18:00 - 02:00. De asemenea, sunt echipe în care se lucrează 90% obligatoriu de luni până duminică, 7 ore din 24.
Care sunt tehnologiile folosite cel mai des?
Gelu Vac: Din păcate nu am cifre exacte, dar aș putea face estimări, cu o doză ridicată de certitudine, cu privire la câteva segmente tehnologice. La nivel de limbaje de programare, probabil cea mai mare pondere o are Java, urmata de Ruby și C#. Dar avem și proiecte de C++, Android, Objective C, etc. .
La nivel de sisteme de operare ne adresăm absolut tuturor : Windows, iOS ( despre care cred că sunt lideri detașați), urmați de Linux, Ubuntu, MacOS.
Pentru versionare folosim exclusiv GitHub, în care integrăm tone de tooluri pentru verificarea sintaxei, standarde de cod, CI/CD, etc. .
Raportam tickete în Jira, versiune de server, dar customizată și automatizată la un nivel record de procese. Soluția de cloud cea mai utilizată este de departe cea de la Amazon dar folosim și Azure.
La Customer Support folosim Zendesk integrat cu Jira.
Pentru serviciul de email folosim Gmail for business, cu tot pachetul Office, etc. . Testarea performanței, prin TestRail integrat cu Jira. Comunicarea directă, prin Skype și Slack, iar ședințele prin platforme gen Bluejeans, Zoom, GoToMeet.
Echipele distribuite necesită un management special, fiind mai dificil decât atunci când toată echipa este în aceeași clădire. Aplicați standardul Agile scrum remote? Ce procese sau tooluri speciale folosiți?
Gelu Vac: Cu această întrebare ai atins un punct sensibil. Managementul de o calitate superioară și performanța echipelor în abordarea remote sunt probabil cea mai mare provocare. Dacă în management este vorba despre strategie și despre responsabilitatea deciziilor pe o unitate de timp, în modul remote, feedbackul are o latență considerabilă și presupune un anume nivel de stabilitate emoțională, necesar adunării feedbackului de la o echipă întreagă. La acest demers de colectare de feedback este important să se țină cont de factorul timp, mai ales de diferențele de fus orar. Pentru a-ți face o imagine mai clară, îți ofer niște repere legate de echipa mea: la Vest, cea mai îndepărtată colegă era în Sillicon Valey, California (GMT-7) și cel mai la EST coleg este în Vladivostok, Rusia (GMT+10). Ca atare, din cauza diferenței de fus orar, feedbackul unei echipe se colectează în minim două zile. Acestea sunt datele problemei în contextul rolului de manager de produs sau de manager de inginerie din Crossover.
Revenind la metodologie, consider că discuțiile despre Agile sau Waterfall s-au stereotipizat. Se vorbește despre ele ca într-un sistem de coordonate închis, în care cele două metodologii sunt extreme diametral opuse. De asemenea, în toate țările în care se face outsourcing (și România nu face excepție), noțiunea de manager s-a diluat la nivelul unui rol remunerat convenabil și cu o marjă bună de profit, către un terț fericit de un cost redus.
Crossover face parte dintr-un grup de firme al căror obiect de activitate este centrat exclusiv pe Produse. Crossover nu face deloc outsourcing, fiind preocupat doar de calitatea și de succesul Produsului. De aceea, dacă trebuie să rigidizezi un proces în sistem Waterfall, o vei face fără să clipești. Pe acea secțiune. Dacă va trebui să iei decizia să implementezi ceva din Agile sau Scrum, procedezi la fel, fără ezitări. Pe acea secțiune. Ambele pe același Produs. De multe ori în aceeași săptămână. În realitate, utilizăm paradigma Enterprise Unified Process extinsă pe mai multe roluri, iar ca tooluri, ne folosim de workflow-urile din Jira combinate cu grupuri de utilizatori. Aplicând aceste principii, am reușit să implementăm procese care să ne diminueze considerabil costurile, fără să facem rabat de la calitatea livrabilelor.
Deși se lucrează pe produse diferite, o mare parte din acestea aparțin grupului de firme, Trilogy, din care face parte și Crossover. Care sunt principalele provocări și ce avantaje apar atunci când companiile pentru câte se scrie software-ul fac parte din același grup?
Trilogy și mai nou ESW Capital nu sunt doar o umbrelă de gestiune a mai multor firme. Ideea grupului se bazează pe un model de fabrică. O fabrică uriașă, în care sunt mai multe secții, care colaborează între ele pentru a scoate la capăt un produs. Avantajul pe care se bazează ESW Capital este că, spre deosebire de orice alt domeniu, ( de exemplu, industria de hardware, unde procesul tehnologic este complet diferit pentru realizarea fiecărei piese), un produs software se produce identic, indiferent ce face el. Așadar, dacă grupul de firme are în componență 60 de societăți comerciale și 147 de produse software, să nu te aștepți să găsești 147 de echipe de analiză de produs, 147 de echipe de dezvoltare, QA, etc. . Secretul raționalizat în Fabrica ESW Capital este că are o singură secție de analiză, o singură secție de development, o singură secție de testare, o singura secție de livrare, etc. . Toate procesele sunt standardizate în așa fel încât să semene în proporție de 99%. Restul de 1% ar fi doar un risc asumat de asezonare totală cu segmentul de consum al fiecărui produs. Și orice developer poate intra în orice moment să livreze o implementare, cu risc minim pentru produs și fără a cunoaște efectiv produsul.
Cum vezi jobul de programator peste zece ani?
Gelu Vac: Programatorii au un cost tot mai ridicat, chiar și în țările cu tradiție în off-shoring. Ca atare, asaltul asupra diminuării costurilor îi va surprinde pe tot mai mulți prin specializarea continuă a limbajelor și a platformelor de implementare. În schimb, va rămâne necesitatea supra-specializării în integrarea tehnologiilor, pentru că banii de la consumatori finali se colectează prin rezultanta proceselor software și nu individual prin fiecare proces. Produsul vinde. Rezultatul final al întregului proces de producție face bani. Tehnologic vorbind, consider că un rezultat al super-specializării la nivel de platformă va asigura oricui conversia la jobul de programator. Dar nu cred că programatorii prin conversie vor fi vreodată o amenințare reală pentru programatorii de profesie așa cum se tinde să se stereotipeze în discuțiile publice. La nivel economic, respectiv în antreprenoriat, mă aștept să crească viteza de prototipare și de segmentare excesivă pe paradigme de consum, care va avea ca rezultat creșterea ratei de eșec a ideilor antreprenoriale. Probabil că soluția, în acest caz, ar fi o fabrică de idei, pentru care se depun eforturi de construire în acceleratoare de business - dar în care încă nu am văzut o soluție complet integrată. Mă aștept la o raționalizare a exercițiului de elaborare a ideii de consum, pornind probabil de la cererea potențială de consum, astfel încât să pot contura perfect și complet orice idee de business, în cel mai scurt timp posibil.
de Kiss Tibor
de Elena Leu
