Thursday, April 23, 2009

What's the Least?

I don't remember the last time I was talking to an engineer who had too much time, or too many resources, or not enough to do. We're all resource constrained! (well, at least in my sample set)

So we're all trying to cram more in.

There are two ways to look at this:

  • What's the most I can do with the resources I have?
  • What's the least  I need to accomplish X?

When I'm asked to do something, I realize that I'm looking at one of these two questions. Either my resources - people, time, machines - are static and what I can get done is variable. Or what I can get done is static and my resources are variable.

It's important to figure out which question I'm facing. If I'm being asked what I can do with my resources, then there's no point in trying to change the resources; it's time to take a hard look at what I can actually accomplish with them. If I'm being asked to do something, well, better to say what I need than to fail and not do it. Sometimes, though, it's tricky to figure out which question I'm really facing.

A sample:

Question: We need to improve our CIFS testing.
Which is it?: Resources are probably not variable here (unless you have an open req or some budget). You're probably looking at a question about what we can accomplish in this area without altering our schedule.

Question: Our client is going to walk unless performance is 30% better by the end of the month.
Which is it?: Your goal is set (and probably relatively clear!). Now is the time to ask for the resources you need. In a crisis like this, resources can be made available. Use them. And then keep the client. Even better, exceed your client's expectations - they'll probably be happier than if there had never been a problem (but that's a topic for another time).

Question: When can we ship X?
Which is it?: Trick question. If X is defined, then your resources - particularly time - are variable. X may not be defined, though. For this one, you can (and should) play both sides; try to get the resources you need and push at what exactly needs to be done.

The reality is, most questions are about balancing. There will be some variability in resources (usually time, sometimes money), and some looseness in the definition of what the thing under discussion really is. There are very few things about testing that are inviolate. Stick to your principles, and beyond that, be prepared to balance each situation as it comes up.

No comments:

Post a Comment