Friday, July 30, 2010

Adventures in Scheduling: two weeks


Two weeks ago I posted about my new attempt to actually make a work schedule of some form, instead of figuring out my work tasks each hour as issue erupt. I've been doing it for eleven work days, and this is an update on what I have learned.

It's hard to trust the schedule, but I must. The challenge is that with ten or so ongoing projects, it's always hard to believe that task number 6 is truly important enough to be working on it right now. The other nine tasks call to me from my conscience. But the point of making a schedule is to intentionally and consciously ensure fairness among the tasks: I.e. Every project will get some time, and critical projects will get the extra time they need.

People schedule meetings without asking me when I can meet with them. This one has been hard ti take. Often that scheduled meeting punches a big hole in my focus on another in-depth development project. It's really tough to work for one hour on software then do a 30 minute call, then another 90 minutes back on software.

Rescheduling for the future is key. In these two weeks I have had two instances of planning work, but being stymied by the customer's network. In those cases I have had to just drop the project until a future date. My desire would be to push everything around for the sake of this customer, but that approach has failed me many times before.

gahk! Don't forget to add meetings to my calendar. I goofed up and ended up working a lot last Saturday because I forgot the time of a meeting, and I had a day of planning to do before that meeting.

Switching between software projects is painful. Three of my projects are software development. I'm mostly doing two of them: A and B. I'll work for 3-4 hours on A on one day, then 3-4 hours on B the next day. This switching does ensure some fairness, but it's been very tough to get into the work each day. Also, 3-4 hours isn't enough time to even finish some smallish changes, so I'm sometimes forced to comment out big blocks of unfinished code to get the thing to compile. (All my projects share some common library code that is under development.)

All in all, it has helped make more fun, but the scheduling still needs sime work. I need some ways to deal with being drafted into meetings at times that prevent work on other projects, in particular.

1 comment:

Joshua Papandrea said...

In regard to being drafted into meetings that you have not planned for, I can completely relate! :)