Creeping feature-ism
Last issue I addressed the problems of product failure caused by incomplete market
product requirement analysis and faulty design specifications. These are primarily
external factors which are misunderstood at the beginning of the design process
leading to a product market failure.
There is also a second trap we technologists are sometimes prone to fall prey to,
the deadly "creeping feature-ism." The syndrome of this affliction is never-ending
design iterations, missed release dates, and products bristling with so many features
and so difficult to use that the average use approaches the product with the same
enthusiasm and anticipation as petting a porcupine.
Creeping feature-ism is the result of the breakdown of design discipline. First,
you must have done your homework and have a comprehensive product
requirements/function definition and have cross-referenced each product feature
in your design specification against a product requirement. Then, the role of the
design manager is to rigorously enforce the design process to keep the product design
on tract so that what you are designing actually matches the specification!
Repeat the mantra - "Function first, performance second." It is surprising how often
we designers start to "optimize" incomplete designs. After all, we are technologists.
We get caught up with the technology and lose sight of the product functional
requirements. We focus on how the product works rather than what the product needs to
do. If the design is not firm, optimization is a waste of time and resources.
And of course, when we start to optimize a design, we start thinking... hey, I can
easily add this little feature at no extra cost, or this is neat, but wouldn't it be
great if we could also do this... Before long, not only have we wasted design
resources, but we also have a porcupine on our hands, bristling with neat, but from a
users perspective, completely unnecessary and probably hard to understand features.
Who hasn't accidentally pressed the wrong key in a complex program only to find their
work reformatted in some strange and mysterious fashion - or lost completely due to
a "neat" function which until now we had no idea existed?
Implement complete functions first. If early in the design process of a complex
product, simulate or prototype the design. But in either case, early in the design
process get the product into the hands of users/evaluators as fast as you can, to
determine if you are on the right track. Market place requirements shift in time -
sometimes very quickly. Verify that your users agree that your solution still meets
their needs while you still time to make a design course correction. The earlier in the design process a correction is made, the less expensive it is. This reality check will also indicate what the product users think needs to be optimized or improved to make the product more attractive. This will help to insure that any extra design time and expense added to the program has a real bottom line pay-off.
Finally, only when the product functions as advertised in the product specification
do you begin final optimization. You cannot piecewise optimize a design. Especially in
team designs, until there is a complete implementation, you cannot anticipate the
interactions of the individual functions which comprise the complete product. At a
minimum you will lose time backing up a design to include a needed interface
modification. At worst you can optimize yourself so far into a corner that you cannot
back up and will need to start all over. Both of these situation will wreak havoc
with your design schedule.
|
"Real World Applications" require
sophisticated sensor interfaces, and the MB2001 MechaBlox card
makes sensor interfacing a snap.
