How to Change Behavior of Software Development Team
One of the hard missions I ever encounter is when I try to convince a software developer or a team that their end-result product is not easy to be used. At this point, you turn defensive mode ON and a list of prerecorded defenses are played.
Changing the behavior of a team is one of challenges that anyone working at software industry can encounter. Recently I got an idea of recording videos illustrating end-users while they are interacting with resulting product during testing sessions. Another idea is to accompany development team into site visit to customers.
While I was reading I stumbled below story happened within Microsoft. It demonstrates how such ideas would change behavior of software development team and how they can put end-user at steering.
At many software companies, the developers-who are responsible for writing new software programs-fall in love with their code. When their programs are tested by customers, they can be skeptical of the customer feed back. At Microsoft, for instance, one test of a new feature showed that six out of ten users couldn’t figure out how to use it. When the test lab shared the data with the developers, their reaction was, “Where’d you find six dumb people?”
Many companies experience a form of this problem. Is it possible to convince developers to be more responsive to customer feedback?
Ultimately, companies need developers to tweak their software in response to feedback from customers; otherwise, the programs won’t be successful. But sometimes developers resist or dismiss than trying to empathize with customers’ difficulties. Normally developers understand what’s being asked of them but resent being forced to change their beautiful code for the dummies in their audience. But let’s not be too quick to treat developers as a “type” (e.g., as arrogant technologists). Character judgments like that reflect a psychological bias. Let’s focus on providing developers with more motivation and a smoother path customer feedback and make only “token” revisions rather.
At Microsoft, the developers were invited to visit the usability testing lab. There, from behind a one-way mirror, they could watch real users struggling with their programs. It made all the difference. The test lab manager says that when developers see a user live, “Twenty ideas just immediately come to mind. First of all, you immediately empathize with the person. The usual nonsense answers-Well, they can just look in the manual if they don’t know how to use it: or ‘My idea is brilliant ; you just found six stupid people’ … that kind of stuff just goes out the door.
We should stress that the test of a great developer isn’t the quality of his or her first-draft code; it’s how well the developer codes around the inevitable roadblocks. We should make an effort to praise ingenious solutions to customers’ problems.
At conclusion, it is highly important that customer feedback comes at appropriate time during software development and not after deploying the product.