David Allen's productivity system, GTD (standing for Getting Things Done), continues to be more and more popular. If you are all at interested in being more productive, than likely you've heard of this already. I follow it myself, using emacs and org-mode. Well, actually, when I say I follow it, I currently only follow part of it, because part of it is just not useful.
There are a few key concepts in GTD, but the most often applied are next actions, contexts, and weekly reviews. I think that next actions are an important concept. The general idea is that in your todo list you break down tasks to a level that each are simple and directly actionable with no planning or meta-level thinking required. One of these is your next action, which is the very next thing you have to do to move your project forward. This is a cool thing, because it forces your tasks to be of the correct granularity. Also, most GTD software will show you all your next actions, so that you can see what you have to work on. Once you complete one next action, the next todo item will become a next action. For example, if your project is to fix a bug, then the next action here is to attempt to reproduce the problem locally.
Actually, this concept is slightly simplistic. Sometimes your project can have several next actions. If your project is to launch a new feature, then you might have several next actions, one to write the introduction and high level overview of a design document, the other is to send out a mail to your manager asking who could possibly be allocated to work on this feature. A good GTD system should let you mark items as next actions arbitrarily. org-mode does this, which is one of the reasons I like it.
Another key concept of GTD is the weekly review, which means that you update your tasks and take time to plan new ones. Good advice. I have nothing to add to it.
Finally, GTD has the notion of contexts, which are the bread-and-butter of most GTD apps. Contexts represent some state in which your actions are performed. One obvious place for contexts is for direct communication with someone. You might have several projects that have an action that requires you to talk to your project manager. You can associate those tasks with a context, and now you have a context that you look at to before you go speak to the project manager, to see all the appropriate tasks. Then when you go talk with them, you have a list of things to ask them.
Sounds vaguely useful. And that's the problem. For software engineers and other types of knowledge workers, we just don't have a lot of context. We are pretty well connected. Usually things that can be done at work in front of our workstation can also be done at home, through VPN. I find that most of my actions are to be done in front of my workstation, so the vast majority of my tasks have the context of the workstation. What I find useful is to not use contexts for these tasks, since they all have a default obvious context. I use it only for person-related contexts (such as the context for my project manager in my example). And even then it's only somewhat useful. It's possible that I could start doing work on my subway ride, in which case that is a useful context. The problem would be that things done on the subway is a subset of things I can do at work. Here again the concept of rigid contexts doesn't work. So when I'm at my workstation, every task if fair game. If I'm somewhere specialized, a specific context may come in handy. But, ultimately, for most modern "knowledge-workers", contexts are not something we should be spending a lot of time thinking about.
With contexts, org-mode again comes in handy. It's not a real GTD app, so it doesn't insist on contexts. It just lets you tag items, and those tags are your contexts. So you can put things in multiple contexts, or none. The tags inherit. I think it's really perfect flexible solution for the modern GTD user. Next post I'll detail exactly how I use it and give some customizations.
No comments:
Post a Comment