| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Browse archives
|
Untitled
Submitted by reeses on Mon, 2002-04-01 07:23.
I've been in death-march mode at work lately. We launch a client next weekend, so we're grinding out the last of the bugs. I've been amazed at how intrusive PMs get when they don't have anything productive to do. Really, they're heavily involved early in the project, but near the end, they really don't have much to do. It makes sense -- you could only succeed in the career path of PHBs by sheer force of will and personality. It doesn't have to be a personality other than "annoying and pushy", but you get the idea. A perfect example -- we have pretty clear guidelines on determining severity levels for bugs. Critical -- can't do anything, no workaround. High -- bad voodoo, but there's a workaround. Medium -- It's gross, but it doesn't impair functionality. Low -- someone used pantone color 45632 instead of 45631 in a deeply-nested help file. You get the idea. For items that do not have a functional impact, we have a priority system. So, if you have big dirty words on the front page, it doesn't affect functionality, but you'd better get it fixed before launch. Therefore, it would be a medium severity, but very high priority. Not tough to grasp once it's explained, eh? For every bug, you could think,"How does this affect functionality? OK, now, how important is the problem?" To avoid a huge sev/pri education, we're just using two priorities -- 'normal' and 'high'. Everything is 'normal' unless it requires immediate and special attention, with significance not indicated by the severity structure. For everything else, we prioritise solely on severity. Anyway, PMs seem to think these rules apply only to other people. This is a real conversation I had today. "I filed a bug on incorrect text on this page." This last line was delivered in that tone so familiar to those who deal with non-technical managers. The "eff you, you simpering idiot, you couldn't understand the priceless eggs I juggle in variable gravity, and you should just accept what I say as gospel"-type voice. The other phrases uttered in this tone are "I don't remember it that way," or "If you find that overwhelming, I guess I could move that task off your plate." You get the idea. Anyway, with nothing to do, they're doing QA. Normally, a QA person digs into a bug, describes it, files it, etc. Not a PM-QA. They come over and interrupt you every five minutes to see if you've fixed their bug, and don't understand why you're not making the progress they think you should. This is where I thank god for Grados. They make great open-ear headphones that fit over the ears. So, people think you can't hear them, so they don't interrupt you. But you can hear them unless you have your music turned up, so you can jump into any conversations you find interesting. These keep you from killing the PMs long enough to come home and rant into a blog. Post new comment |
SearchSimilar entriesUser login |