My most valuable skill I can think of is in the context of being a software developer. I’ve learned to be pretty good at extracting requirements from customers. I often say this is one of the more important skills a software developer can learn. It’s important at all levels of the profession, and is really a gateway skill to performing at a high level.
The reason it’s important and hard to learn is that most of the time, customers don’t know what they want, or they have an idea in their head, but they’re wrong about what will satisfy. Extreme Programming (XP) teaches one approach that lets you get by with less of this skill, and that’s to build something simple that approaches what they say they want, and then keep adding stuff until they’re happy with it. But if the customer is really confused (which happens more often than you might think) then you’ll have started in the wrong direction, and the customer won’t get less confused about what they want.
So it helps to know how to talk to the customer and find out what the real problem is, rather than just what they think the solution might be. It’s also valuable to have good intuitions about features they’re likely to want that they haven’t asked for yet, so you can build in the hooks for those. But if you make too many guesses, you’ll waste time building general support where it’s not needed. So you have to calibrate your guesses as well.
I’m a programmer but have worked as a more general engineering/management consultant and attest that this skill is valuable for more than programming. “Extracting requirements” is pretty close to “looking at the problem and figuing out what interventions (tools, systems changes, training, outsourced services, etc) would fix it”, which is pretty obviously pretty generally useful.
My most valuable skill I can think of is in the context of being a software developer. I’ve learned to be pretty good at extracting requirements from customers. I often say this is one of the more important skills a software developer can learn. It’s important at all levels of the profession, and is really a gateway skill to performing at a high level.
The reason it’s important and hard to learn is that most of the time, customers don’t know what they want, or they have an idea in their head, but they’re wrong about what will satisfy. Extreme Programming (XP) teaches one approach that lets you get by with less of this skill, and that’s to build something simple that approaches what they say they want, and then keep adding stuff until they’re happy with it. But if the customer is really confused (which happens more often than you might think) then you’ll have started in the wrong direction, and the customer won’t get less confused about what they want.
So it helps to know how to talk to the customer and find out what the real problem is, rather than just what they think the solution might be. It’s also valuable to have good intuitions about features they’re likely to want that they haven’t asked for yet, so you can build in the hooks for those. But if you make too many guesses, you’ll waste time building general support where it’s not needed. So you have to calibrate your guesses as well.
Indeed. Programming is the art of figuring out what you want so precisely that even a machine can do it.
I’m a programmer but have worked as a more general engineering/management consultant and attest that this skill is valuable for more than programming. “Extracting requirements” is pretty close to “looking at the problem and figuing out what interventions (tools, systems changes, training, outsourced services, etc) would fix it”, which is pretty obviously pretty generally useful.