开发过程中返工预防及监控
在开发工作的组织方面，我们建议A企业将原来的串行开发转变成并行开发。组建了有技术、营销、生产、采购及质量等部门人员参加的跨部门开发小组，让其他部门从一开始就介入到产品开发中来，把他们的“抱怨”作为需求提出来，一起形成产品的需求，然后再一起开发产品的“设计方案”（如系统、软件、硬件、结构、工艺等）。这样以来，既可以让相关部门准确的理解需求，又可以及早的暴露问题，并可以及时的得到修改，避免造成大量的返工。
在工具层面，我们针对经常出现的问题以及其原因，对产品开发过程中的关键活动，在流程及工作方法（流程、指导书）优化的基础上，进一步细化了流程活动的操作工具—活动模板，而且很多模板做到了样例化。比如，针对研发人员经常出现小“问题”，我们在相应的活动后面增加了自检或审核，并对自检及审核设计了自检与审核工具---CheckList（查捡表）。针对需求分析经常出现遗漏或需求模糊的问题，我们设计了需求分析模板以及需求评审模板—需求分析书、需求评审要素表等。 对这些常出现的问题，他们建立经验教训库，并借助IT工具对其进行动态的更新管理，以便使其能够既有效的避免员工犯同样的错误，而又不至于占用他们很多的时间，以提高经验教训库的实用性。

表4-1 流程关键模板示例

最后，为了确保这些改进措施得到落地执行与持续优化，A企业还接受了我们的建议，成立专门的流程管理部门，并将流程优化纳入到对各部门负责人及骨干的考核中。
改进措施实施三个月后，“小问题”开始明显减少。半年后，由于需求不明确或需求遗漏而造成的返工也开始明显减少，大家的跨部门协同意识也明显加强。“以前，只要是出了问题，大家首先说的都是为自己推脱责任，现在，大家首先说的则是怎么能把问题解决了，变化很大！”A企业的一位高层如是说。
其实，像A企业这样的企业还很多，我们希望通过这个案例，能对其他企业在减少产品开发过程的返工，提高过程质量与效率，提升研发管理水平有所启发与帮助。