Читать книгу So You Want To Be An Engineer - Ray Floyd - Страница 8
ОглавлениеToo often civic and government organizations announce and implement programs that fail to meet their intended goals, with great cost to the taxpayer. Once in a great while, industry will have a product that fails to meet market expectations, but not often. Even when industry has a failure, the overall product base of the company can often compensate for the single product failure to meet revenue goals. If they didn’t have such a distribution, they would soon be out of business. So what are the differences in the product development procedures that allow success on one hand or almost certainly ensure failure on the other?
Most successful products will have three important documents produced prior to the product ever reaching the design and implementation phases. The three are: 1) Market Requirements, 2) Product Specification, and 3) Product Test Plan. The first document is generally written by the Marketing Department (Sales, Product Planning, Marketing or similarly titled groups). In that document, the questions to be answered include: 1) what is the product need? 2) who are the users? 3) when is it needed? 4) what is the impact on current product sales? 5) what is the competition doing? 6) what are the sales projections and pricing? and 7) are there any special requirements (for example, language, accommodations, mean-time-to-failure, mean-time-to-repair, and service expectations). This list is not exhaustive, but gives you some idea about the content of the Market Requirements document.
The second document, Product Specification, is written by the Product Development group. The Product Specification is a detailed description of how the new product will meet all of the Market Requirements. If a particular requirement cannot be met due to time, cost, technology, or other factors, that requirement will be negotiated out of the Market Requirement with agreement between Marketing and Development. The Product Specification does not detail the product implementation method. That is left to the Product Design group responsible for the final product build. The Product Specification provides explicit statements (testable) for each area. For example, the Market Requirement may have stated the requirement for the new product to “operate on North American and European voltage and frequency.” The Product Specification cannot use the same words, as there are no specified values (cannot be tested for meeting the requirements). In the Product Specification, the requirement may be shown to be a product that operates on 50 to 60 hertz, 90 to 130 volts AC. These values can be validated.
The final document is the Test Plan. This document is written by the Product Test Group, and will put in place a series of tests to validate that the designed (and built) product will meet all stated requirements and specifications. In most cases, the tests of hardware will test to limits beyond the specifications to allow for part/product variability during the manufacturing process. The Test Plan may also specify that usability or field testing be conducted as lab testing cannot verify all aspects of the product anticipated use. This type of detailed testing is in addition to all the testing that will be done by the Development group during the development process.
A company’s marketing staff find a product need and convey this to the company’s development branch for consideration. If a trial is deemed reasonable, the proposed product is designed, reviewed and, if approved, a model is then developed and sent to the company’s testing organization. They in turn develop a test plan, which is reviewed with the developers, followed by a series of appropriate tests. Such tests may involve controlled environmental trials, noise levels, vibration, etc., conducted within lab facilities, or they may be conducted at field locations, especially where usability questions must be addressed.
Problems get corrected and testing is repeated. If the testing is successful, the product is released to manufacturing and initial production units, typically three to ensure for parts variability, are again subjected to planned testing. Once again, testing may include field testing in selected business environments. When the product successfully passes through the testing, it is released to full production and shipment to customers. Throughout this testing process, the product market is continually reviewed against Market Requirements and System Specifications in order to ensure the product is going to achieve its expected market, both in costs and revenue. This is a very brief description of the development, testing, and manufacturing cycle employed by many successful industries.
The market has many examples of successful companies, companies that exhibit fiscal responsibility, controlled product development and release, and quality control of the product release. If examined closely, it will be found that their good practices help them remain competitive and successful in the market today.
Industry is not above suffering from the lack of, or poor definition of, Market Requirements. Three famous failures come from the automotive world with the Ford Edsel, the DeLorean, and the Tucker. In the cases of the Edsel and the Tucker, the cars were of a futuristic design, and simply not accepted by the buyers. Ford Motor Company spent over $250 million for the Edsel, but in the end the car line was dropped due to the lack of buyer acceptance. The Tucker suffered from problems of too many user options, and failed after only 51 cars were built. In the case of the DeLorean, the cost of the automobile was far beyond any other at the time and thus suffered poor sales. The DeLorean may be best remembered as the automobile used in the movies Back to the Future.
The authors had the experience of being involved in a new process control computer system that had all appearances of being a unit with a wide open application base. Although the unit had good Market Requirements and a Product Specification that had gone through the normal rigorous process, somewhere something got lost. When the new product reached Product Test and entered usability testing one major flaw was found: the unit only had paper tape as an input/output device! There was no way to write, compile, or execute programs on the unit without using some other system to prepare the program tapes for loading. Totally unacceptable for the most simple applications, the problem had to be fixed before the system entered the market. The problem was corrected, and the product went on to be one of the industry’s most widely accepted process control systems.
In each of the situations described, the lack of good Market Requirements and Product Specifications could be seen as the primary reasons for the failure or poor results for the particular project.
The authors had the experience of what could be called “Ugly” projects. In the first case, the project was a new process control system which included, as an option, an arithmetic unit that included binary-coded-decimal (BCD) arithmetic and conversion hardware. As Marketing believed that some users would not want to include the cost of the arithmetic unit, a software emulator would be required to support BCD arithmetic applications. The emulator project was funded and development completed. When the system entered Product Test, the project failed miserably. Whereas most BCD operations performed in the hardware were measured in micro-seconds to complete the desired operation, the emulator took an extremely long time. In some instances, rather than MIPS, the unit was said to perform in furlongs per fortnight. Needless to say, the emulator was never released and the hardware unit became the standard system.
In the second case, the project was a shipboard guidance and collision avoidance control system. The proposed system had international impact, and was viewed as being a great prospective revenue producer for the corporation. The product went through the normal testing process, including extensive sea trials and appeared to be an unqualified success. Unfortunately, when the Market Requirements and Product Specification were written, the Service aspect of such international travel was not taken into account. As a result, when a problem did occur, the service engineer might have to be flown from one country (where the service center was located) to another where the ship was docked. In some cases, the service engineer would have to be transported to the ship at sea via a helicopter. To further complicate the servicing aspects of the product, in some cases when the ship docked at a new location, the service engineer could not leave the ship, as his or her passport was not acceptable to that country and the engineer would have to remain on-board waiting for the next port of call. The product was not as successful as had been hoped.
Project successes can be measured by cost, time, and revenue as constituent parts. In most projects, the better the Market Requirements and Product Specification, the higher the probability that the project will be a success. This doesn’t mean a lengthy tome, but a set of documents that fully explore the anticipated market and user. Add to that the rigorous review and test processes needed, and, for each level of control, the higher the probability of success. Understand the process, work the process, and ensure your projects stay in the good regime.
A product’s success, or failure, may often depend on how well the product was defined before it was developed. Some products based on a developer’s concepts may become popular and in demand, but in most cases, because of the narrow perspective of a developer’s specific application, such products rarely hit the high revenue mark. To raise the probability of success for a newly announced product or product enhancement, both the marketing and development communities must have a road map of the direction they wish to take. These road maps are referred to as Market Requirements and Product (or Technical) Specifications, both of which are required for the Testing organization to develop a comprehensive Test Plan. The more complete and detailed these two documents are, the greater the probability that the product will succeed in the market place.
These two documents are not developed in a vacuum by each group, with Marketing (which often includes the Sales Department, which is responsible for the day-to-day-in-the-face exposure to the customer) writing the Market Requirements and Development the Product Specifications. Marketing may ask for new, not yet invented, technology, and Development too often then provides a timetable that is too long and too expensive. Such differences must be negotiated and resolved. Special features may require new algorithms, or other development work that will not meet Marketing’s expectations — and the features may be so narrow in scope that their absence will not affect the overall acceptance of the product by the user community.
In many cases, the Marketing and Development groups will modify and discuss both documents until a consensus can be arrived at in order to meet the market needs, in a reasonable time, at a reasonable cost, with the most highly desired features present. In addition to Marketing and Development, three other organizations are called upon to help ensure the product requested and the product delivered are the same. Those organizations are Product Test, Manufacturing, and Quality Assurance. The specific roles carried out by each will be investigated in later chapters.
Most successful products have their success grounded in complete market research conducted before the product is designed. Although there are a number of facets to be discussed within the Market Requirements document, perhaps first and foremost is, “Who is the intended user group?” Immediately after is the question, “What problem, or problems, will the proposed product solve?” If either question is found to lack a definitive answer, perhaps the funds for the development undertaking would be better placed elsewhere. In some cases, the breadth of the possible applications may not be fully anticipated while writing the Market Requirements document.
Consider, for example, the simple requirements for road building equipment. Two sets of extreme conditions are real-life cases of environments in which the same kinds of equipment were required to perform similar tasks under totally opposite condition extremes. Case one was road building equipment (trucks, bulldozers and graders, etc.) to build a road over forested mountains, then down through the densest jungle in the world within a war zone. There were summer monsoons of 300 to 500 inches of rain each spring-summer season, and another 100 to 200 inches during winter monsoons. Diluted fuels, rust, fungus, and so forth were daily problems that had to be overcome to complete the road. The other extreme was California’s Death Valley, which is absolutely arid, with summer temperatures in excess of 120 degrees, no rain, and limited sources of water for equipment and workers, and at times, extreme dust conditions. The intense heat coupled with the dust that infiltrated equipment wear points created havoc in the road building process.
Another example considers the Market Requirements for a new design of a desk top computer used by experienced engineers that could also be installed at airport car rental counters and used by someone hardly as computer-literate. In such cases, documentation for the system operation, if not fully specified in the Market Requirements, could result in instructions with technical jargon essentially not understandable by the less computer literate user.
There are a number of items the Market Requirements should address, among these being:
• Proposed user problem requiring a solution.
• Who is the targeted user community?
• What is the sophistication of the user community (neophyte, intermediate, advanced)?
• When can the product be delivered and at what cost?
• What are the required features and/or modifications?
• Who is the competition and how are they performing (in this product venue)?
• What are the sales expectations to ensure profit (high, median, and low)?
• What languages are required to support the user and field service personnel?
• Is there any special technology constraints that must be solved?
• Strengths, weakness, opportunities, and threats (SWOT) analysis for the product.
• Is there a growth path for the product and future model enhancements?
• What is the Mean Time Between Failure (MTBF) criteria expected/required?
• What is the Mean Time To Repair (MTTR) criteria expected/required?
• Are there any special or unique needs for testing by Product Test, Quality, and handling by the Field Service organization?
Note the word required inserted into the MTBF and MTTR list items. There is a significant difference between expectation and absolute requirement, and these differences must be understood and agreed to by Marketing and Development.
Specifications are something more than simply a passing reference when talking or learning about products and product design and development. Specifications should embody an underpinning of market requirements and existing standards, as well as use, user and maintenance requirements, and limitations, as well as performance requirements.
Product Specifications and Technical Specifications are often used interchangeably, but should not be. Product Specifications will normally provide a functional description of the product, including such aspects as weight, size, performance, temperature (transit, storage, and operating), power, maintenance issues, interfaces, connectivity, compatibility with older systems, languages for displays and documentation, and any certifications or standards the product must adhere too. This is not a complete list, but it is important to note that none of the items listed designate the implementation method needed to satisfy the function. The implementation is left to the development group, allowing maximum freedom in the choice and also the possible use of new technology.
As a simple example, consider the product specification of including a removable memory device. The implementation in the Technical Specification may map this requirement into including magnetic tape, diskette, memory stick, R/W CD, or even a USB connected external storage device. In short, the implementation method is left to the developer— as long as the implementation meets the Product Specification requirements.
One important aspect of the Product Specification, often overlooked, is that the specifications must be able to be verified by Product Test, Manufacturing, and Quality. For example, for the specification to state that the equipment must operate from commercial power is not verifiable. It begs the questions, “What commercial power? What voltage or voltages? What frequency? What variation is allowable? What is the maximum current load?” In each question, national and international differences must also be recognized if the product is to be marketed internationally.
The Product Specification will normally list any standards that the product will be required to meet, for example UL/CSA safety requirements. In addition, it will list any industry standards or international standards that will be required to be met for sale of the product in countries other than the home country of the product.
As noted previously, Market Requirements and Product Specifications need to cover a wide range of product aspects, such as:
• the intended market(s)
• user description(s)
• use conditions expected to be encountered
• those to address the acceptable limits
• mean-time-to failure
• mean-time-to-repair
• required through-put
• load capacity
• temperature and humidity high and low limits
• vibration and/or impact
• sound/noise level limits
• serviceability and operational access requirements
• all documentation to be used by the product manufacturer, intended users, and those who will service and maintain the equipment
Not to be ignored are national standards established by and for industries as to their products and services. These standards must be explored when developing product and services specifications, and the test plans for their evaluation. Finally, there is the question of intellectual property, i. e., are there patents that need to be written and/or avoided, and what trademarks may be used for the final product? Intellectual property rights are a major investment for any company and can create a heavy burden on new product development efforts.
A development organization will typically be composed of a number of different engineering skills, ranging from electrical engineering to field engineering. In each case, the specialty needed will provide a portion of the final product design effort. No one specialty is any more critical than the others, but all must work together to provide the desired results - a successful product introduction.
Circuit design is most often carried out by electrical engineers. One difference in the technical approach is whether the circuits in question will be analog or digital. The difference requires different skills from the engineer. Analog circuits must be able to respond to a time varying signal, faithfully reproducing the signal of interest. In the case of the digital process, the same analog signal will be approximated by a sample process, providing a series of step values. The reproduction of the analog signal in a digital world will not be exact, but, depending on the sample rate, may approximate the signal closely enough for further processing. Some will argue that the analog signal design engineer is more of an artist, whereas the work done by digital design engineers is more scientific in nature.
Frequently, based on predicted volume sales, a complete application may be developed on a single chip — the Application Specific Integrated Chip (ASIC). The ASIC replaces many separate devices, resistors, capacitors, and similar discrete electrical parts, with the necessary mask layers on a substrate to implement the replaced physical components. Although the logic of the ASIC will typically be developed by an electrical engineer within the development group, the mask build, substrate build, and final assembly will more likely be completed by a process engineer familiar with chip manufacturing, perhaps even by an outside vendor who specializes in chip manufacturing.
Magnetic media design, whether magnetic tape, disk, or diskette, requires a mix of engineering talent. Although the principle topic is magnetic media, the reading and/or writing device must also be considered. From the media perspective, both chemical and process engineers must be involved. The material supporting the reading surface must be established, whether tape, disk, or diskette. It must be strong enough to support the movement of the media, yet pliant enough to not be damaged by handling. The material must also be capable of having the magnetic surface adhere to it, providing the magnetic media for information recording. The purity and uniformity of the surface is also critical as the bit density and speeds have increased significantly over the years.
From the perspective of the device handler, mechanical engineering and electrical engineering skills are needed. In the case of the electrical engineers, both analog and digital skills will be required to complete the product. In general, the data being read and/or written is digital information, but the magnetic media is analog in nature. As a result, the read head design lies mostly in the realm of the analog engineer, while the control and digital processing belong to the digital engineer. The skills of the mechanical engineer are called upon for the design of the movement of the read head(s) and the read head itself.
Power supply design lies primarily in the realm of the electrical engineer. In this case, the engineer must have a firm knowledge of the types of AC rectification modules, filtering, and supply loading that might be appropriate for the supply. Overload conditions, power sequencing, frequency response, input voltage variations, output loading variations, and other characteristics must meet the conditions given in the overall equipment specifications.
All of the electronics may be designed and built, but it remains to the packaging engineer, typically a mechanical engineer by skill set, to make the parts into a system. The outside covers, equipment racks, and other physical aspects of the new product must be reviewed and taken into account by the packaging engineer. Other items that may need to be considered are the packaging and shipability of the system, i.e., can the system be separated into smaller units for packing, shipping, and easier handling? Whether the system must include extra cooling, fans, heat exchangers, or water cooling options must also be considered.
