研发问题分析与解决技巧
作者: 来源: 文字大小:[大][中][小]
一、前言
研发单位是公司竞争力的指针，也是所有产品状况的最终防线。所以研发人员不单单只需要新产品的研发能力，问题的分析、处理、解决、沟通能力也是不可或缺的。但是由于产品的问题解决往往不是个人能力所能完全涵盖，所以目前以「问题处理团队」的方式来进行问题处理的方式，是
研发管理学术上的一个主流。
这个团队中需要各种人员。首先是各方客户代表，然后是善于分析者，善于操作者，善于协调者，以及流程主管或组织负责人等等。为什么需要这么多的角色呢?举例来说，如果一个团队的组成，都是PM级的人物。如此，横向的沟通肯定没有问题，但是因为每个PM都还有许多的CASE需要处理，变成没有人可以真的下去执行操作会议中决议的事项。又譬如，所有的人才均都齐全，项目也很快的处理完毕了。结果修改出来的东西没有一个客户有兴趣，为什么呢?因为团队中独缺了客户代表，所以并没有以客户的需求下去进行处理。
由于本公司的体制还没有庞大到可以为了一个问题，去组成一个项目小组。但是，希望各位工程师能够了解这样的精神，尽可能以少数人的力量，去达成更完善的结果。这样在将来公司成长起来之后，各位就都是能够独当一面的人物了。
在管理上，通常使用DMAIC的五个步骤来进行问题的解决管理，概述如下：
二、 订定改善的方向 (Definition)
在项目成立之前，首先必须先厘清改善的方向。也就是由客户端所反应回来的产品设计、规格问题，或是由业务端回馈回来的商品规格、成本问题，或是由生产单位反应回来的组装、测试、质量稳定度等等的问题改善方案。这些问题必须被汇整，并且召集所有相关单位研拟，确定必须改善的项目，并同时确定这样的改善，并不会造成其它单位的新问题产生。或是发生不必要的成本、工时。最后，会议的决议必须作成会议记录，并且送交各单位存底备查。如此确认，最后出来的成果才会顺利被所有单位接受。
三、 确定问题点 (Measurement)
问题定义：
现状分析与数据收集 – 首先，问题解决团队必须先根据改善方向会议当中定义出来的改善方向，拟定出可能的问题所在。一般在这个阶段，通常会使用的手法为1. 脑力激荡，以及2. 鱼骨图分析 3. 数据的收集。
1. 脑力激荡 - 将问题改善团队召集，并且利用脑力激荡的手法，尽可能的列出所有可能导致问题发生的原因，一一列出并记录。无论可能性有多低，都必须提出来，并且记录在黑/白板上，并刺激其它的组员产生更新的想法，如此重复的进行，直到没有人能够想出更多的可能性为止。
2. 鱼骨图分析 – 将脑力激荡中所得到的可能原因，加以分类，并改画成鱼骨分析图，使所有组员能够一目了然。并就鱼骨图中表现的出的现象，加以讨论，并归纳出可能性最高的几条可能原因。
3. 数据的收集 – 根据鱼骨图中分析出的可能原因，进行进一步的数据收集或实验证明。每个可能性都必须收集到足够的数据，来证明其是否为问题主要的原因。
四、 分析问题 (Analysis)
此一阶段，就是利用搜集得到的数据，来进行分析，以确认问题发生的根源为何。这是一个急转直下的过程，往往结论就在一瞬间得到，所以必须非常仔细慎重的进行。
原因分析：
分析型的问题(非数据型)
非数据型的问题通常为逻辑值的累积结果，如发生率等等。在非数据型的数据分析重点，即在于发生装况的周边条件，必须也加以记录。藉由大数法则，及能够在量化的过程中，发现问题之所在。
分析型的问题(数据型)
数据型的问题也必须经过大数法则，得到可靠的参考数据，并藉由不同的实验参数，得到更多的比较值。通常可以藉由反复的交叉比对，发现问题之所在。
五、 改善问题 (Improvement)
对策拟定与评估
解决难题经常是99%的努力在于寻找关键原因所在，而修改只需要1%的努力。
一旦原因确定，改善的结果就只是时间的问题。但是不幸的，RD就是没有时间!掌握时间的方法，就是快速的列出所有可能解决该问题的方式，并同时列出该方案的优点与缺点，并同时提出解决方案，以及可能造成的成本问题。
方案一一列出并讨论之后，应该选择哪一个方案，就应该非常的清楚了。
实施对策及追踪
改善方案的实施，必须有其阶段性，初期必须以实验性质的方式来进行。小规模的测试，或是实验。待证明其效果确实，再逐渐扩大实施的范围，期间必须不断的追踪问题改善的成效，并收集足够的信息，作为随时调整方案执行方式的参考回馈值。
切忌因为时间的压力，就将预先设想应该没有问题的方案，一次就进入大规模的测试或修改，如此很可能因为一个差错，就造成更大的问题，甚至到无法收拾的地步。毕竟人脑不是万能的，总是有可能发生失误。
六、 效果控制 (Control)
效果确认
在逐步扩大实施范围后，必须定期召开或发行问题改善现况的确认报告。以便随时发现可能发生的潜在问题，并有助于改善时程的控制。
再发防止
研发单位也有「不贰过」之责任。所以在每次改善项目结束之后，皆应撰写改善报告，以及分析问题之成因。并发行给所有研发单位人员，作为研发时之参考资料。避免一再的发成同样的问题。
未来方向
改善项目的累积数量达到一定的程度之后，可以藉由分析各项目知过程、内容以及结论。分析出研发单位最容易发生的问题，以及如何避免发生类似问题的方法。藉由这些宝贵的资料，可以编辑成册，作为研发单位的研发手册，或是在研发标准程序当中，增加街段性的检讨项目，以期在未来，尽可能的完全杜绝问题的发生。