Conul de Incertitudine, descris de Steve McConnel, arată ceea ce orice profesionist experimentat în domeniul software știe. Și anume că la începutul oricărui proiect nu știm cu exactitate cât timp va dura un proiect.
Motive pentru acest lucru sunt multe. Niciodată două proiecte nu au:
- Aceleași cerințe.
- Aceiași oameni.
- Același context de afaceri.
- Aceeași tehnologie.
- Aceleași priorități & constrângeri.
Care este unic. Fiecare linie de cod este lucrată manual. Iar munca de cunoaștere care implică oameni creativi și inteligenți nu se pretează la precizie așa cum se pretează săparea șanțurilor.
Și totuși, precizia este ceea ce se cere. Sponsorii vor să știe exact când va fi finalizat proiectul și cât va costa.
Afacerea cu această enigmă este aproape la fel de veche ca și timpul însuși. Iată câteva modalități prin care echipele și companiile fac față acestei incertitudini.
Afacerea cu conul
Subliniați estimarea
După ce simțiți înțepătura subestimării, o reacție comună este de a dubla sau tripla estimarea data viitoare. Acest lucru scade cu siguranță riscul inițial, dar umflarea cifrelor este mai dificilă decât pare.
Dați o cifră prea mare, iar sponsorii se vor eschiva și nu vă vor aproba proiectul. Dați o cifră prea mică și riscați să rămâneți fără bani. Acest lucru devine de două ori mai riscant atunci când participați la licitații pentru contracte cu ofertă fixă, unde există o presiune și mai mare pentru a menține cifrele la un nivel scăzut.
Majoritatea proiectelor adaugă un fel de umflătură la cifrele finale pentru a-și oferi suficient spațiu de manevră. Un alt lucru pe care echipele îl pot face este să compare acest proiect cu altele.
Dimensionați relativ proiectul
Oamenii sunt foarte buni la dimensionarea relativă a lucrurilor. Nu putem să vă spunem cu precizie cât de mare este o piatră. Dar putem să vă spunem cât de mare este în comparație cu altceva. Putem folosi acest lucru și atunci când dimensionăm proiectele.
Să fim deschiși și cinstiți
Modul de operare implicit al Agile este transparența și vizibilitatea. Așa că nu ar trebui să fie o surpriză faptul că modul Agile de abordare a condeiului este să fim direcți și cinstiți.
Vezi. Nu știm cât timp va dura acest lucru. Aceasta este cea mai bună presupunere a noastră. Dar dacă ne dați câteva iterații, putem să construim ceva, să măsurăm cât durează și apoi să vă dăm o idee mult mai bună despre cât de mare este acest lucru.
O altă abordare pe care unele echipe Agile o vor adopta pentru a ajuta la comunicarea incertitudinii este de a prezenta estimările sub forma unui interval.
Aceasta are avantajul de a arăta în mod vizibil sponsorilor incertitudinea care însoțește proiectul, iar apoi îi lasă pe sponsori să decidă cât de mult risc își pot permite să își asume.
Fundați incremental
O altă abordare care are mult sens, dar, din păcate, nu o văd aplicată suficient de des, este finanțarea incrementală.
Cu finanțarea incrementală nu cereți tot sacul de bani de la început. Doar atât cât trebuie pentru a trece cu vârf și îndesat o parte suficientă din muncă, pentru a raporta o cifră mai bună despre cât timp va dura.
Nu este infailibil. Încă mai poți avea probleme mai târziu. Dar dând echipelor 30-50.000 de dolari, lăsându-le să construiască ceva și văzând cât timp durează, se poate reduce foarte mult variația acestei cifre inițiale.
Puteți citi mai multe despre acest mod de planificare și avantajele pe care le aduce în Beyond Budgeting
Cauza principală
Vom trăi într-o lume a bugetelor anuale. Și, din nefericire, acest lucru determină o mare parte din tensiunile și dramele de la locul de muncă. În unele privințe, bugetele anuale sunt firești (trăim și urmărim timpul în cicluri anuale), dar în altele sunt teribile pentru planificare, deoarece un an este o perioadă lungă de timp pe piață.
Dacă vă treziți că vă împiedicați de conul de incertitudine, amintiți-vă doar că scopul estimării software-ului este de a determina dacă proiectul este chiar posibil.
Sau, așa cum spune Steve McConnell:
Scopul principal al estimării software nu este de a prezice rezultatul unui proiect; acesta este de a determina dacă țintele unui proiect sunt suficient de realiste pentru a permite ca proiectul să fie controlat pentru a le îndeplini.
-Steve McConnell, Software Estimation: Demistificarea artei negre
.