Regula 80 : 20

regula

Principiul Pareto – cunoscut si sub numele “Regula 80:20” – este de fapt o lege a distributiei. Se refera la faptul ca mai multe procese au un raport de distributie similar. Mai exact, regula spune ca aproximativ 80% din rezultate vin de obicei din aproximativ 20% din cauze. Sigur – 80% si 20% sunt cifre relative. Ideea e insa ca cea mai mare parte a efectelor este generata de o foarte mica parte a cauzelor.

Sunt unele variatiuni ale acestei reguli care se aplica si in IT / Software Development. Ma voi opri in continuare la cateva dintre ele.

80% din buguri sunt cauzate de 20% din cod

Exista mereu o parte relativ mica a codului care cauzeaza cele mai multe probleme. De regula, vorbim de acea parte care este responsabila de functionalitatile principale. In general, e usor de identificat – insa orice interventie in aceasta zona trebuie facuta cu maxima precautie, de catre developerii experimentati. Practic, e acea parte a codului care va genera cele mai mari probleme daca nu este corect intretinuta. Iar din pacate intretinerea ei e mereu problematica, daca schimbarile care se fac in aceasta parte de 20% sunt numeroase si mari.

80% din schimbari sunt facute in 20% din cod

De regula, acest procent de 20% din cod e acelasi despre care vorbeam si mai sus. Putem spune ca 80% din schimbarile de functionalitate afecteaza aceeasi parte sensibila de 20% a codebase-ului, parte a carei intretinere ridica mari probleme in timp.
Schimbarile dese duc insa – de cele mai multe ori – la scaderea calitatii codului modificat. Mai ales daca sunt facute pe fuga si mai ales daca sunt facute de mai multi dezvoltatori care nu colaboreaza eficient, din diverse motive. Iar daca aceasta “masa critica” de 20% din codebase devine imposibil de intretinut, va trebui cel mai probabil rescrisa.

80% din downtime e cauzat de 20% din buguri

Bug-urile sunt clasate in functie de importanta si prioritati. Prioritare (si cu grad de importanta maxim) sunt cele care duc direct la downtime. Tocmai din acest motiv se incearca rezolvarea lor rapida si eficienta.
Aproximativ 20% din buguri vor fi mereu cele critice, care pun in pericol direct intreg proiectul – riscand sa-l faca inaccesibil pe o anumita perioada de timp.

80% din utilizatori folosesc doar 20% din functionalitati

Marea provocare in acest caz e identificarea acelei transe de 20% din functionalitati la utilizarea carora se rezuma cei mai multi utilizatori (80%). Putini, foarte putini utilizatori vor folosi produsul (proiectul) in intregime. Cei mai multi folosesc strict partile care-i intereseaza cu adevarat si care le aduc un beneficiu imediat.
De regula, in proiectele dezvoltate pe metodologia Agile (sau pe una care imprumuta conceptele de baza din Agile) se pune accent pe aceasta transa de 20% a functionalitatilor – in vederea lansarii cat mai urgente a unui MVP (Minimum Viable Product). Odata lansat, MVP-ul va aduna utilizatori in timp ce se lucreaza la restul de 80% din functionalitati, care vor fi utilizate mai putin – si in general doar de o marja mai mica din numarul total al utilizatorilor (20%).

80% din functionalitatea proiectului este realizata in 20% din orele lucrate

Regula complementara aici ar fi “20% din functionalitatea proiectului este realizata in 80% din orele lucrate”. Ambele sunt corecte, chiar daca cifrele sunt relative, dupa cum spuneam la inceput.
Complexitatea functionalitatilor unui proiect difera, ceea ce face ca si timpul necesar dezvoltarii lor sa difere. Chiar daca uneori partea vizibila a unei functionalitati majore este mica in comparatie cu altele, volumul de munca depus pentru realizarea ei poate fi semnificativ. De exemplu, functionalitatea de cautare pe baza de cuvinte-cheie intr-un proiect e-commerce cu sute de mii de produse poate parea banala, pentru ca pasii sunt simpli : (1) se introduc cuvintele cheie, (2) se da click pe butonul de cautare, (3) se afiseaza rezultatele. Insa indexarea si optimizarea intregului mecanism de cautare (ca sa raspunda in cateva milisecunde, de exemplu) ascunde deseori o munca titanica. In comparatie, realizarea layout-ului aceluiasi proiect e-commerce poate fi un task mai putin consumator de timp, insa cu un impact major asupra utilizatorilor. Adica un task care se incadreaza in acea parte de 80%, care e realizata in 20% din timp.

80% din rezultate se obtin in 20% din timpul investit

Aceasta regula are o tangenta mai mare cu nivelul productivitatii, pe intreg parcursul lucrului la un anumit task.
Putem fi productivi, insa nu putem fi constant la fel de productivi. Exista varfuri, la fel cum exista nivele medii sau scazute de productivitate. Insa rezultatele semnificative se obtin in perioadele de varf.

80% din timp este consumat de 20% din clienti

Timpul dedicat unui anumit client difera in functie de complexitatea proiectului sau – de ce nu – de proactivitatea/reactivitatea clientului respectiv. Exista o tendinta de a incadra clientii reactivi la capitolul “clienti dificili”. Nu sunt neaparat de acord cu asta, dar e un subiect despre care vom discuta probabil cu alta ocazie. Problema nu e neaparat ca un numar mic de clienti iti consuma cea mai mare parte din timp, ci ca iti ramane doar 20% din timp pentru ceilalti 80% din clienti – iar asta poate fi uneori insuficient. Pe de alta parte, rezervarea aceeasi marje de timp pentru fiecare client in parte este imposibila si neproductiva, pentru ca nu toti clientii vin cu proiecte de aceeasi complexitate si nu toti au acelasi tip de personalitate. Secretul (daca poate fi numit asa) e identificarea celor 20% care consuma cea mai mare parte a timpului si lucrul alaturi de ei la un tip de colaborare care sa consume mai putin timp, dar sa-si pastreze eficienta. In acest fel, raportul dintre numarul de clienti si timpul petrecut pe proiectul fiecaruia va avea sanse sa se echilibreze in timp.

Add a Comment

Your email address will not be published. Required fields are marked *