Up to 50% of development time in a traditional software project is taken up by gathering requirements. It’s a losing battle from the start. When teams are focused on gathering requirements, they’re taking their least seasoned people—business analysts who don’t have a technical orientation in terms of coding—and sending them in to talk to customers. Invariably they end up parroting what the customer says.
We all have a tendency to tell people what we think they want to hear, and some customer-facing professionals still fall into this trap. It’s uncomfortable to try to find a way to tell your customer, “No, you don’t want that, you want this,” or “Let’s not worry about how it works and instead trust our developers to get us there.”
It’s easier to list the features requested by the customer and tell them exactly what we think they want to hear: “Got it. We can do that.” But can we?
More importantly, should we?
It’s natural in spoken language to talk in terms of implementation. That’s how people tend to speak, and it’s hard to identify when we’re doing that. I go from my specific understanding to a generalization. You hear that generalization and go back to your specific understanding. And in the end we have two different experiential understandings of what we think is common ground, but they’re probably completely different.
Requirements have no form of validation and that’s translated from the customer telling the analyst, the analyst writing it down, the developer reading it and translating it into code….It’s the telephone game. There are all these different ways of reinterpreting stuff so when you finally give the released version to the customer they’re apt to say, “That’s not what I said. That’s not what I wanted.”