În ultima perioadă s-a vorbit destul de mult despre modul în care au fost afectate (sau nu!) companiile IT după această criză generată de pandemia de COVID-19. În acest context, credem că este important să se analizeze cauzele care au dus la apariţia unora dintre problemele cele mai mari. Ne vom referi doar la companiile IT și vom avea în vedere mai ales companiile din Cluj. Am formulat 12 întrebări care pot ajuta orice manager sau profesionist din domeniu să înțeleagă mai bine prezentul și să își construiască mai sănătos viitorul.
Poate că, în urma unei analize atente, se va descoperi că există foarte multe lucruri care se pot schimba la nivel de organizaţie, prin îmbunătăţiri structurale și calitative aduse culturii organizației, climatului de lucru, dar și fiecărui proiect. Credem că, înainte de a menţiona că au fost scăderi salariale sau au fost eliminate beneficii (ca efecte ale situației dificile), trebuie să ne gândim la cauzele care au generat situațiile dificile din unele companii.
Suntem convinși că, înainte de a fi luat măsuri care să afecteze organizaţia şi oamenii cu care lucrează pe termen lung, decidenții de top din marile companii ar fi trebuit să folosească oportunitatea actualei crize pentru a descoperi ce nu a funcționat cum trebuie în activitățile companiei, înainte de pandemie. Din păcate, deciziile dure de reducere a personalului, salariilor și beneficiilor au venit rapid și, în foarte multe cazuri, analiza critică și onestă a cauzelor crizei a lipsit. Ceea ce înseamnă că se lucrează la efecte, nu la cauze. De aceea, în viitor problemele vor continua să apară.
Vom face o scurtă analiză generală, fără a nominaliza companii sau lideri, bazându-ne pe un set de întrebări directe și clare. Invităm cititorii să ia acest set de întrebări și să îl aplice, transparent și onest, organizației lor. Punctual, pentru fiecare organizaţie, ar putea exista foarte multe alte întrebări particulare. Depinde doar de liderii și angajații fiecărei companii IT să își pună toate întrebările necesare și să caute răspunsurile corecte.
Criza va trece mai devreme sau mai târziu, dar nu toate organizațiile vor reuși să iasă vii și nevătămate din actualul context. Unele își vor descoperi problemele și le vor rezolva, ieșind mai puternice din această încercare, altele vor continua să se mintă și să evite confruntarea cu problemele reale, iluzionându-se că vor putea reveni ușor la paradisul prosperității și lăcomiei, de dinainte de pandemie.
Productivitatea este o măsură a eficienţei producţiei. Eficienţa (randamentul) angajaţilor a scăzut probabil semnificativ o dată cu pandemia, pentru că oamenii au fost nevoiţi să lucreze într-un alt mediu şi în alte condiţii. Din punct de vedere tehnic, multe probleme pe care le rezolva de obicei compania au fost lăsate în sarcina angajatului. În acest fel au existat mulţi factori colaterali care au generat o "abatere" de la programul zilnic și au dus la scăderea productivității.
Au existat impedimente legate de platformele și canalele de comunicare, conexiunile VPN, vulnerabilități de securitate a datelor şi alte deficiențe tehnice. Pe termen scurt, sistemul work from home este benefic pentru cei care au un spațiu propice de lucru acasă. Dar foarte mulţi oameni au fost afectaţi în activitatea zilnică pentru că s-au schimbat radical condiţiile de muncă şi modul de abordare: acasă nu au la dispoziție condițiile ideale de lucru, dacă e să luăm în calcul aglomerarea familiei, copii zgomotoși sau implicați în cursuri online, vecini care renovează, internet cu viteză slabă, lipsa unor echipamente etc.
Comunicarea a fost şi rămâne un aspect extrem de important în activităţile de dezvoltare software. Toţi cei implicaţi activ în echipe de software development ştiu că munca în echipă înseamnă pair programing, testare în echipă, şedinţe de analiză, găsire de soluții prin colaborare, knowledge sharing, use cases etc. Toate acestea s-au mutat online și au devenit mai obositoare, greoaie și lipsite de consistență.
Echipele care folosesc frameworkul SCRUM au descoperit că un daily stand-up meeting cu întreaga echipă remote este mult mai dificil online, deoarece comunicarea este mai greoaie și mai neclară. Foarte multe echipe au renunţat la daily stand-up sau l-au transformat în episoade mai restrânse. Să ne gândim și la şedinţele de review în SCRUM. Cât de accesibil este un sistem de test în care se pot face demonstraţii? Dacă într-un astfel de meeting este prezent şi clientul, cât de uşor este pentru client să urmărească livrabilul? Ce facem ca să devenim mai productivi? Îi întrebăm și pe oameni, poate au idei?
Atunci când ne referim la o echipă corect alcătuită ne gândim la o componenţă care să răspundă într-un mod adecvat nevoilor tehnice pentru dezvoltarea proiectului/produsului. Poate că am realizat în această perioadă în care nu am lucrat de la distanţă, că foarte multe echipe au avut dificultăţi pentru că:
Au existat juniori în echipe care au avut nevoie de mai multă îndrumare.
Cei cu mai multă experienţă au fost implicaţi brusc şi în alte activităţi.
Credem că este bine să ne gândim la problema componenței echipelor şi să răspundem creativ dacă putem îmbunătăți lucrurile. Evaluăm componenţa echipelor pe bază unei matrice de competenţe şi a gradului de răspuns în rezolvarea problemelor? Ne gândim că e nevoie de traininguri adecvate, adăugăm în taskurile zilnice timp pentru prezentarea unor informaţii tehnice şi acordăm timpul necesar pentru sedinţele de knowledge sharing?
Da, aceste şedinţe trebuie să fie eficiente şi să abordeze topicurile concret. Credem că, înainte de a lua decizii de concediere, reducere a salariilor sau suspendare a programelor de învățare, companiile și echipele ar trebui să facă o foarte necesară și cinstită analiză, pentru a identifica precis cauzele care au dus la scăderea eficienţei și la apariția erorilor. Fiindcă echipele care funcționau treacă-meargă în contextul de la birou nu mai funcționează atunci când oamenii sunt împrăștiați pe la casele lor.
Sunt foarte multe proiecte care au fost amânate fiindcă unii clienți au probleme sau pur și simplu au suspendat unele. Dar sunt proiecte suspendate și fiindcă echipele de sales şi presales nu au putut să realizeze în timp util o comunicare directă cu clientul, nu au putut să facă prezentări ale soluţiilor și nu au reușit să obțină un agreement pentru a începe. Clientul nu a avut posibilitatea să vadă anumite demonstraţii ale aplicaţiei, nu a putut să adreseze suficiente întrebări şi proiectul s-a pierdut sau, în cel mai fericit caz, a fost amânat.
Apoi, lipsa unei nevoi urgente pentru o anumită aplicaţie a generat amânarea ei sau renunţarea la achiziţia unui produs software. Trebuie să luăm în calcul şi faptul că în această perioadă nevoile clientului s-au schimbat foarte mult. O analiză corectă a acestor nevoi poate salva multe proiecte viitoare. Dar credem că au existat şi cazuri în care s-a pierdut un proiect pentru ca nu s-a livrat ceea ce se dorea, nu au fost respectate specificațiile şi nu s-a livrat la termenul stabilit.
Ce putem învaţa de aici? Ce ar trebui să analizăm pentru a vedea unde sunt probleme? Dacă ne vom pune câteva întrebări, poate că vom reuşi să vedem ce avem de învăţat şi ce putem îmbunătăţi:
Am documentat foarte bine prezentările pe proiecte? Sunt simple şi uşor de urmărit?
Avem un pachet bine organizat cu ceea ce dorim să vindem, descris într-o manieră care să faciliteze chiar şi o discuţie online cu clientul?
Cât de uşor este să preluăm şi să descriem noi features?
Avem un sistem de organizare clar, structurat pe business case-uri?
Asigurarea calității este un aspect extrem de important. Pentru a realiza produse software de calitate trebuie să avem şi procese bine definite, flexibile, uşor de adaptat şi mai ales simple şi aplicabile. Trebuie să verificăm şi să înţelegem dacă procesele de dezvoltare software existente ne-au ajutat sau nu în această perioadă.
Dificultăţile tehnice de comunicare, timpul necesar uneori pentru stabilirea conexiunilor şi apoi timpul acordat pentru a explica lucruri pe care ar fi trebuit să le avem undeva documentate într-un tool, într-o pagină de wiki, au redus din timpul efectiv de muncă concretă pentru rezolvarea unui task. Pentru o analiză concretă şi punctuală credem că este necesar să răspundem la câteva întrebări:
Am analizat corect la sfârşitul fiecărui proiect, al fiecărei integrări de produs plusuri şi minusuri în procesele pe care le avem la nivel de proiect? Exemplu: în cazul în care folosim metodologia Agile și frameworkul SCRUM, cât de repede am îmbunătăţit procesele pe parcursul dezvoltării şi cât de uşor au fost asimilate de către echipă? Am avut dificultăţi în a respecta release-uri? Cum s-au desfăşurat şedinţele retrospective? Cât de uşor a fost să organizăm sedinţele de Sprint review? Am avut infrastructura tehnică necesară pentru a prezenta rezultatele (de exemplu, sistemul de test funcţional?) Ce putem face în perspectivă pentru a avea infrastructura necesară?
După ce se răspunde la aceste întrebări se poate face un plan global de îmbunătăţire la nivel de companie şi se pot implica resursele existente care, poate, au rămas fără un proiect concret.
Avem nevoie de procese simplificate, de instrumente care să ne ajute să colectăm informaţiile la nivel de individ, echipă și organizație, să le organizăm și să le oferim, accesibil, tuturor celor care au nevoie de ele în diverse momente. Cum facem concret acumularea și gestiunea informaţiilor în interiorul companiei? Am oferit suficiente traininguri specifice proiectului în care angajatul este implicat? Colectăm eficient documentaţia internă utilă?
Avem la nivel de organizaţie instrumentele necesare în care să colectăm date fundamentale despre munca noastră, de la How To... până la What if? Avem un KMS (Knowledge Management System) care să acumuleze toată informația despre cunoștințele și proiectele noastre, despre modulele dezvoltate deja sau despre specificațiile, metodele și bazele de date implicate și care să ajute la optimizarea resurselor folosite?
Mai mult, avem în organizație un LMS (Learning Management System) pe care toți colegii să îl poată accesa, în orice moment, pentru a găsi răspunsul la întrebări, pentru a descoperi date relevante fără a îi deranja pe alții și pentru a asimila aptitudini noi, pentru a parcurge și singuri o parte din ciclurile de învățare?
Am discutat mult un topic colateral legat de calitate şi suntem siguri că aici se încadrează şi trainingurile necesare unui angajat. Fără îndoială, investițiile în asimilarea de soft skills sunt utile, însă multe companii uită că oamenii trebuie să evolueze și în zona cunoștințelor specifice domeniului. Sigur că e nevoie şi de training-uri de comunicare, dar avem nevoie de traininguri tehnice, de traininguri pentru asigurarea calităţii produsului, de traininguri pentru a înţelege domeniul pentru care produc software, pentru a putea oferi soluţii eficiente.
În ultimii ani, foarte mulţi specialişti plecați din companii au fost înlocuiţi cu angajați mai puţin experimentați și calificați, care au foarte multe dificultăţi în înţelegerea întregului proces de dezvoltare software. Clienților li s-au vândut de multe ori echipe cu expertiză supraevaluată, iar acest lucru a dus la satisfacție redusă și de multe ori la pierderea unor proiecte. De foarte multe ori, în această perioadă s-a pierdut timp pentru că au fost lucruri neclare, pentru că persoane noi din echipă au avut nevoie de mai mult suport tehnic care era foarte uşor acordat în birou, unde fiecărui task i se puteau asocia informaţii verbale foarte utile.
Oare am avut suficiente traininguri corect alese și aplicate? Oare am oferit suficiente traininguri tehnice colegilor, în aşa fel încât să aibă resursele tehnice necesare dezvoltării software-ului şi a unei oarecare independenţe în a lucra pe o anumita nişă? De câte ori am supraevaluat sau subevaluat cunoştinţele unui angajat atunci când am avut nevoie de un anumit număr de ore pentru un proiect? Știm că această evaluare eronată costă enorm și produce efecte toxice?
Cu siguranţă atunci când vine vorba despre integrarea unui proiect la client este clar că această etapă a fost blocată în perioada pandemiei din cauza măsurilor stricte de deplasare atât în ţara de origine cât şi la clienţi internaţionali.
Poate că trebuie să ne gândim şi aici la implementarea unor soluţii care să poată automatiza o bună parte din munca de deploy on site. (nu ne referim la partea de hardware). Integrarea proiectelor on-site poate să fie automatizată? Putem simplifica anumite aspecte ale instalării?
Probabil foarte multe proiecte s-au pierdut şi pentru că etapa de analiză nu s-a făcut corect sau pentru că echipele nu au reuşit să se adapteze unei analize operate online, la distanță. Sunt multe feluri în care putem să îmbunătățim această activitate de analiză. Avem instrumentele necesare pentru etapa de analiză a unui proiect (fie că utilizam Agile sau Waterfall)?
Toţi ştim cât de importantă este analiza inițială corectă a proiectelor în evoluţia fiecărui proiect, indiferent de metodologia folosită. Credem că trebuie să ne punem şi aici cîteva întrebări: Avem instrumentele necesare pentru a realiza analiza remote? Avem procese simple de analiză? Avem instrumente uşor de utilizat ? Ne-am gândit să lucrăm prototype-based acolo unde se poate?
Credem că este important să găsim instrumentele necesare pentru a înţelege care este valoarea exactă pe care fiecare persoană din echipă o aduce în proiect. Auditarea unui proiect în timpul desfăşurării şi la sfârşitul lui ne poate aduce informaţii vitale despre proiect şi despre performanţele echipei.
Considerăm utilă o analiză mai detaliată a modului în care au fost evaluate uneori rezultatele și performanţele unui proiect. De multe ori, organizațiile uită să inventarieze "lessons learned", deși aceasta este o etapă importantă la finalizarea unui proiect. Poate că trebuie analizate în detaliu performanţele pentru care se acordă recompensele și beneficiile componenților echipelor.
Un alt aspect care a generat foarte multe probleme în această criză a fost şi faptul că anumite proiecte nu au avut o organizare foarte bine pusă la punct. De cele mai multe ori în cazurile proiectelor ratate, procesele nu sunt bine definite şi acest lucru afectează atât calitatea muncii, cât și calitatea produselor.
De fiecare dată trebuie să se folosească instrumentele (tools) potrivite pentru fiecare etapă de dezvoltare a unui proiect. Am pierdut oare controlul pentru că nu avem instrumentele necesare? Sau pentru că nu le aplicăm corect, coerent, consistent? Trebuie să analizăm cu foarte mare atenţie dacă avem procese clare şi dacă aceste procese sunt implementate corespunzător în toolurile folosite.
În cele mai multe cazuri, echipele de suport răspund cerințelor clientului, dar de foarte multe ori apare nevoia de a cere informații suplimentare și chiar efort de asistență, prin implicarea echipei de development. Acest lucru se întâmplă mereu atunci când proiectele livrate nu sunt corect documentate, iar transferul acestora de la echipa de dezvoltare la cea de exploatare sau mentenanță este superficială, inconsistentă și incompletă.
O altă situație apare când se pierd contracte de mentenanță din cauza faptului că beneficiarii nu percep valoarea și utilitatea acestora. Trebuie să privim cu atenție: există posibilitatea ca anumiți clienți care au fost inactivi în această perioadă să nu apeleze la serviciile de suport. Echipele de suport au fost probabil nevoite să rămână în așteptarea unui request, dar concret nu au avut incidente. Acest lucru nu înseamnă că trebuie să interpretăm că pe viitor asistența lor nu va fi necesară și să luăm decizii neinspirate de realocare a resurselor respective.
Ce facem în situațiile în care, temporar, nu apar incidente? Cum motivăm și cum ținem activă echipa de suport? Poate că implicarea oamenilor în activități interne de dezvoltare a unor instrumente care să simplifice activitățile de suport sau în elaborarea unor documentații (evident într-un KMS/LMS) ar fi o oportunitate și ar motiva echipa. Am avut totuși nevoie de sisteme din interiorul companiei care au avut nevoie de mentenanţă? Să alocăm aceste echipe pentru astfel de proiecte.
Intenţionat am lăsat această întrebare la sfârşit. Trebuie şi aici să răspundem la câteva întrebări pentru a înţelege problemele. Avem instrumente eficiente și verificate la intervale regulate pentru colectarea datelor atunci când vine vorba de numărul de ore lucrate pe proiecte?
Facem prea mult micro-management. Sigur acest aspect a ridicat multe probleme în contorizarea şi centralizarea orelor în foarte multe proiecte. Acordăm o prea mare atenţie acestui aspect în loc să "învăţam" angajaţii să fie implicaţi şi să folosească eficient timpul de lucru. Oare e nevoie de tooluri de monitorizare? Și, dacă le folosim, în ce măsură pot fi ele "fentate" și cât de mult ne arată acestea adevărul?
Putem să analizăm şi să gândim un sistem eficient de colectare automată a orelor din toolurile de software development? Da, se poate! Și putem astfel să eliminăm foarte multe ore consumate inutil, în care cei care trebuie să facă acest lucru pot gândi noi STRATEGII de dezvoltare. Putem să stimulăm mult creativitatea prin aducerea în discuţie, apelând la reţele interne, a unor proiecte mici de îmbunătăţire în activităţile zilnice. Implicarea în astfel de proiecte generează şi o abordare creativă şi responsabilă, dar şi învăţarea unor noi tehnologii. Win-win.
Considerăm că trebuie să înţelegem că livrarea unui produs software nu înseamnă doar scrierea unui cod mai mult sau mai puţin de calitate. Credem că trebuie să înţelegem că monitorizarea unui commit nu înseamnă neapărat nici calitate şi nici eficienţă.
Atunci când vom înţelege că suntem parte dintr-un întreg şi că fiecare acţiune va face ca întregul să rămână intact, atunci când vom înţelege cu adevărat cât sunt de complexe și cât trebuie să fie de clare și transparente procesele de dezvoltare software, vom privi cu RESPONSABILITATE rezultatul pe care fiecare dintre noi trebuie să îl livrăm.
Credem că trebuie să înţelegem că responsabilitatea se cultivă. Putem învăţa la nivel de echipă şi organizaţie că asumându-ne cu adevărat responsabilitatea, manifestând integritate și onestitate, dobândim un brand personal credibil, puternic, valoros, care produce efecte benefice pentru oameni, pentru echipe și pentru organizațiile în care lucrăm.
Un citat atribuit lui Osho ar putea să ne fie de folos: "Libertatea nu înseamnă lene și nepăsare. Libertatea este responsabilitate. Dacă tu nu-ți asumi responsabilitatea, o va face altcineva pentru tine. Așa devii sclav."