support ⁽²⁾

Picking up someone else's design to get it into production is a common enough situation and yet there are always interesting problems to be solved. These can get particularly challenging if that previous engineer has left the company and was the only one who really knew how the product worked. In this case, not only was it a new product, it was the first product of a new range using a new processor and new communications protocol, which we were going to develop into many more variants. So it was inevitable that there would be some bugs found by the first customers. Of course the product worked fine on the bench - it was when multiple products were wired together in the field that the bug showed up. Although as a product manufacturer we specified how the field wiring was to be done, it is never that simple. Wiring is done by third parties who don't know the product design and system requirements, so what looks equivalent to them isn't necessarily acceptable in the complete system. We should have been able to provide sufficient guidance about the wiring requirements to guarantee acceptable performance, but this requires either a lot of…

In all the companies I have worked, when the product development is finished it gets passed on to manufacturing and product support but the original developer retains ownership of the design. It's important that the product support department gets full training on how the product works, how to use it, how to diagnose problems in the field and on the bench, and what happens under misuse and failure conditions. But I have never seen a product support department really own the design to the extent that they could diagnose down to component level in the hardware or line of code in the software, which means that the last line of technical support comes back to the R & D engineer. Too often, that last line is perilously close to the first line, such as when the support team are understaffed or a particularly difficult field problem arises. On each occasion, the support team need to drag the R & D engineer off his assigned project with very little notice, often within the hour of the problem arising. If the support staff are not involved in the solution, even if no design change is needed, they will not learn what the…