So, lets take a minute to look at the requirements example because this one is probably the most common problem. Now, I tend to think that business analysis is part of a developer's everyday job, so the role itself is important; but why do we use a business analyst?
- Do they have better domain knowledge? Often not, they are usually skilled in business analysis, so like a developer, their knowledge of the domain is secondary. Additionally, developers tend to ask many more questions than their BA counterparts.
- Are they better communicators? I don't think there is any difference (in my experience)
- Do they save developers time? Well undoubtedly if the developer starts work without talking to the customer at all - but is this what we want. This, I think is a serious problem and leads to the developer missing a key opportunity to pick up on the domain, the more they can talk directly to the customer the better, having a proxy in between is just a recipe for miscommunication and misunderstanding.
- Don't they get it right first time? No, unfortunately not. Johanna's post describes this much better than me. Often subconsciously, customers use empirical feedback to steer their requirements along the journey. Expecting them to sign their name in blood on a requirements document and it will never change has long since been dismissed as naive at best.
So, why do I seem to be committed to the development perspective and not feel for the poor BA? Quite simply its a matter of responsibility. A business analyst has to deliver a paper document, proving how good or otherwise that is proves to be quite subjective. A developer on the other hand takes responsibility for delivering working code. Did you ever hear of a BA getting in trouble for not delivering a document on time? Do documents fail testing or cause null pointer exceptions during use? Many customers read requirements documents and think to themselves 'I have no idea what this all means - but I am confident everything will come out exactly as I expect it to.'.
Even if you work with a BA, cutting out the silo and having the BA work with the development team - and the team all working with the customer, (all other things being equal) should result in a better product.