透明思考

(From The Build Master )

For most of my career, I’ve been a test manager. I’ve come to realize that the job of a test manager is really quite simple and consists of three activities:

1. Say “no” to development at least once a day.
2. On a regular basis, complain that the project is off track, the schedule is ludicrous, and the quality is terrible only to be told to “lighten up” by the program manager.
3. Find the killer metric to measure the product.

What I’ve learned that I’d like to pass along (the condensed version):

1. If [people] really want you to do something, they’ll ask at least twice. The first time they ask is just to see if what they’re asking for sounds good to them. If you do what they ask when they’ve only asked once, you’re not playing the game right.
2. The bug resolution fixed is more a wish than a statement of fact.
3. You can still be friends with your developer even after threatening him/ her with a baseball bat.
4. A schedule is not a sausage casing designed to be stuffed to the breaking point.
5. 95 percent of reorgs have no impact on the people actually doing the work. The other 5 percent of reorgs mean you’ll be looking for a new job. The trick is to know which one is about to happen.
6. It’s fun to have one’s mistakes made into a Dilbert cartoon.
7. If no one else knows how to do what you do, leaving your group is going to be tough.
8. A spec is like a fairy tale. Only the naïve and childlike believe it.
9. The first time a question is asked, it’s fine to say, “I don’t know.” When the same question is asked again a week later, you’d better have an answer.
10. Metrics are dangerous. No matter how carefully you caveat them in the original mail, they are interpreted to mean something completely different.