Well, today's feedreader binge brings the advice to "Zip It" -- that projects that success most are the ones that keep themselves secret. Apparently, the idea is that by purging the idea from your mind, it gives you enough satisfaction by sharing it, and this satisfaction fills the spot of actually accomplishing the task itself to the point that you don't actually do the thing you talk about.

Ok, then. Just to keep people in the loop, I'm following one of my personal principles: Move Forward Every Day. If I keep doing a little, I'll inevitably get somewhere.

In the vein of moving forward, here's Alice.

Alice Burns is basically... me. She's a seasoned developer for Skywater-Stone. She's used many different project and/or bug tracking systems. She knows her way around web applications because she builds them. She's willing to put up with a little inconvenience in the perfection of an application if it is generally useful, but on the whole, she'll complain a lot if something doesn't work the way it's supposed to.

Alice's primary task consists of writing code for various client projects. At any one point, Alice will be working on (on average) between one and four client projects. While working on these projects, she has a frequent need to return to functional specifications - documents that describe what she's supposed to be producing.

She also needs access to project files provided by either the client or designer. Sometimes these files aren't complete and need to be sent back for review. She usually has a direct line to both the client and designer, but sometimes works through an intermediary, either someone within her company, someone hired by the client (often the design firm who subcontracted the development work), or within the client's company itself (sometimes a print designer re-purposed to web design, or a "project manager" that doesn't themselves know development).

Day to day, Alice keeps track of client requests, converting them into actionable items and acting upon those she has time for. She may keep a spreadsheet of items to work on, which may also include assignment dates and estimates. She may keep a combined to-do list for all clients as next-actions. Whether each of these to-do items corresponds to a larger list depends on the project size and how well it is (and needs to be) documented. Speed of using any of these tools is key to her, since messing around with some interface other than her IDE is a waste of the time she has so little of to begin with.

Although there is often someone between the client and Alice, ultimately her goal is to satisfy the client's needs. Sometimes requests are forwarded directly from the client that are out of scope for the current project. Sometimes these requests come from intermediary project managers that don't understand the development process enough to know how their request is affected by scope. Alice must often make the determination of what is in scope and out, and be able to make the case to the client.

As is the nature of the business, Alice reports time spent on projects for billing purposes. It is useful for her to use the amount of time estimated to spend on current projects to predict how busy she is going to be, and when she will be able to schedule new large tasks and client work. Knowing what's coming on the horizon would be an asset for planning what might happen in a more distant schedule.

Although a lot of her work might happen on her own, Alice sometimes has the responsibility for leading a project team. In those cases, coordinating who should work on what part of the project is important. Keeping in touch with the whole team is usually done via email. Sometimes inefficiencies in email make it unclear who is supposed to be doing what, so she has to be extra clear.

Once again... Subject to review.