FV and FVP Forum > go backwards
Marks' method ensures you always consider older tasks before newer ones.
March 19, 2012 at 11:11 |
Ed
Ed
Jens, why? The ideal is "as simple as possible, but not simpler", so work becomes automatic and efficient. Any possible advantage to going backwards is easily overmatched by the increased complexity.
March 19, 2012 at 12:38 |
Alan Baljeu
Alan Baljeu
Jens,
By doing your preselection backwards, its likely you are never going to want to do the oldest item before doing the newer ones. That's why its the oldest item.
By doing your preselection backwards, its likely you are never going to want to do the oldest item before doing the newer ones. That's why its the oldest item.
March 19, 2012 at 12:44 |
MartyH
MartyH
Thanks for your feedback,
IMHO it isn't more complex if one will do the preselection backwards. You mark the first unfinished item as mark described and then jump to the end of the list and read backwards (instead of foward). I don't think this will increase complexity.
Ed, MartyH: The older items were also considered (especially the first unactioned). If one will read the list backwards instead of foward and read the entire list all items where considered - but, my assumption the more current one will be selected.
I don't say backward is better or worse - I only want to throw this in for discussion... Could be, that both make sense.
IMHO it isn't more complex if one will do the preselection backwards. You mark the first unfinished item as mark described and then jump to the end of the list and read backwards (instead of foward). I don't think this will increase complexity.
Ed, MartyH: The older items were also considered (especially the first unactioned). If one will read the list backwards instead of foward and read the entire list all items where considered - but, my assumption the more current one will be selected.
I don't say backward is better or worse - I only want to throw this in for discussion... Could be, that both make sense.
March 19, 2012 at 14:20 |
Jens
Jens
I meant, if you introduce this, you're now having to think "which direction should I go?". I haven't yet seen a reason to think there's a benefit for switching up like this.
March 19, 2012 at 14:58 |
Alan Baljeu
Alan Baljeu
Creating the chain backwards would put more emphasis on the newer tasks. One must always do the newest task (even if it's one you've just rewritten).
Also, you're more likely to want to do the lastest and loudest, so you'll not want to do the older tasks before the newer ones.
So, I'm not included to change the pre-selection sequence.
I'm more tempted to change the doing sequence. Get the oldest off the pile and reward myself with something a bit nicer. This is risky, though, because if I can't finish a chain, the oldest ones get all the attention, rather than the ones I want to do more -- which are often the urgent, critical ones.
Also, you're more likely to want to do the lastest and loudest, so you'll not want to do the older tasks before the newer ones.
So, I'm not included to change the pre-selection sequence.
I'm more tempted to change the doing sequence. Get the oldest off the pile and reward myself with something a bit nicer. This is risky, though, because if I can't finish a chain, the oldest ones get all the attention, rather than the ones I want to do more -- which are often the urgent, critical ones.
March 19, 2012 at 17:04 |
Cricket
Cricket
I'm wondering if it makes in some situations sense to generate the task-chain backwards.
a/ Mark the first unactioned item (as original)
b/ go to the end of the list and read backwards (ask the "want to do before x")
Proably the task-chain could be look quite different compared when working forward. I assume that more currently ongoing stuff will be dealt with?!
Mark: Had you tried processing the list this way?! (ok, it's a theoretical question ;-)