What do you really know about how your programs are being used? Sure, you wrote the application to spec. Yes, you included those (possibly foolish) features the users insisted on. So you know how your application is working in the field, right? Maybe not. The only way to truly know how your program is working—and how it is being used—is to get out of your office or cubicle and get in the trenches with your users.
Now you might be saying, “That’s going too far. A programmer’s time is too valuable for that sort of nonsense.” Or perhaps you simply feel it’s not necessary to get out in the field in order to write better programs. I disagree. I think the only way to know what’s going on with your applications, and to profit from the knowledge, is to leave the safety of the IT department and walk a mile in the user’s shoes.
Of course, I’m not the first person to say that programmers and other IT people should understand the businesses they support. Cross-training and interdepartmental teams have been promoted for some time now. Certainly, outside departments would benefit from knowing what we, in the IT department, do and how we do it. Likewise, all members of a development team can benefit from an understanding of what the rest of the business does. Yet despite this philosophy, it seems that far too few developers actually get to see their programs in action.
What I found
When I worked as a trainer in an MIS department, I was responsible for running a nine-week orientation program for college recruits. One of the things I designed into the program was time for the new programmers to sit beside an inside sales rep, the computer operators, and a help desk person. This was a one-on-one experience. One sales rep would be working, and one programmer would be watching and asking questions. In operations, the programmers mounted tapes. At the help desk, they got to see first-hand the kinds of questions end users asked about the programs they would be developing and maintaining.
I believe that this experience gave the developers a view of the world outside their department that could never be delivered from written documentation or a committee meeting. These people were not analysts or designers, but their programs still improved in a variety of little ways—and isn’t it the little things that make such a big difference in a finished application?
Two other things happened as a result of this program. First, experienced developers, I mean the people who have been with the company for three to six years, were envious. Some wished they had the time to do what these relative beginners did. Others wanted to know why these people got all of the special treatment. No one, however, thought the experiential training was a bad idea.
Second, the groups we imposed on (sales, operations, and help desk) had something to say as well. Typically in the past, people outside the development area felt that MIS was slow, clueless, and generally ineffectual. Having people go to their areas to listen and learn gained more traction than a year of newsletters and luncheons ever would. Talk about good PR. They felt like we cared. They felt like we were trying. They felt involved.
From my point of view, you can’t have too much hands-on experience. If you write retail sales software for use by checkout clerks, go ring some sales. If you write medical scheduling software, sit with receptionists while people are telling them to do 10 things at once and watch how they handle it. If you write time-tracking software for use on a manufacturing plant floor, put on your hardhat and goggles, get out there, see how the people on the floor log their activity, and try making a few entries yourself. You’ll learn a bunch. And you’ll earn the kind of respect that money can’t buy.
If this sounds like a good strategy to you, but your company doesn’t provide this type of training as a matter of course, here are some suggestions:
Take the initiative. No one is going to walk up and hand you the chance for this type of training. You have to request it for yourself or your team.
Have a plan. When you approach people, you have much greater credibility if it looks like you’ve thought out exactly what you want to do and what you want others to do and why. Your plan should address these concerns:
- What activities do you want to participate in?
- Who in the users' department needs to know your plans?
- Who in your department needs to know your plans?
- What do you hope to gain from this experience?
- What immediate impact will your absence have on your work?
- What will be the impact for the person you partner with?
Respect people’s time. The people in the other departments may be willing to help, and they may see the ultimate benefit for them, but they still have jobs to do. If you make sure you don’t overstay your welcome, you or your team might just be invited back again.
Know the benefit to the outside departments. When pitching the idea to the groups you want to visit, don’t forget to point out how they will benefit. Discuss it with them, and they may even come up with a few benefits that you didn’t think of.
Know the benefit to your organization. You’ll be taking time away from your regular work, which is an investment on the part of your employer. You need to know and communicate how the company benefits.
Start with your boss. Your supervisor may have had this idea for some time. Explain your plan. If he or she can make it happen for you, great. If not, you may still come away with valuable insights that you can use as you pursue the project.
Go to the source. Okay, maybe your organization is clueless. That doesn’t mean you can’t contact other departments on your own. You may find them very helpful and willing to work with you to accommodate a less-than-ideal schedule. Maybe you can spend a couple of lunch hours sitting with the sales team. While not the best scenario, it has the benefit of not interfering with your regular work.
You can’t overdo it
I believe you can’t know too much about the customers you serve. Yes, it takes time. No, it’s not easy. Yes, getting out there may go against the grain of how things have always been done. However, the organization, your department, and you as a programmer will be better for it.
Are you in touch with your users?
What experiences have you had studying or performing your users’ jobs? Has your training included anything like this? Send us an e-mail and share your thoughts and experiences.