Developers Benefit By Seeing What Customers See

Spyglass

SpyglassSoftware engineering, and development in particular, encourages tunnel vision. For the most part, engineers receive inputs (an understanding of something to build), do some design, write some code, do some testing, and generate outputs (a product or some piece of a product.) In many cases, the inputs come from someone else in the organization, usually from a product manager, or a bug report from QA. The outputs go to someone else in the organization, frequently QA or a release team. It’s easily possible for a developer to go for months or years without any exposure to actual end users. The downside is we actually build better software when we better understand the customer.

So how do we get better at our jobs and understand our users better?

Try On Someone Else’s Job for a While.

Spend a week sitting with someone in support answering the phones. Hearing the customers talk (OK, complain) will start to show you how they think and what they want from your product. Spend a day with a product manager on a customer visit, and you’ll start to understand how customers express their needs — and how the product manager translates them. Spend a day with a QA engineer seeing how easy or hard it is to test the product.

You might be relieved to go back to your desk and get to coding again when you’re done. You’ll also have a better understanding of how customer and user requirements match up with what you’re seeing — and that will help you produce software that’s more useful. And that’s a win for everyone.

Comments

No Responses to “Developers Benefit By Seeing What Customers See”

April 12, 2012 at 5:39 pm, RMS said:

Much of this assumes the organization has well defined AOR and there are no lines being crossed or blurred. More than once not only was I the programmer, but I was also QA working closely with the end users who were testing the product.

Only for a few years, out of more than 20, have I been in a postion of no interaction with users. In that particular position, with a company now part of McKesson Provider Technologies, I was in a strictly development group and was not even allowed to enter the computer room. In a previous programming position, with the same company, I did have contact with some clients and had access to the computer room. Because of comments and compliments received from supervisors during that first position I made certain future positions always required contact with end users.

I am one of few “IT guys” I know that actually had empathy for the end user and understood that my role was to provide and maintain the tools they used on a daily basis. If the others knew that they were hiding that most masterfully. Most of the others seemed to view users as some sort of necessary evil. The challenge/problem as I see it is the lack of folk inside and outside of IT that can, or even desire to, talk to folk on the other side. That’s what leads to products that don’t meet end user needs, but almost invariably are what IT believed was desired or should be produced.

Reply

Post a Comment

Your email address will not be published.