[sf-perl] Bug management / time management
Tom Limoncelli
tal at whatexit.org
Tue May 8 09:13:40 PDT 2007
I'm not on the mailing list, so this post may get rejected. Therefore I'm
CCing Vicki and Andy directly.
What you need is a way to say "no" and "not now".
One way to do that is to set priorities. Let users set the priority of
their requests but once a day a manager should review all new items and
change any priorities they disagree with. Sometimes this is done by a
committee with representatives from all areas. They are called a MRRB (MR
review board, or Bug Review Board). They meet once a week. Requests are
left at the default or user-set priority until the meeting happens, at which
time the priorities might be reset.
Another thing you can do is make sure you have 3 policies in writing:
1. what constitutes an emergency? (definitions of what is a priority 1, 2,
3, 4, etc.)
2. how do people report problems? (submit a bug request.... don't bother
my damn employees)
3. what is the scope of what the team works on? (i.e. we do fix bugs in
these 3 areas... we don't fix bugs with other people's systems, etc.)
#3 is most likely not a problem.
When I say "in writing" I mean that they are documented and management above
you goes to bat to enforce those policies. If a priority 1 bug is "only
emergencies... and an emergency is defined as something that will DIRECTLY
prevent tomorrows newspaper from getting out on time" (if you work at a
newspaper) then management has to be willing to support you when you change
a pri-1 to a pri-2.
As Andy alluded to, I make these points in Time Management for System
Administrators. (www.everythingsysadmin.com). It's also in a chapter called
"Crawl Out of the Hole" in the next edition of my other book, due out in
June.
Good luck!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20070508/88a3337a/attachment-0001.html
More information about the SanFrancisco-pm
mailing list