Martin Fowler at ThoughtWorks says:
When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I’ll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.
Bingo! The critical thing to realise is that software development is less about the software and more about the customer and his/her business. No amount of technical expertise will make the software work if the workings of the underlying business are not understood. Customer Affinity is about working close with the customer to understand the problem. And this creates the need for agility in the software development.
Business is a multi-dimensional entity, which is affected by multiple factors. It becomes imperative to discuss with the customer first hand to comprehend something like this and then automate it. Requirements gathering is not as much about interviews as it is about discussions. Interview is inherently a question-answer session, whereas a business, and hence software development is a field where you can have multiple answers to a question from different perspectives. Selecting the best one is an effort to talk to all the stakeholders involved, bring them on a common ground and then discuss with them. Like Martin mentions, most of the times the developer learns about the business by collaborating with the domain experts. In some cases a software developer ends up contributing a feature to the solution. An example of this is during a project of article management, the feature of related articles was something that came from us, the software developers.
The popular reason I have seen for this to not happen is that the software developer is too scared to talk non-technology with the customer, and the customer to talk technology. The ideal thing would be if both of them discuss the solution. Isn’t it the solution that we are really looking for? Discuss the solution, and let the expert handle the details of corresponding domains.
The developer should also be able to rationalise the requirements and then justify the design against them. At the end of the day, the software developer should be able to solve the problems with the designed software. I have seen lot of designs fail when they cannot assign purpose to the design. The best way to do this is a direct customer developer interaction at various levels and at multiple times during the software development project.
It is equally important that the customers realise that a customer cannot just wash off hands from the project after providing information. The customers should identify their problems, but also keep an open mind in the discussios and expect contribution from the other side of the table.
Technorati tags: customer, software developer
Copyright Abhijit Nadgouda.
