| I agree it's a bit like playing in the mud, but the more I work the more I suspect that's just accepting reality. Requirements gathering works wonderfully for internal projects with a fixed set of stakeholders and a well defined problem with measurable outcomes. Product development is a whole different world whose outcome is the much more vague "generate profit for the developers". Particularly in the realm of B2B software. You need to find some local minimum that will meet the needs of thousands of organizations in order for development to be worthwhile. You need to get many busy people who don't know you to actually talk to you. You need to talk to multiple different stakeholders within the organization. And even after you group all your stakeholders into some kind of user personas, you still haven't accounted for what the larger organizational behavior will be, as B2B products generally require large-scale buy-in. And at the end of the day, no matter what people say they will do, the true test is when a company actually opens their coffers and pays your invoice. We've arrived down here in the mud through years of experience of doing requirements gathering, building to a spec, and then finding out that we built the wrong thing and nobody will pay us for all our hard work. Sometimes you really do have to build it to see if they will come. And the more formalized (ie expensive) you make the requirements engineering process, the more compelling the iterate and start getting paying customers asap plan becomes. |