Having rapport with users, building their trust, means that the end users don t feel as if IT is shoving something down their throats, Dan Goldstein says. That matters, because if the users don t buy into something you re introducing, it is not going to work. They can make or break any system.
Dealing with an end user can be tricky. Even as an experienced programmer you will have end user encounters that will require all of your expertise and finesse to facilitate. To help you visualize some of the situations you might encounter, this chapter presents some tips from two IT veterans ”Jean Kopan and Dan Goldstein, both of whom have gained perspective on the problem not only as programmers but also as high-level IT managers.
Jean Kopan, vice-president of technical development at a software development and consulting company in suburban Philadelphia, has the following advice:
When a user comes to you with a request, you should not just transcribe that request into programming. The request may be counterproductive.
For instance, let s say someone in the order entry department says, ˜I don t really see why I have to key in this order classification code. I don t want to key it in anymore. Take it off the screen.
But everyone in the sales department is using that classification code to decide how well certain classes of orders are selling. So if you take out that code, there ll be a ripple effect. You cannot always just do what the user wants. To respond intelligently to his request, you need to understand the business of the company, what the other users are doing, and how this request may affect other parts of the company.
You may notice that Jean has just affirmed my oft-stated axiom that you cannot be a good programmer without having a thorough knowledge of the flow of your company or client s business. In the situation she described, you wouldn t be savvy enough to say no unless you understood the business.