PM quotes

Mar. 26th, 2009 10:37 am
jenk: Faye (GeekGirl)
So I'm reading a book on project management by Scott Berkun.

"All successful projects are simply a long series of adversities that must be overcome. Far from it being unusal to face adversity, it is normal, and our business it to overcome it."
William A. Cohen

Scott then has a rough guide of how to address problems:

  1. Calm down. "Nothing makes a situation worse than basing your actions on fear, anger, or frustration ... Rule of thumb: the less aware you are of your feelings, the more vulnerable you are to them influencing you."
  2. Evaluate the problem in relation to the project (how bad is it really?)
  3. Calm down again. ("Now that you know something about the problem, you might really get upset")
  4. Get the right people in the room.
  5. Explore alternatives.
  6. Make the simplest plan.
  7. Execute - make it happen.
  8. Debrief - what are the lessons learned?
This is directed at software project managers, but it can be used by anyone who's working to solve problems. ;)
jenk: Faye (ItsACompany)
  • 11:48 Interesting read on how some corporate cultures thrive on fear - tinyurl.com/6p5cam
  • 19:43 At crossroads waiting for iron man to start. :)
  • 19:47 Remember when there were just ads for movies before the movies not cars?

Automatically copied from http://www.twitter.com/jenk3 via LoudTwitter cause it's easy :)
jenk: Faye (Testers)
...is that often the metrics aren't what you really wanted. In tech support, "shorter calls" were a big metric. Shorter calls meant more customers were served and problems were solved more efficiently, right? Right?

Some calls, yes. Perhaps even the 50% or 80% most common calls. But not the less common calls. Not the troublesome calls. Those took longer, and one 1/2 hour call would screw up your stats for the day.

"Of course you should take the time to do the job right, just not more time than necessary," management would chirp. And yet the rewards went to those who did the job quickly - and not necessarily well. Since people repeat the behavior that gets rewards, this led to less service.

In testing, focusing on bug counts can be a similar problem1. My first test lead didn't look at how many bugs were reported by each individual on his team. Instead, he read every bug reported by his team. He found it was very clear who was breaking bugs into tiny little bits so's to inflate bug counts (often a habit acquired elsewhere), who was sloppy in figuring out repros, who was noticing that two different symptoms had a common cause and reporting it as such, who was mostly finding bugs in areas other than their own (which if a conversation determined their area just didn't have many bugs to find could be a good thing) and so on.

Of course, it was expected that a test lead would read and know all the bugs for the areas covered by his team. And my first test lead did so. Among other things, this made him aware of what was being reported by those not assigned to test the area. (Often these were bugs on areas that weren't officially released for testing yet and such. But sometimes it was a clue that tests needed revising.)

Sometimes the focus on bug count goes beyond using it as a measure of tester productivity. The Defect Black Market relates just one example. This Dilbert shows a slightly less, er, subtle approach.

1The problems with using bug counts as a measure of tester productivity are discussed in-depth in Testing Computer Software by Kaner et al.

Profile

jenk: Faye (Default)
jenk

June 2025

S M T W T F S
1234567
891011 121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 19th, 2025 02:33 pm
Powered by Dreamwidth Studios