Nu există răspuns ideal la întrebarea de mai sus, dar cu siguranță sunt lucruri de îndreptat în acest sens. Totul pornește de la nevoia de informație, iar nevoia de informație este contextuală și vine cu cunoștințele și cu experiența managerilor sau a clienților.
Dacă ar fi să mă refer la o relație de tipul client-furnizor, unde furnizorul este plătit la timpul lucrat pentru client, am putea găsi o utilitate. Eu și echipa raportam timpul de fiecare dată, dar abia într-un singur caz clientul era interesat realmente de detaliile la ceea ce se făcea zilnic și citea rapoartele frecvent. Era un fel de lectură de seară pentru el și chiar am simțit că ne ajuta. Atunci când în raport începeau să apară semne că o luăm pe arătură ne trimitea sfaturi în luarea deciziilor. Același lucru se putea întâmpla și dacă am fi făcut ședințe zilnice de sincronizare în cadrul echipei. Nu există moment mai potrivit să vezi cum avansează echipa și care sunt problemele cu care se întâlnește decât în ședința zilnică (daily scrum), iar clientul ar fi putut participa.
În restul cazurilor, nici măcar când se verifica factura nu se citeau detaliile din raport.
După Jeff Sutherland, în articolul Why time sheets are lame?, raportarea timpului:
- demotivează dezvoltatorii,
- duce la cel puțin 10-15% pierderi în performanță,
- dezvoltatorii trebuie să falsifice timpul ca să dea bine numerelor,
- duce la date eronate folosite în raportare și astfel managementul ia decizii proaste,
- amăgește clienții,
- n-are nimic de a face cu calitatea produsului,
- concentrează întreaga organizație pe date false în locul producției.
Raportarea timpului ne distrage atenția de la progresul real. Noi trebuie să privilegiem software-ul funcțional înaintea documentației vaste (a doua valoare din manifestul agil), software-ul funcţional fiind principala măsură a progresului (al șaptelea principiu agil din același manifest). Altfel se creează iluzia progresului, precum în exemplul din în Grafic.
Nu cred că raportarea timpului are un impact direct în pierderea performanței de 10%-15%, dar sunt de acord cu cele de mai sus și că nu există corelații:
- între timpul petrecut de dezvoltator și producția de software,
- între timpul petrecut și calitatea codului,
- între „oamenii de calitate” și producția codului.
La care aș mai putea adăuga că:
- încurajează orele suplimentare la muncă și
- adâncește diferențele dintre ierarhii
Orele suplimentare la muncă
Fiecare zi se termină cu 8 ore raportate, ceea ce ar însemna un factor de concentrare de 100%. Este fals. Și n-am văzut până acum niciun raport de timp în care să apară timpul petrecut pentru raportare deși mereu durează între 5 și 30 de minute.
Diferențele dintre ierarhii
Dacă raportarea timpului este atât de importantă, de ce nu o face toată lumea? Și rareori mi s-a întâmplat să văd echipele de la client să raporteze așa cum o făcea echipa mea, ceea ce mă face să cred că era doar un instrument de control.
Când să raportăm timpul?
De fiecare dată când echipa de dezvoltare consideră că este necesară. Clientul poate să vadă concret ce a realizat echipa la final de iterație alături de un simplu raport de prezență.
Productivitatea echipei
Într-unul din exercițiile pe care-l fac în cursul de Kanban, rog echipa să noteze pe post-it-uturi timpul petrecut pentru realizarea fiecărui produs. După prima iterație îi întreb dacă găsesc utilitatea timpului raportat. Răspunsul este nu, deși la astfel de curs participă preponderent manageri care cer echipelor lor să raporteze timpul. Dacă un client mi-ar cere astăzi ca echipa să-i raporteze timpul, nu prezența, aș încerca să înțeleg mai întâi ce-i lipsește. S-ar putea să fie o problemă de transparență sau de încredere. În exercițiul dat exista o vizibilitate permanentă asupra progresului, nivel excelent de transparență pentru oricine vrea să afle ce face echipa.
Cât de importantă este raportarea timpului?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 2272 ori