Assisting enterprises in learning, exploring, reengineering, and implementing component-based/object-oriented software solutions using best-in-class methods.
|
|
|
|
It never ceases to amaze me with large companies. Where are all of the information technology professionals? I'm not talking about the people with titles. I'm talking about the people who really know their stuff. As a professional consultant (white collar migrant worker), I see many fortune 100 companies that do not have the techno-business acumen to adequately address their challenges. I can only guess that all of the people who "know their stuff" left the company for better, more lucrative and interesting opportunities, or retired. Nevertheless, in the course of practicing I must work with people (internal employees and external contractors/consultants) whose title includes the word 'analyst'. Often, the first thing I do upon meeting these 'analysts' is determine their backgrounds and share mine. The amazing concept is that frighteningly few 'analysts' have any grounding whatsoever in analysis. That is, they do not use tools or techniques for eliciting, capturing, validating, and communicating the focus of their analysis. Understandably, when asked for their repertoire of techniques the analyst gets defensive remarking that such techniques are "academic", "theoretical", and are not useful in the real world. Many of these analysts are "super-users". These were the cream-of-the-crop clerical workers that were able to write procedure manuals and offer procedural improvement suggestions. A product of '80's (and earlier) systems development efforts, these folks employ the time honored hacker approach. That is, keep saying (writing) it over and over again until your "plain English" is understood. Plain English is the tool and technique of many analysts. The good news is that most other analysts are equally unversed in more formal techniques. Therefore, they appreciate the plain English. The bad news is is that the consumers of the material (developers) can't make heads-or-tails of the ambiguous litany. The vicious life cycle continues: The developers are also guilty of not using formal methods, so they secretly love the ambiguous litany; they get to 'interpret' and are not accountable if they get it wrong (which is often the case). Here, the developers merely devalue the analysts work, go directly to the users and simply continue hacking until the user surrenders. Now we have an application or system that is based on ambiguous requirements, hacked code, and users that are less than satisfied with the solution. Is it any wonder that most projects fail? When are we going to admit that systems are the result of clearly understood requirements, repeatable techniques, common vocabulary (not plain English - which is never plain) of words and symbols with clear semantics and meaning. I imagine that the analysts of which I speak regard computers as intelligent forms that "know better" when faced with ambiguity. An important question to ask any prospective analyst, whether they are internal or external candidates, is "with what programming language or languages have you experience?" If the answer is, "I've never programmed", do your company a big favor, pass on that candidate. This candidate could not possibly have internalized the requirement for specificity and will not provide the type of value necessary to do the job correctly. ...to be continued... |
Send mail to smarcus@MarcusSoftwareDesigns.com with questions or
comments about this web site.
|