德通咨询 任传宏
两年前与一家企业（A企业）交流时，他们的企业负责人说：我的产品开发返工太多，一个小产品也要折腾3-4次，严重影响了上市计划；研发负责人也在向我们诉苦：其实我们也不想改来改去，可市场的需求不停的在改，我们也没办法，再说了，我们改来改去，也是为了产品更好卖啊；供应链负责人则向我们抱怨：研发交付的样品问题一大堆，我们简直没法生产。不是缺了某个技术图纸、就是图纸不是最新的，或者图纸标注错误；不是缺了某个物料、一等好几天，就是我们的工艺根本就没法生产……我们虽然多次向他们反映，可我们开发人员却总是不以为然，他们甚至认为这些问题都是“小问题”，不要小题大做，可正是由于太多的这样“小问题”重复的、经常的出现，新产品多的时候，搞得我们无法正常生产，货期经常延期。
为了进一步了解A企业产品开发经常返工的问题，我们进行了深入的调研，经过2周的调研分析，我们发现，A企业产品开发过程中的返工可以归纳为以下五大类：
1、 由于一些“小问题”而返工。例如：产品图纸/技术文档不是最新的、图纸/技术
文档标注错误等；
2、 由于需求不明确而返工。例如：产品图纸/技术文档里忘记说明器件或配件/物料
的装配工艺，而靠下游的打样人员根据自己的经验去判断，结果往往会导致样品与开发人员要求不一致而返工；
3、 由于遗漏某方面的需求分析（如“条件限制”）而返工。例如，由于工艺条件达
不到，而返工，由于采购不到需要的器件，而返工，由于超目标成本而返工；
4、 由于需求更改而返工。例如：销售人员突然反馈说，这款产品需要增加一个新
功能或者成本太高等；
5、 由于设计错误，导致产品功能不符合要求而返工。
上述五类问题中，出现较多的是第一类和第二类问题，接下来次多的是第三及第四类，第五类问题较少。
为了减少返工，我们对上述五类问题产生的原因分别进行了分析，分析发现：
1、 由于产品开发人员忽视技术文档以及不良的工作习惯（比如粗心），导致经常出
现“小问题”；
2、 由于上下游之间缺乏明确的输入及输出要求，凭经验办事，经常造成需求不明
确或需求理解错误，而引起返工；
3、 由于缺乏对需求的全面理解和需求分解工具，造成在进行需求分析时仅仅考虑
功能、性能等技术性需求，而忽视或遗漏了成本、可采购性需求、可制造性需求等“限制性需求”或“内部需求”。
4、 造成需求更改的主要原因有两类，一是在前期需求分析时，由于缺乏系统的希
求分析工具或投入不够，而遗漏了部分需求，比如易用性、成本等，另外一类是由于对市场及产品缺乏系统的规划，只能被动的由市场或客户牵着鼻子走。
5、 造成设计错误的原因主要是由于经验不足。
从上述的问题原因分析中，我们可以发现，造成产品开发过程中返工多的原因虽然是多方面的，但是通过统计归类，我们发现主要是以下三个层面：
1、 认识层面：对产品开发的可管理性及系统性缺乏理解。造成第一、三、四类问题
的原因中，有很多就是属于对产品开发管理认识不到位的原因。
2、 工作方法层面：缺乏明确的、可操作的开发过程指导。开发过程过于粗放，甚
至关键活动的输入、输出都不明确。不同的人做同一件事情，有不同的做法，甚至同一个人都同一件事情也有不同的做法，结果相差很大。“同一个方案/样品，今天评审没有通过，明天重新评审一下就可以通过了，这是常有的事情”。一位研发经理如是说。
造成第二类问题的原因就是很典型的属于工作方法层面的问题。
3、 工具层面：产品开发过程缺乏专业、系统缺的工作工具（主要是非技术方面的工
具，例如需求分析方法及工具、评审方法及工具等）。
针对每类问题出现的频率以及问题产生的原因，我们采取了不同的解决策略及方法，并从认识、工作方法及工具层面进行系统的改进。
在认识层面，我们对产品开发团队（不仅仅是技术人员，包括市场、采购、工艺等与产品开发相关的职能代表）及业务骨干进行了研发管理体系、研发流程、研发项目管理、研发人员职业素养等培训，通过系统的培养，研发团队及相关业务骨干，特别是中高层团队对产品开的跨部门协同性、系统性以及可管理性有了较深入的认识，对树立跨部门协作的流程意识起了表率作用。“真没有想到自己的一个‘小问题’会给下游部门带去那么多的麻烦及工作量，以后的工作中，我们将争取杜绝‘小问题’”。培训后他们的一位研发负责人这样感慨到。
在工作方法层面，首先，我们优化了市场与产品规划流程，把以前市场与研发各做各的规划统一起来一起考虑，以避免研发与市场脱节，同时也可以让研发更好的理解市场、理解需求，减少需求变更。为了减少客户的需求变更，除了提高需求分析的质量外，我们还建议加强对客户需求的管理及引导，这就需要我们对客户的业务或市场有较强的前瞻性，为此建议对业务专家的招聘与培养提升到战略高度。
其次，我们产品开发流程、及其相关子流程进行了优化，明确了每个阶段的输入及输出和关键控制点。并重点对产品开发流程中的关键活动（如需求分析、测试、评审等）进行了优化，对关键活动从输入、输出、执行活动的角色职责与能力要求、活动的操作方法及工具等方面进行了细化（如需求分析子流程、原始需求收集操作指导书、需求评审要素表等），从而保障关键活动的需求明确、执行步骤明了、执行人的职责清晰、操作方法及工具清晰，避免由于需求不明、活动缺失或模糊而导致的返工。对经常发生返工的环节，设置了监控点，进行自检或互检，然后再进行子评审，子评审通过后提交到项目组，进行评审等，以加强预防与监控。
开发过程中返工预防及监控
在开发工作的组织方面，我们建议A企业将原来的串行开发转变成并行开发。组建了有技术、营销、生产、采购及质量等部门人员参加的跨部门开发小组，让其他部门从一开始就介入到产品开发中来，把他们的“抱怨”作为需求提出来，一起形成产品的需求，然后再一起开发产品的“设计方案”（如系统、软件、硬件、结构、工艺等）。这样以来，既可以让相关部门准确的理解需求，又可以及早的暴露问题，并可以及时的得到修改，避免造成大量的返工。
在工具层面，我们针对经常出现的问题以及其原因，对产品开发过程中的关键活动，在流程及工作方法（流程、指导书）优化的基础上，进一步细化了流程活动的操作工具—活动模板，而且很多模板做到了样例化。比如，针对研发人员经常出现小“问题”，我们在相应的活动后面增加了自检或审核，并对自检及审核设计了自检与审核工具---CheckList（查捡表）。针对需求分析经常出现遗漏或需求模糊的问题，我们设计了需求分析模板以及需求评审模板—需求分析书、需求评审要素表等。 对这些常出现的问题，他们建立经验教训库，并借助IT工具对其进行动态的更新管理，以便使其能够既有效的避免员工犯同样的错误，而又不至于占用他们很多的时间，以提高经验教训库的实用性。
表4-1 流程关键模板示例
最后，为了确保这些改进措施得到落地执行与持续优化，A企业还接受了我们的建议，成立专门的流程管理部门，并将流程优化纳入到对各部门负责人及骨干的考核中。
改进措施实施三个月后，“小问题”开始明显减少。半年后，由于需求不明确或需求遗漏而造成的返工也开始明显减少，大家的跨部门协同意识也明显加强。“以前，只要是出了问题，大家首先说的都是为自己推脱责任，现在，大家首先说的则是怎么能把问题解决了，变化很大！”A企业的一位高层如是说。
其实，像A企业这样的企业还很多，我们希望通过这个案例，能对其他企业在减少产品开发过程的返工，提高过程质量与效率，提升研发管理水平有所启发与帮助。
如何减少产品开发过程中的返工