Agreed on consultants. It provided so much enlightenment on the multitudinous ways many companies can screw up the discovery and development process.
Setting aside the "This company was fundamentally disfunctional" cases, my takeaway has been that knowledge gaps between roles are an underappreciated cause of bad development outcomes.
Writing requirements is hard. Writing requirements without some intuition of what developers need to know is harder. Writing requirements without context on the business domain is harder.
So the ideal BA is someone who is a developer who is also experienced in the business domain.
The majority of companies don't want to pay enough to hire BAs with that experience.
So you get users (who may know nothing about software) + minimum cost BA (who is doing their best, but has no context for anything) coming up with requirements, which are of course incomplete and/or incorrect.
But fundamentally this problem is too large of a skill/knowledge gap between the user and BA, and between the BA and the developer.
Setting aside the "This company was fundamentally disfunctional" cases, my takeaway has been that knowledge gaps between roles are an underappreciated cause of bad development outcomes.
Writing requirements is hard. Writing requirements without some intuition of what developers need to know is harder. Writing requirements without context on the business domain is harder.
So the ideal BA is someone who is a developer who is also experienced in the business domain.
The majority of companies don't want to pay enough to hire BAs with that experience.
So you get users (who may know nothing about software) + minimum cost BA (who is doing their best, but has no context for anything) coming up with requirements, which are of course incomplete and/or incorrect.
But fundamentally this problem is too large of a skill/knowledge gap between the user and BA, and between the BA and the developer.