Software developers are a clever lot, and prone to bouts of creativity every once in a while. It turns out these are essential traits when building software, but cleverness also needs to be must be tempered when it impacts the user-facing parts of your software.
(Bugzilla's "no results found" message -- please don't do this)
Case in point: Bugzilla's search results page. This is what happens when you try searching for something in Bugzilla and it doesn't find any results. It's supposed to be funny -- the misspelling is, in fact, intentional.
But it's not funny. It's really, really not funny. It's not funny for two very specific and very important reasons.
Reason 1: Usage context. If any Bugzilla user ever sees this message, it's because he failed at the task he was trying to accomplish. Since the message exists solely to explain to the user that he failed, it's pretty reasonable to assume that the user might not be in the best of moods already. I know I wasn't.
Reason 2: Product context. If you've not already had the pleasure of using Bugzilla, let me fill you in on its search capabilities: they suck. Like, searching in Bugzilla is not only unpleasant, it's also unfruitful way too often. It's the best reminder you're likely to see about why Google won the search wars -- it's because everything else used to work like Bugzilla. So when your (otherwise excellent) product has a critical flaw, such as searching in Bugzilla, it might be best to not choose that specific part of your product to try to crack a funny. Just sayin'.
The lesson in all this? Somewhere on any product team, there needs to be a voice of reason who's looking at context stuff like this and deciding when it's time to be funny, and when it's not.
Years ago, I introduced a bug tracking system at a software company, and the most lasting lesson I learned from that process has nothing to do with software. You see, even though it took a while to accomplish this, I eventually trained our company to use this system to finally be able to answer the highest and greatest question of any operationally-oriented workgroup:
What the hell is going on?
It astounds me on a pretty regular basis how utterly lost people (and organizations) are with respect to this simple question, and I think it ultimately stems from people trying to relate to one another like people, rather than as parts of an organization. While this is completely understandable -- even virtuous -- the uncertainty and passivity of polite society are inefficient and confusing. Ironically, the more polite everyone tries to be, the more tension builds as problems fester and grow.
(Photo credit: lambertpix)
Like ripping off a band-aid, though, I've found that setting a few simple rules, and then sticking to them rigorously, so thoroughly squelches the confusion about "who's doing what" that the pain of working the system quickly gives way to the relief of actually knowing what the hell really is going on.
Before jumping into the rules, understand that this approach applies most directly to tasks in the context of an organization. If you're unsure of the difference, here's a clue: if you're talking about something the organization would expect to get done even if the person who normally does it is sick or on vacation, then it's an organizational task. If it's going to wait for you no matter how long you're out of the office, then you don't really need to bother with this at all -- just work your own to-do list.
So, without further ado, the rules:
Have a list. Use a whiteboard or a spreadsheet or scrabble tiles, but whatever you use, treat it as the one and only definitive source of truth and enlightenment for your organization (with respect to the subject of the list, of course). Given that tools like Bugzilla are available for free, scrabble tiles would really be sort of silly, but the important part is that the list is kept sacred. Better yet, tools that are built for this sort of thing will help enforce the rest of these rules.
The list belongs to the organization, but assignments belong to people. You're trying to map the somewhat nebulous idea of organizational responsibility to actions of individual people, so this part is important.
Assignments belong to one and only one person. When I talk about people being responsible for things, I'm talking about one person (I've covered this before, incidentally).
Someone needs to be responsible for the list. I'm not talking about items on the list -- I'm talking about the integrity and life-force of the list itself. This is a full-time job, and it must be staffed all the time, so be ready to pass this baton when your list-owner is sick, on vacation, or out of the office. Your organization will eventually self-train to keep the list alive, but this takes serious time and dedication (think years, not months or days).
Issues belong to a single person. Again, with the one and only one person. It's important.
Issues can change owners. They should, in fact, or you're probably not talking about an organizational issue. Most of the time, issues are created precisely because the person who finds the issue isn't the person who needs to do something about it.
If it ain't in the list, it never happened. Watch out for stuff happening "off the books". I can't tell you how many times I experienced people sending an email about an issue because they didn't want to take the extra thirty seconds necessary to add something to the bug tracking system, but in return for saving those few seconds, your organization will give up all the management oversight and quality control your list gives you. I personally saw the single worst "off-list" violator in my organization turn in to the biggest "list enforcer" over the course of a couple years because the list works.
Ok, I lied. Scrabble tiles suck. In most cases, you really want a place to show history, emails, attachments, and so on, because most issues complicated enough to need a system gather little artifacts like this as they're worked, and if it ain't in the list, it never happened. One of the points of tracking stuff in the list instead of email is that as these issues pass from one person to the next, the list holds the whole thread and context of the issue – very unlike email, where information goes to die.
A quiet list is a dead list. If you don't see activity in the list, it sure as hell doesn't mean there aren't any issues. It means nobody's using the list. The list owner should have a good enough sense for the "pulse" of issues to know if this ever happens, by the way.
A quiet issue is a dead issue. Sounds familiar, no? If there's no action on an issue, somebody needs to know why. If nobody cares about it all that much, make sure it gets shunted to a side track of some sort, but if it's an issue that needs to be dealt with, find out why it's stalled and address the problem. This is "project manager 101" stuff, but it's really easy to miss unless you've got a living list, and really hard to miss if you're really working a list.
There's more you can do with issue tracking once you get this far, but I promise if you embrace the rules here in a meaningful way, your entire organization will take a step up in efficiency and effectiveness, and best of all, you'll eliminate a whole lot of the latent tension that comes from trying to manage implicit lists.
