Quick Kill Project Management + GTD ratio
While there is a relative quietness in the Java Community as a whole since the advent of IoC etc. etc. Some new annotation-based web frameworks, new server-side scripting tools ala rails doesn't really draw too much attention. There isn't much breakthrough in Java EE for someone to move into it hastily. Developer's now realize that they always run into particular problems which has become a pattern in every project, a pattern usually starts with setting up the new framework for the development environment, testing it and hoping it works, if didn't then join the framework's forum and shout for help, in the case of commercial or proprietary tools it will take around 2-3 days and coming up with a wrong answer most of the time. This is where helluva sleepless nights starts.
There are plenty of tools and frameworks out there some are helpful and some are not. But nobody really talks about "getting things done" or GTD. I don't agree that this should only fall under the project management's responsibility. When we sometimes play a lead role in development team we focus too much on standardization from code writing to internal processes. But how much of these really helps in bringing up our GTD ratio? What standards should we keep and let go?
And then there's Quick-Kill Project Management a very interesting article from Dr. Dobb's. I think the "Quick-Kill" is just a catch because the way the process goes, except for the code review, is the same as the process we had on how I made my first Vernier Caliper out of our school's machine shop during my Secondary School/High School days. And that's a quick kill. And suddenly this quick-kill culture disappeared during college allegedly replaced by teachings of the "missionaries" from the West. And the word "buzzword" and "hype" started to find their way to our vocabularies. Of course, Quick-Kill is just one thing, yet again there's no mention on how mundane factors affect our GTD ratio. Some questions will help but shouldn't influence any policy-making decision.
1. How many hours a day your team spent answering all the emails? What email should be answered at the start of day and what should be answered at the end? Is it really necessary write email to the guy next to me?
2. How many hours a day your team surfs the Web for unrelated matters? You can't do a precise monitoring but a leader can motivate members to focus on the project.
3. How slow are the machines being used?
4. How the outsourced team are coping up?
How many hours a day should one focus on particular task to get it done? 3 hours? 4 hours? 8 hours? As one developer's experience grows, one core component of the project can be done in 4-6 hours giving a full focus on the assignment. Now if everyone can give full focus on the assignment, there are just too few reasons to stay late at night or work on weekends.
There are plenty of tools and frameworks out there some are helpful and some are not. But nobody really talks about "getting things done" or GTD. I don't agree that this should only fall under the project management's responsibility. When we sometimes play a lead role in development team we focus too much on standardization from code writing to internal processes. But how much of these really helps in bringing up our GTD ratio? What standards should we keep and let go?
And then there's Quick-Kill Project Management a very interesting article from Dr. Dobb's. I think the "Quick-Kill" is just a catch because the way the process goes, except for the code review, is the same as the process we had on how I made my first Vernier Caliper out of our school's machine shop during my Secondary School/High School days. And that's a quick kill. And suddenly this quick-kill culture disappeared during college allegedly replaced by teachings of the "missionaries" from the West. And the word "buzzword" and "hype" started to find their way to our vocabularies. Of course, Quick-Kill is just one thing, yet again there's no mention on how mundane factors affect our GTD ratio. Some questions will help but shouldn't influence any policy-making decision.
1. How many hours a day your team spent answering all the emails? What email should be answered at the start of day and what should be answered at the end? Is it really necessary write email to the guy next to me?
2. How many hours a day your team surfs the Web for unrelated matters? You can't do a precise monitoring but a leader can motivate members to focus on the project.
3. How slow are the machines being used?
4. How the outsourced team are coping up?
How many hours a day should one focus on particular task to get it done? 3 hours? 4 hours? 8 hours? As one developer's experience grows, one core component of the project can be done in 4-6 hours giving a full focus on the assignment. Now if everyone can give full focus on the assignment, there are just too few reasons to stay late at night or work on weekends.
Comments