Nu inca…
Si nu poti face asta fara sa iti masori timpul la minut, folosind tool-uri? Nu-ti ajunge capul de pe umeri? Daca nu iti ajunge, poti oricand folosi tool-uri. Problema este cand esti fortat (1) sa folosesti tool-uri, care pot fi folosite pentru a iti crea dezavantaje (to say the least). Cat de intortochiate sunt acele task-uri de nu stii cum sa le imparti? Tight-coupling, anyone?
De ceva ce tie ti-se pare normal, altii n-au auzit in viata lor.
Problema este cand issue/task tracking-ul devine time tracking… iar softurile de genul fac tranzitia respectiva foarte usoara.
(1): Ma refer la faptul ca daca angajatii accepta sa lucreze sub acele coditii, probabilitatea ca acele conditii sa devina norma(l) creste. Si nu e nevoie decat de un manager sa caute un motiv pentru a fi sanctionat pentru ceva ce nu ai facut. (Poate i-ai intors vorba cand nu avea dreptate cand te certa ca din vina ta nu a putut fi completat proiectul in care nici n-ai luat parte, lucrand la cu totul altul.)
Exceptia confirma regula. (Iubesc vorba asta.) Cum, spre exemplu, se recomanda sa tratezi exceptiile inainte de cod, pentru ca ce ramane dupa ce ai tratat cazurile exceptionale sa fie rezolvarea problemei in cauza, poate n-ar fi o idee rea sa incercam sa folosim aceeasi modalitate si pentru rezolvarea problemelor care nu pot fi rezolvate scriind cod.
Offtopic:
Tu nu crezi ca un creier este suficient pentru a emite teorii valide? Daca n-am fost angajat pana acum, nu inseamna ca nu am “lucrat” (asta include si invatatul/studiatul). Pana la urma, un programator nu trebuie sa poata simula toate tipurile de situatii posibile, pentru a se asigura ca nu exista erori in codul scris?
Sau vrei sa spui ca, mai nou, am nevoie de facultate de business pentru a-mi deschide o afacere? Bun, nu am fost angajat, dar internetul este plin de exemple. Doar fiindca tie nu-ti place unul din exemple, nu inseamna ca nu poate fi perfect valid. Iar exemplul dat de mine poate fi cu atat mai daunator cu cat o persoana are mai putina experienta.