voi aborda întrebarea din perspectiva ingineriei software, deși multe dintre lecțiile învățate se aplică și altor proiecte. Producerea estimărilor exacte ale proiectului este una dintre cele mai grele sarcini de făcut în ingineria software și o abilitate adesea trecută cu vederea pe care majoritatea inginerilor (inclusiv eu) nu știu să o facă bine. Este, de asemenea, cazul în care persoanele care nu au avut nevoie să estimeze timpii de finalizare pentru proiecte înainte tind să subestimeze dificultatea și adesea își greșesc estimările cu cel puțin un factor de doi. Ca orice abilitate, unul devine mai bun doar cu practica.
cea mai vie amintire a estimărilor de proiect care au mers prost s-a întâmplat la câteva luni după ce s-a alăturat ca inginer la Ooyala, un startup care a furnizat o platformă video online end-to-end. În August 2008, la doar puțin mai mult de un an de la înființarea companiei, echipa de ingineri a început să lucreze la o rescriere a playerului video bazat pe Flash al produsului. Obiectivele noastre au fost să facem jucătorul mai modular și mai performant și să avem, de asemenea, o bază de cod mai curată și mai bine testată. O echipă inițială de 3 persoane a proiectat și a scris o infrastructură de bază înainte de a trage în mine și restul echipei de inginerie ~10-persoană. Au estimat 4 luni pentru finalizarea proiectului, iar CTO și product manager au produs diagrame Gantt care rezumă defalcarea lucrărilor și dependențele. Noul jucător a ajuns să se lanseze complet 9 luni mai târziu, în mai 2009 .
am ratat ținta nu din lipsă de muncă grea sau ingineri talentați; au existat o serie de luni în care majoritatea oamenilor din echipă au tras 70-80 de ore săptămâni (nerecomandate). Partway prin proiect, am trecut chiar cu migală prin câteva zile în valoare de exerciții în cazul în care am atribuit estimări orare pentru sarcini destul de granulare. Cele mai mari întârzieri au rezultat aproape întotdeauna din factori, mulți externi, pe care nu i-am luat în considerare în estimările inițiale:
- au fost semnate oferte de clienți cu prioritate ridicată, care au necesitat inginerilor să comute contextul la munca personalizată,
- bug-uri din Codul flash Player Adobe care au făcut dificilă determinarea exactă a momentului în care videoclipul a fost întrerupt, tamponat și redat,
- bug-uri de corupție video greu de reprodus care ar prăbuși playerul atunci când caută anumite cadre video în IE,
- dezvoltarea produsului care trebuie reluată 4 luni în proiect, în scopul de a menține baza de clienti curent fericit,
- probleme de scalabilitate care trebuiau abordate ca suma de datele analitice au crescut,
- un inginer timpuriu care a părăsit echipa la mijlocul proiectului, necesitând o cantitate mare de transfer de cunoștințe a părților majore ale bazei de cod,
- etc.
în timp ce rescrierea jucătorului a fost cu siguranță necesară pentru companie, modul neprevăzut în care a fost târât a avut un impact mare asupra lansării timpurii. Alte proiecte la care am lucrat, am văzut la mâna a doua sau am vorbit cu alți ingineri, au urmat modele similare în care timpul efectiv de finalizare dublează adesea estimările inițiale.
iată câteva dintre lecțiile mele de luat masa atât de departe de aceste experiențe:
pe cât posibil, oamenii care produc estimările pentru o sarcină să fie oamenii reali care vor lucra la ea. Acest lucru este similar cu punctul lui Ian McAllister de a folosi estimarea B-player – este deja incredibil de dificil pentru o persoană să prezică cu exactitate cât timp ar dura o listă de sarcini, chiar dacă sarcinile sunt destul de granulare; este chiar mai greu de prezis cât timp ar dura altcineva cu un grad diferit de familiaritate și un grad diferit de abilitate. A devenit evident în timpul rescrierii jucătorului lui Ooyala că multe dintre estimările inițiale au fost extrem de agresive și au ignorat timpul de rampă al unui inginer pe părți ale bazei de cod cu care era mai puțin familiarizat.
Feriți-vă de efectul celui de-al doilea sistem. În miticul om-lună, Frederick Brooks descrie din experiențele sale de proiect de la IBM cum o tendință umană de a supra-proiecta al doilea sistem duce la o complexitate substanțial crescută, determinând alunecarea calendarelor proiectelor de reproiectare:
prima lucrare a unui arhitect este apt să fie de rezervă și curată. Știe că nu știe ce face, așa că o face cu atenție și cu mare reținere.
pe măsură ce proiectează prima lucrare, i se întâmplă jabou după jabou și înfrumusețare după înfrumusețare. Acestea sunt stocate pentru a fi utilizate ” data viitoare.”mai devreme sau mai târziu, primul sistem este terminat, iar arhitectul, cu încredere fermă și o stăpânire demonstrată a acelei clase de sisteme, este gata să construiască un al doilea sistem.
acest al doilea este cel mai periculos sistem pe care un om l-a proiectat vreodată… Tendința generală este de a supra-proiecta al doilea sistem, folosind toate ideile și bibelourile care au fost distrase cu precauție pe primul.
mai ales pentru un proiect care implică rescrierea software-ului existent, este tentant să grupați o mulțime de funcții noi în ceea ce altfel ar fi putut fi un port simplu, folosind argumentul că echipa ar putea la fel de bine să o facă dacă oricum vor rescrie baza de cod. Complexitatea crescută nu poate duce nici la rescrierea, nici la lansarea noilor caracteristici decât semnificativ mai târziu.
aveți grijă să combinați cât timp va dura sarcinile unui proiect cu cât de curând va termina un proiect. Cu cât un proiect durează mai mult, cu atât este mai mare probabilitatea ca variabilele externe de mediu să intre în joc și să extindă cronologia generală a proiectului. Tragerea recurentă pe care Ian o menționează contribuie la cronologia unui proiect, dar la fel și evenimentele neașteptate. Pentru proiectele pe care le-am lucrat la începutul acestui an la Quora, un număr dintre ele a durat mai mult pentru a lansa decât era de așteptat din cauza costurilor de timp cumulate ale:
- răspunzând și recuperându-se de la o întrerupere AWS neașteptată, de mai multe zile,
- gestionarea alertelor de pager perioide pentru a menține site-ul în sus,
- vacanțe programate care odată păreau departe de un proiect, dar care au ajuns să se suprapună cu acesta,
- pregătirea și participarea la evenimente de recrutare,
- comutarea contextului între mai multe proiecte acest lucru s-a dovedit a fi mai complicat decât se aștepta inițial.
pentru orice proiect, s-ar putea enumera probabil orice număr de evenimente și distrageri care individual ar putea fi improbabile sau necostisitoare, dar care colectiv sunt obligate să se întâmple și să se adune într-un interval de timp suficient de lung. Cu cât proiectul este mai lung, cu atât vor exista mai multe distrageri și este important să bugetați timp tampon pentru factori externi, necunoscuți.
buget suficient timp pentru orice sarcini legate de integrare. În special pentru proiectele cu multe componente interdependente, mulți ingineri tind să 1) amâne sarcinile de integrare end-to-end până la capăt și 2) subestimează semnificativ timpul necesar pentru a integra toate piesele împreună într-un sistem de lucru. Deoarece integrarea tinde să fie atât de departe și pentru că riscurile sunt de obicei necunoscute-presupunerea prin timpul de integrare este că toate componentele funcționează cu succes izolat-subestimarea timpului de integrare tinde să fie destul de comună. Proiectele primesc adesea doar o fracțiune minusculă din timpul total al proiectului pentru testarea end-to-end, chiar dacă este de obicei unul dintre aspectele mai riscante ale unui proiect și, în comparație cu etapele anterioare, necesită o comunicare substanțial mai mare între membrii echipei.
corolarul acestui lucru este de a începe testarea end-to-end cât mai curând posibil pentru a identifica riscurile și problemele de integrare mai devreme, astfel încât să existe suficient timp pentru a le aborda.
estimați în funcție de cât timp vor dura efectiv sarcinile, nu în funcție de cât timp doriți dvs. sau altcineva să le ia. Întotdeauna va exista presiune pentru a finaliza proiectele mai repede, fie de la tine, de la membrii echipei tale, de la conducere sau de la clienți și de multe ori răspunsul emoțional la acea presiune ne ancorează la termenele cerute din exterior și ne conduce la subestimarea sistematică a sarcinilor. Din punct de vedere psihologic, nimeni nu vrea să-i dezamăgească pe ceilalți și este ușor să vă spuneți că, dacă lucrați puțin mai greu sau mai eficient, puteți respecta un anumit termen. Cu toate acestea, în special pentru proiectele lungi, acest tip de gândire dornică este în cele din urmă nesustenabilă.
revizuiți și revizuiți periodic estimările proiectului pe măsură ce proiectul continuă. La fel cum cel mai bun software este construit și îmbunătățit treptat, la fel sunt și estimările proiectului. Revizuirea estimărilor proiectului și compararea estimărilor pentru sarcinile din ultima săptămână cu timpul efectiv necesar ajută la evidențierea greșelilor de estimare și la revizuirea programelor pe baza riscurilor neprevăzute anterior.
estimările proiectelor tind aproape întotdeauna să fie subestimate, mai degrabă decât supraestimate; rareori se aude că proiectele lungi se termină înainte de termen. Fiind conștient de faptul că estimarea proiectului este greu și reflectând pe ce estimările a mers prost pe un anumit proiect vă va ghida spre spre erori de estimare mai mici pe proiecte ulterioare.
executarea unui proiect înseamnă mult mai mult decât producerea unor estimări exacte. Dacă sunteți inginer și doriți să stăpâniți tehnicile utilizate de inginerii software de top pentru a-și transforma proiectele în succese, descărcați un capitol gratuit, eșantion din cartea mea, inginerul eficient. Este plin de sute de povești, perspective și strategii acționabile de la lideri din întreaga Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html