Vihaio schreef op donderdag 10 februari 2022 @ 14:38:
[...]
Maar een situatie waar tijd bijhouden niks toevoegt is niet haalbaar. Het is vaak gewoon handig/nodig om te weten hoe lang iets duurt. Dan kan je achteraf tijd gaan inschatten, of je houdt het gewoon bij. Waar ik vooral op reageerde was jou uitspraak dat uren bijhouden soms heel belangrijk is, maar nooit in software development. En daar ben ik het volledig mee oneens.
Als je denkt naar een situatie te kunnen waarin een software developers nooit hun tijd bij hoeven te houden, dan kan je ook naar zo'n situatie in elk ander beroep. Als je inziet dat het voor andere beroepen wel nuttig is, zou je ook in moeten kunnen zien dat het voor andere stakeholders nuttig kan zijn als developers hun uren bijhouden. Dat je dat niet leuk vindt om te doen, of dat de implementatie daarvan soms slecht is, staat daar los van.
Het internet is geweldig voor hyperbools en daar maak ik me ook schuldig aan
De reden waarom ik zo fel tegen tijd registratie is, zoals ik aangaf, omdat het niet nodig zou moeten zijn. Als er bijvoorbeeld met sprints gewerkt wordt dan is het vereist dat er van te voren de kosten bekend zijn. Immers aan het eind van de sprint moet alles af zijn. Omdat een sprint time-boxed is en niet effort-boxed zou het ook niet mogelijk moeten zijn dat er tussen door incidentjes behandelt worden tenzij je ook het risico op overmatige down-time in de sprint zelf plant.
Gaat het fout dan is er analyse nodig van hoe en wat. Als het eenmalig is dan is het een incident en dan kan je met relatief veel moeite de tijdslijn bepalen en dat gebruiken om te corrigeren.
Denk bijvoorbeeld aan het inleveren van een boek bij de bibliotheek. Ben je te laat dan krijg je een boete. Echter wat als je het toch de boek ingeleverd hebt en toch een boete krijgt? Dan kan je aan de stempel laten zien dat je het toch tijdig teruggebracht hebt. Die stempel? Dat is een impliciete tijd registratie. Het achterhalen kost echter tijd. En dan moet je overtuigen dat die tijdstempel overeenkomt met het boek. Veel werk, maar je doet het zelden in de praktijk.
Ga je aan expliciete tijd registratie doen dan heb je een logboek waarin je continue bij houdt wat en wanneer je iets ingeleverd hebt. Dit zodat wanneer je een boete krijgt je meteen kan zeggen dat je het boek wel ingeleverd hebt.
Als alles
goed gaat dan is tijd registratie
achteraf waardeloos. Met nadruk op "achteraf" en "goed gaat". Immers je hebt al de planning vooraf die voldoende is.
Werk je zonder planning of gaat het regelmatig fout, dan wordt het een ander verhaal. Dan zul je inderdaad actief moeten monitoren zodat het relatief minder inspanning vereist om de tijdslijn te bepalen als er vragen komen vanwege afwijkingen. Doe je dat niet dan moet je continue bewijsmateriaal matchen en dat kost erg veel tijd.
Dus heel kort door de bocht:
100% van de tijd volgens de planning => geen tijdslijn nodig => geen registratie nodig
90% van de tijd volgens de planning => soms tijdslijn nodig => achteraf opstellen
0% van de tijd volgens de planning => continue tijdslijn nodig => continue bijhouden.
Betreffend stakeholders:
Stakeholders hebben plannen met onze output en als we geen beloftes houden (of erger continue onze beloftes breken) dan moeten ze continue hun tijdslijn aanpassen aan die van ons. Dus moeten ze ook continue feedback krijgen.
Dat gezegd te hebben: De stakeholders die tijdregistratie op die manier toepassen zijn uitermate zeldzaam. Meestal zoeken ze alleen een wassen neus die bevestigd dat er gewerkt wordt. De stakeholders (of developer) die het correct gebruikt voor een root cause analyse heb ik nog maar een paar keer meegemaakt en dat was eigenlijk alleen omdat die stakeholder dusdanig vaak klaagde dat ik het uit zijn systeem wilde hebben.
Ergo mijn conclusie: Tijd registratie bij software developers met een betrouwbare planning is tijdverspilling.
Overigens heb ik een paar uitzonderingen eruit gelaten, maar die zijn allemaal incidenteel of vallen buiten de bovengenoemde nuances.
Enfin, ik hoop hiermee mijn stelling wat strengere criteria gegeven te hebben zodat we elkaar allebei gelijk kunnen geven
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel