ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 22
Abonament PDF

Optimizarea – de ce ar merita efortul?

Tibor Laszlo
Partner & Consultant
@Improving-IT



MANAGEMENT


Î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 o organizaț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).
  • Documentarea practicilor existente, identificarea zonelor problemă.
  • 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?

  1. 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.
  2. 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.
  3. 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.
  4. 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 a sarcinilor 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.
  5. 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.
  1. 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.
  2. 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.
  1. Deoarece conduc la rezultate tangibile, măsurabile, concrete. Iată câteva exemple publicate de Software Engineering Institute:
  1. Reducerea anuală a TTM - câștiguri între 15% și 23%,
  2. Creșterea anuală a ratei de detectare a defectelor - câștiguri între 6% si 25%,
  3. Reducerea anuală a erorilor raportate - câștiguri între 11% si 94%,
  4. ROI global - câștiguri între 400% și 880%.
  1. 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?

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects