În urmă cu cinci ani mă aflam în fața acestei întrebări, în momentul în care am acceptat mandatul de a implementa un program de optimizări într-o organizație de servicii IT cu peste 150 angajați. La vremea respectivă am estimat-o ca fiind o sarcină relativ simplă, de câteva luni, care se termină în momentul în care "ne definim procesele și obținem certificarea CMMI". Ce gândire simplistă și naivă! Mi-ar plăcea să fi avut gândirea de azi la acea vreme… Totuși este util să împărtășesc din aceste experiențe - uneori nu tocmai plăcute - în speranța că ele vor fi de ajutor pentru alții.
Ceea ce s-a întâmplat în acești cinci ani nu a fost doar o structurare, o implementare a unor procese, ci o schimbare completă de gândire privind calitatea si optimizarea modului de lucru, cu ajutorul mentorilor extraordinari cu care am avut plăcerea de a lucra. În realitate această sarcină asumată s-a transformat în cinci ani de eforturi serioase, determinare puternică de a nu renunța, care la final a schimbat gândirea și modul de lucru al întregii organizații. Astfel de programe nu sunt de neglijat. Ele sunt dificile, intruzive, imprevizibile și deseori sunt privite ca devieri fără sens de la "modul normal de lucru". Prin urmare, întrebarea naturală este: "merită efortul?".
În cursul acestor ani am mai avut ocazia să observ foarte multe persoane din domeniul IT - atât programatori cât și manageri, în companii mici și mari - punând această întrebare: "merită efortul?". Desigur cu alte cuvinte și alte nuanțe, dar cu aceeași esență, prin variații precum:
"Lucrurile au funcționat și până acum, de ce le-am schimba?"
"Nu ne dorim ISO sau CMMI, de ce ne-am complica?"
"Suntem o firmă mică, nu ne dorim gândire corporatistă, nu avem nevoie de asta."
"Nu avem timp anul acesta, poate altădată."
"Implică costuri ridicate, mai degrabă angajăm doi programatori."
"Am lucrat deja la procese și lucrurile nu s-au schimbat."
"Alții au inițiat astfel de programe și au eșuat."
"Noi am mai inițiat astfel de programe și am eșuat."
…și lista poate continua.
Uneori răspunsul vine din partea clienților (sau potențialilor clienți) care doresc o colaborare doar cu parteneri care pot dovedi o anumită maturitate organizațională. Acest lucru poate genera una din cele două reacții: fie (1) căutarea unor căi de ocolire, scurtături pentru obținerea unei certificări, fie (2) efectuarea unei investiții pe termen lung, optimizată pentru maximizarea beneficiilor. Din fericire, majoritatea managerilor ar opta pentru a doua variantă, însă grupul complementar este de o dimensiune deloc neglijabilă.
Însă acei clienți (sau potențiali clienți) interesați de acea maturitate organizațională sunt rareori interesați de ștampila sau de certificatul afișat la recepție. Ei sunt interesați de faptul că acele cazuri de succes afișate pe site-urile noastre sunt repetabile. Că ele au fost analizate, că ingredientele pentru succesul lor au fost identificate și sunt disponibile pentru proiectele de viitor efectuate în colaborare. Acest aspect este de importanță extremă pentru companiile de servicii IT din Europa Centrală și de Est. Deoarece întotdeauna se va găsi un competitor care oferă aceleași servicii fie la un preț mai redus, fie într-un timp mai scurt sau chiar ambele. Prin urmare, șansa de a rămâne competitivi pe o piață de servicii IT supra-aglomerată și volatilă, unde competiția devine globală, se regăsește în calitatea demonstrată și continuu optimizată. Dar calitatea înseamnă mai mult decât un slogan. În primul rând, aceasta trebuie DEFINITĂ, apoi trebuie MĂSURATĂ și DEMONSTRATĂ, iar în timp trebuie vizibil OPTIMIZATĂ. Din păcate acesta nu se poate obține prin ședinte. Modul în care se poate obține sunt programele de optimizare care necesită angajament și investiții.
Termenul de "Quality Assurance" are în fond o semnificație mult mai largă decât cea cu care ne-am obișnuit deja, dincolo de testare și dincolo de controlul calității. Existența unui sistem de QA funcțional poate reprezenta o diferență semnificativă și un avantaj competitiv major pentru oorganizație. Există o percepție greșită asupra ceea ce reprezintă QA: în marea majoritate a cazurilor prin QA se înțeleg activitățile efectuate de personalul de testare într-o echipă. Mai mult, uneori acest personal este simplist denumit "QA", nefiind parte din echipa de dezvoltare, în schimb testând rezultatele produse cu un decalaj de o iterație completă. În realitate,activitățile de testare sunt parte a QC (Quality Control) din ciclul de dezvoltare, verificând reactiv produsele/serviciile care s-au dezvoltat. În contrast, QA are o importanță net superioară: asigurarea calității produselor/serviciilor ce urmează a fi dezvoltate. Diferența dintre cele două concepte este majoră. De exemplu, QA include activități precum revizuirea artefactelor, activitate capabilă să detecteze de 8-10 ori mai multe defecte decât testarea în aceeași unitate de timp. QA facilitează reutilizarea experienței, metricilor și cunoștințelor - având ca una din urmări, creșterea preciziei estimărilor. QA creează condițiile ca fiecare persoană din echipă să-și înțeleagă rolul în echipă și așteptările față de acel rol, având la dispoziție practicile care să o faciliteze în efactuarea sarcinilor. QA verifică eficiența colectării și analizei metricilor, a raportării eficiente, ceea ce asigură planificări mai precise. Și lista poate continua…
Orice efort, timp sau buget alocat unui program de optimizări trebuie privit ca o investiție și nu un cost. O investiție care generază beneficii semnificative, superioare investiției. Cele mai multe metode de "ocolire" a investițiilor nu vor asigura succesul programului de optimizări, ci vor asigura opusul acestuia: schimbarea investiției într-o risipă irecuperabilă de resurse. Astfel de metode includ:
Doar execuție - fără training, fără suport, fără o viziune sau un plan.
Achiziția unui "tool" care să rezolve problemele.
Achiziția proceselor altora.
Elaborarea proceselor de către o singură persoană (preferabil într-o săptămână).
Inventarea proceselor noi.
Cumularea de multiple roluri pentru o singură persoană - de la definiție, măsurare, implementare și evaluare.
Totuși, cu o abordare corectă, sănătoasă, sunt posibile optimizări semnificative prin aplicarea unor principii simple:
Având ca punct de pornire actualul mod de lucru (optimizări, nu invenții).
Concentrare pe aspectele importante ale organizației.
Colectarea măsurătorilor relevante, publicarea lor în organizație.
Implicarea personalului în definirea nevoilor.
Apelarea la asistența profesională, training și mentoring adecvat.
Așadar, revenind la întrebarea originală: de ce ar merita efortul?
Deoarece facilitează supraviețuirea speciei de companie de servicii IT din Europa Centrală și de Est, în special sub-speciei caracterizate prin servicii outsourcing. Industria de servicii ITși în special cel de outsourcing, este extrem de expus competiției globale în timp ce comunitatea de freelancer-i oferă o alternativă accesibilă clienților. De aceea, companiile trebuie să poată demonstra evoluție, optimizări continue în timp pentru a nu fi eclipsate de competiție.
Deoarece promovează cel mai puternic avantaj competitiv: calitatea. Competiția poate oferi servicii mai accesibile și cu termene mai scurte, însă mult mai dificil poate demonstra calitatea superioară. Putem oare găsi o companie care să nu promoveze calitatea? Desigur, nu.Toate companiile oferă servicii și produse de calitate. Însă este extrem de dificilă definirea ei. De cele mai multe ori această definiție - dacă ea există măcar - se reduce la măsurarea termenelor și a costurilor pentru a demonstra calitatea oferită. De aici întrebarea naturală ar fi: aceasta înseamnă că ieftin și rapid este definiția calității? În realitate, definirea calității este o sarcină dificilă: puține companii reușesc să definească, să poată măsura și optimiza calitatea, iar aceste detalii pot oferi un avantaj competitiv extrem de important.
Deoarece reduce costurile corecțiilor reactive cum ar fi testarea, activitățile de fixing sau refactoring. Implementarea unui sistem de QA în organizație promovează mesajul "calitatea nu e problema altora" și asigură că oricine poate contribui la calitate, nu rămâne exclusiv în responsabilitatea echipei de testare. Asigură împărtășirea cunoștințelor, a practicilor de succes dovedite, pentru ca ele să fie refolosite. Asigură că metricile sunt colectate, analizate și consolidate în statistici care contribuie la precizie și predictabilitate pentru viitor. Asigură implementarea calității începând din primele faze ale proiectelor, unde investiția în training și în planificare poate garanta beneficiile pe parcursul proiectelor.
Deoarece facilitează învățarea continuă. Deseori se învață din greșeli. Orice persoană, echipă sau organizație produce greșeli și este normal ca acestea împreună cu concluziile aferente să fie analizate periodic în vederea evoluției. Însă aceasta nu înseamnă că pentru evoluție trebuie comise greșeli! Deseori ele nu sunt permise. De ce nu s-ar pune obiectivul realizării corecte asarcinilor din prima încercare? Limitarea cea mai frecventă este timpul - sau mai precis lipsa lui. Lipsa timpului pentru revizuirea artifactelor, sau pentru o planificare corectă, sau pentru un design tehnic corect, sau pentru activități corective. În realitate, timpul alocat acestor activități la începutul unui proiect se recuperează triplat în fazele ulterioare prin efort mult mai redus în activități de testare sau corective. Există o varietate largă de practici aplicabile, cum ar fi refolosirea cunoștințelor, experiențelor, a practicilor de succes dovedite sau a statisticelor.
Deoarece este practic și aplicabil, pretabil organizațiilor mici sau mari. A fi o mică firmă de start-up sau, din contră, o corporație nu mai reprezintă o scuză validă pentru a nu investi în optimizări.
Companiile mici au nevoie de creșterea cifrei de afaceri, de contracte mai valoroase, de clienți mai mari. Acești clienți pot fi exigenți, pot avea criterii bine definite pentru parteneri. Ar putea fi interesați de modelul SDLC, care nu ar reprezenta o problemă. Însă ar putea cere detalii și explicații pentru modul și raționamentul din spatele modelului, ceea ce necesită o bună pregătire. De multe ori modelul SDLC se descrie prin activitățile de design + dezvoltare + testare. Dar activitățile de planificare? Cele de monitorizare și control? Cele de configuration management sau change management? Poate risk management? Neavând definite aceste activități, modelul nu poate fi considerat complet. Planificarea fără monitorizare este o risipă de efort și timp. Monitorizarea fără o planificare adecvată este nonsens. Iar aceste detalii pot amenința un contract promițător în primele faze.
Marile corporații pot genera pierderi semnificative dacă nu sunt optimizate. Un efect al absenței optimizării este situația schizofrenică în care există munți întregi de cunoștințe în cadrul organizației fără ca ele să poată fi valorificate. Fără a avea o coordonare și viziune clară asupra rolului departamentelor sau activităților, strategiile și planurile își pierd claritatea, rezultând în confuzie și ineficiență în cadrul echipelor, ceea ce se traduce în întârzieri, timpi de așteptare și rework. Aplicat la echipe sau departamente de sute de persoane, pierderile pot fi surprinzătoare.
Deoarece conduc la rezultate tangibile, măsurabile, concrete. Iată câteva exemple publicate de Software Engineering Institute:
Reducerea anuală a TTM - câștiguri între 15% și 23%,
Creșterea anuală a ratei de detectare a defectelor - câștiguri între 6% si 25%,
Reducerea anuală a erorilor raportate - câștiguri între 11% si 94%,
ROI global - câștiguri între 400% și 880%.
Deoarece serviciile și produsele se adresează unor clienți din ce în ce mai exigenți, pentru care afișarea succeselor din trecut nu mai este suficientă. Trebuie demonstrate cauzele care le-au făcut să fie succese, factorii care au asigurat diferența dintre succes și eșec. Trebuie demonstrat modul de lucru în care ele s-au realizat. Și cel mai important, vor trebui convinși că repetarea modului de lucru va asigura repetarea succesului - iar pentru aceasta avem nevoie de procese repetabile.
Acestea sunt doar câteva motive pentru care optimizare modului de lucru merită efortul. Deși un program de optimizări complet, cu buget ridicat nu este accesibil întotdeauna,acest fapt nu ar trebui să reprezinte un impediment dacă există determinare. Există pași mărunți care se pot aplica în prima fază a optimizărilor:
Pornirea de la practicile existente în companie. Documentarea SDLC existent, identificarea lacunelor.
Definirea obiectivelor. Plan de acțiuni pentru atingerea lor.
Organizarea unor training-uri specifice pentru dobândirea competențelor critice cum ar fi project management, process improvements, risk management, dar și pentru familiarizarea cu unul din modelele aplicabile (CMMI, ISO, Six Sigma, TickIT Plus, etc.)
Concentrarea în primul rând asupra personal, deoarece este factorul principal în realizarea serviciilor și produselor de calitate, pe când un model sau un set de procese are doar rolul de a facilita personalul.
Consultanță profesională, pentru a face eforturile cât mai practice și a maximiza beneficiile cu aceleași investiții.
Abordarea în orice activitate, în orice circumstanțe, a ciclului Sheward-Deming: Plan-Do-Check-Act.
Organizarea de retrospective, colectarea și analizarea experiențelor și a metricilor
Revizuirea artefactelor, frecvent, aplicată pe toate tipurile de artifacte (specificații, planuri, design tehnic, cod, test case, etc.) .
Cu un angajament puternic, un astfel de program poate deveni mai simplu decât ar părea la prima vedere. În mod categoric efortul investit nu devine pierdere, beneficiile pot fi uimitoare. Sperăm că în viitorul apropiat mulți dintre cititorii acestui articol se vor pronunța în mod asemănător. La final, rămâne întrebarea: de ce nu ar merita efortul să ne optimizăm afacerea?