3 ms·
My former colleagues who was trained for PSP/TSP said that it is recommended to count on 4 hours per day in time-on-task activities. Planning for more ToT hours
by thesz 5y ago
My former colleagues who was trained for PSP/TSP said that it is recommended to count on 4 hours per day in time-on-task activities. Planning for more ToT hours will result in project being late as if it was planned for 4 hours/day ToT and people will have to work overtime (weekends).
I have to say that remaining 3.5-4 hours are spent on other tasks like documentation reviews, etc.
For time being we can assume relationship of performance regression is 4/ToT if ToT more than 4. This means that these Chinese workers perform 3.5 less work per hour or even less so. One can try to compensate by hiring more workers, say, 3.5 more workers but then the amount of communication will increase quadratically and there will be more than 12 times increase in communication needed for team(s) to work.
That means that "996" policy results in great underutilization of people's potential. My napkin calculation is that each "996" worker performs less than 1/30 of what he/she can do.
Regardless of culture, it is sad.
- 6keZbCECT2uB 5y agoDocumentation is time on task.
- burnished 5y agoI haven't written a lot of documentation, would you say that it requires the same level of mental focus? I understood the dividing line of 'time on task' as being what is difficult/taxing, whereas admin or docs (important tasks!) are relatively light weight.
- ericbarrett 5y agoI would; it’s a bit like teaching. For general documentation you need to refresh your mental model of the system and organize it to be explained to somebody without your familiarity. For specific areas (APIs, for example) you must review the assumptions in that domain and summarize them.
- plorkyeran 5y agoWriting _good_ documentation absolutely can be just as tiring as creating the thing being documented. It's quite common to not particularly value documentation quality and be happy with a mess of words churned out with little thought because at least it exists, but ensuring that it's accurate, covers all of the little details, and is organized well requires some careful thought and editing processes. With a formal division between "deep thought" work and "easy" work, I'd be inclined to churn out a rough draft of documentation in the second time box but then spend at least as much time as that in the first time box cleaning it up.
- HeyLaughingBoy 5y agoTSP/PSP makes no task differentiation according to what is difficult. If it directly relates to project deliverables, then it's considered time on task. I'd say that documentation that is expected to be used is every bit as difficult to create as good code.