For the programmers out there
Julie
I'm new to GTD, and I'm in the process of getting all my stuff
organized. I'm a little stuck on how to break things down though, so
I thought I'd see how you all do it. The problem is that I have
multiple web sites that I'm currently developing, each with a long
list of features to add. And I'm wondering what the projects/next
actions should be. Should each feature be a project with the next
action be "Code feature foo" or should each web site be its own
project with each new feature being a next action. What if it's just
a list of features with no particular priority to which one should be
implemented next? Does anyone have any examples or suggestions they
can offer me?
Thanks,
Julie
John Mayson
>
> Hey All,
>
> I'm new to GTD, and I'm in the process of getting all my stuff
> organized. I'm a little stuck on how to break things down though, so
> I thought I'd see how you all do it. The problem is that I have
One mistake I made was when I adopted GTD I changed everything at once
and it was a near disaster. I suggest taking it one step at a time.
For instance start with your "43 folders" in a filing cabinet. Next
organize the rest of your files in your filing cabinet. Next tackle
your email. Perhaps you do it in a different order and I have a
feeling David Allen would disagree with me, but the only way I was
able to implement it was basically a chapter at a time.
> multiple web sites that I'm currently developing, each with a long
> list of features to add. And I'm wondering what the projects/next
> actions should be. Should each feature be a project with the next
> action be "Code feature foo" or should each web site be its own
> project with each new feature being a next action. What if it's just
> a list of features with no particular priority to which one should be
> implemented next? Does anyone have any examples or suggestions they
> can offer me?
Projects are collections of actions. You can "do" projects, you can
only "do" actions. I haven't done software development in some time,
but I would imagine each new feature would be a separate project. If
order did in fact matter to you then I would organize by priority.
John
--
John Mayson <jo...@mayson.us>
Austin, Texas, USA
J-Mac
What you define as an action really depends on how you work best.
Remember, David Allen developed this "system" for people to use as a
GUIDE! I have come across a lot of folks who insist on trying to
adhere exactly to what is in the "GTD Bible", and woe to all who vary
from it. Don't get hung up too much on all that. There is a happy
medium that you can work best at; don't try to force yourself into
anything that doesn't seem comfortable to you.
As a general guide to Actions, break your project down into pieces
that you can start and complete within a day at the very most,
preferably something less. That way you can check off items and see
progress. Don't get too lost in minute details, though. E.g., if you
perform certain tasks almost in your sleep, then you don't need to
track those too tightly.
Keep it at a level where it feels comfortable to you. You'll know
soon if you are micro-managing your tasks in too much detail!
Likewise, if you are biting off too big of bites, you will know that
quickly also.
Good luck!
Jim
Hayashi Hideaki
Tom Shannon
> Should each feature be a project with the next
> action be "Code feature foo" or should each web site be its own
> project with each new feature being a next action.
This really depends upon how you work. If its one site at a time then
I'd advise that each site be a project. If its one feature at a time
then I would do the opposite.
Personally I work one program at a time but there's very little
overlap in terms of features in my case.
> What if it's just
> a list of features with no particular priority to which one should be
> implemented next?
Yeah, that's a problem. Its really isn't a question of priority but
the order in which things need to get done. But when there's no order
either, then it really becomes almost arbitrary.
I would make a list of features that you want to work on in the near
future and leave the rest in a list in the project file for later.
Its just a question of keeping your list down to a manageable length.
Otherwise it becomes a long hodge podge. Many people prefer to keep
only on item from each project on the task list. You just have to
pick it and start on ti.
Tom S.
He can compress the most words into the smallest ideas of any man I ever met.
- Abraham Lincoln
Julie
using rememberthemilk.com I have it so each feature is a project, and
the ones that I won't get to soon are on a "On Hold" list. For the
active ones, the next action is just Begin coding. It just seemed off
to me having so many projects with the next action exactly the same,
but I guess that's just the nature of my work.
Evan Edwards
On Friday 29 August 2008, Tom Shannon wrote:
> This really depends upon how you work. If its one site at a time then
> I'd advise that each site be a project. If its one feature at a time
> then I would do the opposite.
As an example, I have a 3x5 card for each feature (a project), and a list
of individual actions underneath. The feature goes into the changelog, the
actions don't. I have several cards filed for "Someday" without actions
under them. When I do implement one, I pull it during review, sit and think
what actual changes need to be made and list them as actions under the
project/feature title. I use the cards in "portrait" layout, 3" across, 5"
down. All projects are @Work, which means "at my computer in work mode",
versus @Desk, which means "at my computer during non-work hours".
But that's just one example of many different ways to do the same thing.
--
Evan "JabberWokky" Edwards
http://www.cheshirehall.org/
615.686.9538
Jim Barrows
Not really. The task should be what you want to accomplish. Begin Coding is not what you want to accomplish. What you want to accomplish might be "Develop template for site". Doing it your way... I write one line of code and I've accomplished your task. Done my way.. it's a real task.
In addition if you ever have to go to court, you can more easily show what was accomplished on what day. If you're using a source code control system, then it's also easier to ask "Why did I commit that again?"
Always be more specific not less.
--
James A Barrows
Evan Edwards
> In addition if you ever have to go to court, you can more easily show what
> was accomplished on what day. If you're using a source code control
> system, then it's also easier to ask "Why did I commit that again?"
It's also much easier to document and test using concrete items. The
various development methods (which I'm not getting into on 43f!) match up
pretty nicely.
Jim Barrows
It's also much easier to document and test using concrete items. The
On Friday 29 August 2008, Jim Barrows wrote:
> In addition if you ever have to go to court, you can more easily show what
> was accomplished on what day. If you're using a source code control
> system, then it's also easier to ask "Why did I commit that again?"
various development methods (which I'm not getting into on 43f!) match up
pretty nicely.
They all (development methods) do varying degrees of Requirements, Analysis, Design Implement and Test Over and OVER with varying levels of documentation and emphasis on various parts of those 4 steps.
The bottom line on documentation is to do enough to accomplish 3 goals:
1) Remind yourself of what your did, and WHY!! (WHY is important)
2) Tell someone else what you did, and WHY!!!!
3) Let the Court know that you exactly, and faithfully did everything the customer wanted, as they articulated in the requirements. Because you got them to sign off on the requirements didn't you?
Why is why important? Because different things affect the choices we make. I can't count how many times I went "Why did I do that, that was stupid, I should have done X." A note telling me that I did the stupidity because the client wouldn't pay for X, and there were no free alternatives to X at the time. If X has a free version suddenly become available, or the customer has a different l0ser.. I mean liaison, then maybe they'll spring for it.. etc etc. Always remember why you did something.
--
Evan "JabberWokky" Edwards
http://www.cheshirehall.org/
615.686.9538
--
James A Barrows
Evan Edwards
> Always remember why you did something.
Which is why the junction of project and action is nice. Actions are "how"
you did it (which is recorded at the VCS check in level). Projects
are "what" you did... and a "why" should be easily attached to that.
Mike Brown
It just seemed off
to me having so many projects with the next action exactly the same,
but I guess that's just the nature of my work.
Probably a gross oversimplification of your problem, but since you mentioned that different projects all had basically the same next action, this solution is what sprang to mind.
Jim Barrows
I wonder if, based on this sentence, it might be that most of your projects could be managed by a generic checklist of things that have to be done for every site. Tracking the project could be as simple (simple!) as creating a job sheet listing all the standard tasks that need to be done for each site project. Mark the date you do each one. Keep the job sheet in the relevant project folder and refer to it as needed.It just seemed off
to me having so many projects with the next action exactly the same,
but I guess that's just the nature of my work.
Probably a mixture of both "standard" things that must be done. "Incorporate shopping Cart". "Develop Site Template" could both be stock items to be done in a standard project, and then you flesh that out with specific things for specific customers.
Common where possible, and custom where it counts type mantra.
Probably a gross oversimplification of your problem, but since you mentioned that different projects all had basically the same next action, this solution is what sprang to mind.
--
James A Barrows
toen
I think each website should be a project, and most of them will only
use one context @computer :), so don't worry too much about that.
I really separate my work GTD & personal GTD, I found that simpler to
manage.
One thing that helps me for such project is sub-tasks, which is in
same application like remember-the-milk, cannot really accommodate
this. Using tag to capture list of feature will end up with quite a
mess list, even if you apply certain naming convention - not simple,
not an intuitive way of work. A freeware like DevProject Manager or
ToDoList might help you. Check in http://www.portablefreeware.com.
If a website is a project, your first level task are probably the
features, then you break them down to more action-able task, such as
define process flow, get image A, create function A, create function
B, create table A, create table B etc. This sub-task should not too
broad but could give you idea what exactly you have to do, and a
feeling of accomplishment when you mark that done :), probably a tasks
that you can accomplish in couples hours maximum. Create more sub-
task if necessary but don't playing with it too much (GTD common
pitfall), your action is more important!
I was using MS Onenote before, I can use checked-box as bullet point,
so I just have to use indentation to create sub task. I can also put
there some useful notes, common code, useful links and draft for
documentation as well in there, which I found that handy & easy to
use.