When a person visits a doctor to complain about an ailment, it is not uncommon for the patient to try and diagnose the problem himself and prescribe a cure. The doctor listens politely but then asks a series of questions aimed at analyzing the patient's symptoms, for example, "When and where did you first notice this?" "How often does this happen?" "What medication are you currently taking?," etc. By analyzing the symptoms, the physician is trying to diagnose the problem. If he cannot ascertain the problem through questioning or a basic examination, he may order additional tests, such as an MRI, X-rays, a CAT scan, blood tests, urine samples, etc. The point is, the doctor is more interested in attacking the root cause, not just the symptoms.
We see this same type of phenomenon in Information Technology (I.T.) related projects where the end-user approaches the I.T. manager with a request for service whereby he sincerely believes he knows the right technical solution to solve his business problems. Two things may result from this request either the I.T. department will treat the users symptoms, and give him what he wants, thereby not really solving his business problem correctly, or; the I.T. department will study the user's problem more closely, possibly order some tests, and prescribe a solution that properly addresses his problems. Regrettably, this latter approach is rarely performed in companies anymore.
There is still a huge frustration factor between users and I.T. developers. On the one hand, users claim, "They (the I.T. people) don't understand me," and on the other hand, the I.T. people contend the users "don't know what they want." This void between the two groups is unhealthy and not conducive for solving the company's problems. Frustrated, I.T. management tells developers not to ask questions, "Just give them what they want." This scenario is obviously counterproductive, yet commonplace in the corporate world today
When I am asked how to deal with this situation, I emphasize the doctor-patient analogy as mentioned above. First, the I.T. people have to learn to ask more questions and differentiate symptoms from problems. In other words, let's not be in such a hurry to program a solution before we truly understand the problem. I.T. has a horrible track record in this regard. The idea of specifying user information requirements is the Achilles' Heel of every development project. If it is performed superficially, the wrong solution will inevitably be delivered. Second, the user should play the role of a patient, meaning don't try to prescribe a solution but concentrate on what you truly need and let the doctor (the I.T. department) prescribe a suitable solution. After all, who has more training in this regard, the doctor or the patient' Let the I.T. people do what they're trained to do (and are paid for).
As long as we know our roles and do not try to do the other person's job, we'll get along just fine. Now turn your head and cough.
Keep the Faith!
in Programming
No comments:
Post a Comment