|
造成第二类问题的原因就是很典型的属于工作方法层面的问题。项目管理者联盟
3、 工具层面：产品开发过程缺乏专业、系统缺的工作工具(主要是非技术方面的工具，例如需求分析方法及工具、评审方法及工具等)。项目管理者联盟
针对每类问题出现的频率以及问题产生的原因，我们采取了不同的解决策略及方法，并从认识、工作方法及工具层面进行系统的改进。service.mypm.net
在认识层面，我们对产品开发团队(不仅仅是技术人员，包括市场、采购、工艺等与产品开发相关的职能代表)及业务骨干进行了研发管理体系、研发流程、研发项目管理、研发人员职业素养等培训，通过系统的培养，研发团队及相关业务骨干，特别是中高层团队对产品开的跨部门协同性、系统性以及可管理性有了较深入的认识，对树立跨部门协作的流程意识起了表率作用。“真没有想到自己的一个‘小问题’会给下游部门带去那么多的麻烦及工作量，以后的工作中，我们将争取杜绝‘小问题’”。培训后他们的一位研发负责人这样感慨到。项目管理者联盟
在工作方法层面，首先，我们优化了市场与产品规划流程，把以前市场与研发各做各的规划统一起来一起考虑，以避免研发与市场脱节，同时也可以让研发更好的理解市场、理解需求，减少需求变更。为了减少客户的需求变更，除了提高需求分析的质量外，我们还建议加强对客户需求的管理及引导，这就需要我们对客户的业务或市场有较强的前瞻性，为此建议对业务专家的招聘与培养提升到战略高度。项目管理者联盟
其次，我们产品开发流程、及其相关子流程进行了优化，明确了每个阶段的输入及输出和关键控制点。并重点对产品开发流程中的关键活动(如需求分析、测试、评审等)进行了优化，对关键活动从输入、输出、执行活动的角色职责与能力要求、活动的操作方法及工具等方面进行了细化(如需求分析子流程、原始需求收集操作指导书、需求评审要素表等)，从而保障关键活动的需求明确、执行步骤明了、执行人的职责清晰、操作方法及工具清晰，避免由于需求不明、活动缺失或模糊而导致的返工。对经常发生返工的环节，设置了监控点，进行自检或互检，然后再进行子评审，子评审通过后提交到项目组，进行评审等，以加强预防与监控。club.mypm.net
开发过程中返工预防及监控项目管理者联盟
在开发工作的组织方面，我们建议A企业将原来的串行开发转变成并行开发。组建了有技术、营销、生产、采购及质量等部门人员参加的跨部门开发小组，让其他部门从一开始就介入到产品开发中来，把他们的“抱怨”作为需求提出来，一起形成产品的需求，然后再一起开发产品的“设计方案”(如系统、软件、硬件、结构、工艺等)。这样以来，既可以让相关部门准确的理解需求，又可以及早的暴露问题，并可以及时的得到修改，避免造成大量的返工。项目管理者联盟
在工具层面，我们针对经常出现的问题以及其原因，对产品开发过程中的关键活动，在流程及工作方法(流程、指导书)优化的基础上，进一步细化了流程活动的操作工具—活动模板，而且很多模板做到了样例化。比如，针对研发人员经常出现小“问题”，我们在相应的活动后面增加了自检或审核，并对自检及审核设计了自检与审核工具---CheckList(查捡表)。针对需求分析经常出现遗漏或需求模糊的问题，我们设计了需求分析模板以及需求评审模板—需求分析书、需求评审要素表等。 对这些常出现的问题，他们建立经验教训库，并借助IT工具对其进行动态的更新管理，以便使其能够既有效的避免员工犯同样的错误，而又不至于占用他们很多的时间，以提高经验教训库的实用性。项目管理者联盟
最后，为了确保这些改进措施得到落地执行与持续优化，A企业还接受了我们的建议，成立专门的流程管理部门，并将流程优化纳入到对各部门负责人及骨干的考核中。项目管理者联盟
改进措施实施三个月后，“小问题”开始明显减少。半年后，由于需求不明确或需求遗漏而造成的返工也开始明显减少，大家的跨部门协同意识也明显加强。“以前，只要是出了问题，大家首先说的都是为自己推脱责任，现在，大家首先说的则是怎么能把问题解决了，变化很大!”A企业的一位高层如是说。项目管理者联盟文章
其实，像A企业这样的企业还很多，我们希望通过这个案例，能对其他企业在减少产品开发过程的返工，提高过程质量与效率，提升研发管理水平有所启发与帮助。www.mypm.net 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
