Thursday, May 29, 2008

On Reporting, Part II

I've written about reporting before, but that kind of daily report is a relatively structured thing. The triggers for sending them are fairly well defined, and there's generally an event after which daily reports stop (in our case, we start when QA takes code for release, and we stop when QA releases the build to support/deployment).

Sometimes there is a need for ad hoc reporting, too. These types of reports are when you have an issue that crosses teams and that matters to numerous people. Think client issues, think service packs, think office moves, etc.

It's really tempting to make an ad hoc report be a verbal thing, just something that "everyone working on the issue knows". Don't give in to this. No matter what's is causing you to need a form of ad hoc reporting, if it's going to last longer than a day or two, set up some sort of reporting expectation.

The report doesn't need to be a major time-consuming thing. It can be a wiki page, or a bug, or an email thread; the format really doesn't matter. It just needs to be something quick that can be updated by anyone working on the issue. There are only three required elements to the report:
  • What we know. Include things we've learned and things we've tried (and their results).
  • What we'd like to know. Include things we think are the stressors or the unknowns here.
  • What we're trying next.  Include a very brief sketch of what we are going to try in what order.
Without ad hoc reporting you'll spend more time explaining what you know and talking about next steps than actually working on the issue. So it seems silly, but take the 5 minutes and just get it started. Three days later you'll be thanking yourself.

No comments:

Post a Comment