IPD研发流程推行中遇到的问题解决措施(下编)
说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。
IPD研发流程推行中遇到的问题解决措施（下编）.doc胡红卫 G公司是一家研发和制造金融终端产品的中小型科技企业，公司销售额3个亿左右，研发人员60多人。通过参加汉捷咨询举办的系列培训，G公司认为IPD是解决当前产品及研发问题的系统解决方案，并于2009年初开始逐步导入IPD体系，但在导入过程中遇到了一系列的问题。G公司相关负责人向汉捷咨询反馈了相关问题，汉捷顾问逐一作了解答。 一、基础常识问题（见上篇） 二、IPD实施过程中与领导层相关的问题（见上篇） 三、与研发团队相关的问题： Q13：搞矩阵式的组织架构，是不是意味着员工有两个甚至两个以上的领导？那么多头指挥的问题是怎么解决的？矩阵式管理模式后部门和项目组之间的配合是怎么做的？部门的价值和地位有什么变化？部门和项目组的权、责、利是怎么划分的？ A13：矩阵结构下，除了部门领导外，员工通常还有一个或一个以上的项目领导。其实，多头指挥的问题是可以解决的。员工会扮演几个角色，不同的角色分配不同的时间，分别向不同的主管负责，这与我们在日常生活中需要扮演不同角色的道理是一样的。各部门关注资源的建设，为项目组提供合格的资源，项目组则关注带领团队去实现项目目标。 过去，各部门都在插手项目，项目管不好，部门资源建设受到忽略，转变为矩阵结构后，部门通过有效支撑项目和不断提升资源能力，更好地发挥了自己的作用和体现了自己的价值。所以，部门经理不必担心强化了项目组的责权后会削弱了自己的地位，其实矩阵模式是同时提升了项目团队和部门的价值和地位。 Q14：IPD强调跨部门的开发团队需要研发之外的部门参与．例如采购部、财务部，但问题是这些部门往往本来就没几个人，而开发项目又很多(像我们公司目前同时开发的项目就超过20个)，那这些部门应该怎么来应对呢？还有一点是这些部门说话算数的可能只 有负责人，如果他们不参加PDT而随便派个代表的话可能和不派人参加没有区别，这个问题该怎么来解决呢? A14：对于采购、财务等领域来说，在PDT中的工作量相对较小，这时候一个人可以兼多个PDT的代表。部门负责人需要对本领域的PDT代表充分授权，使他/她在项目内能够完全代表本专业领域做决策。而且PDT和部门负责人都是直接接受IPMT的领导的，IPMT需要通过承诺的方式确保各部门向PDT提供合格的资源并有力支持项目，在汉捷咨询过的案例中，必要时也可以让各部门负责人正式承诺提供资源并授权。 Q15：结构化流程的特点是什么？有一种说法是要防止流程的过度结构化，那我们怎么来衡量流程是否过度结构化呢? A15：流程结构化首先是建立一个合理的结构层次来划分和定义流程，比如流程层次可以划分为流程框架、主流程、子流程、指导书/模板，活动层次可以划分为阶段、步骤、任务、活动，其实需要对流程中的每一项活动进行规范的定义，包括活动的输入、输出、操作步骤、约束条件、衡量标准等。 产品开发流程需要在非结构化和过度结构化之间取得平衡，如果出现了审批环节太多、流程过于繁琐、度量指标太多、规范规定得太死太细、过多的约束等现象，影响效率又不利于质量或者缺乏创新空间而影响客户需求满足，就说明流程有过度结构化的问题，需要改进。 Q16：IPD强调端到端的流程，提倡从客户中来到客户中去，那么IPD是靠什么来实现这一点的呢？因为很多人甚至很多组织都不自觉的会“代替”客户来定需求或想当然地定义客户的需求。 A16：端到端地满足客户需求需要从意识、流程、团队、人员、技能等多方面综合保障。就IPD开发流程来说，从Charter到GA都是以客户需求为主线的，是业务实现的流程而不仅是技术实现的流程，而且流程执行团队（PDT）需要直接对市场成功负责。 “代替”客户来定需求或想当然地定义客户的需求是一种思维定式，心理学称之为“投射效应”。克服这一问题，除了牢固树立“以客户为中心”、“以客户需求为导向”的理念和意识外，还需要从流程、团队、评审等方面来解决。 Q17：我们注意到IPD里面非常注重团队的概念，但在实践中大家都更倾向于把责任界定的更清晰。例如我们经常听到的是“我们硬件做好了，软件在拖进度，我也没办法”“硬件没人配合我也没办法”“这肯定是XX方面的问题”。IPD对责任界定和团队配合是如何来协调的呢？特别是面对问题的时候，需要追究责任的时候该如何处理? A17：工作中出现问题后推责任，这是自我保护意识和缺乏整体责任意识在作怪。我们需要从岗位分工的角度把岗位工作内容划分清晰，更需要从流程或团队的角度界定整体责任，形成以流程结果责任或团队整体责任为导向的意识。IPD强调集成的理念，其中也包括各部门、流程/团队中的各角色不应只是关注局部，而应与相关部门、相关角色紧密配合，共同对结果负责。 出现问题后大家应关注如何解决问题，尽快采取解决方案。如果要追究责任的话，相关环节和相关岗位都有责任，可以进一步分析是哪里出了差错，分清主要责任、次要责任，该处罚的就处罚，以增强大家的责任心。 Q18：IPD强调重用，但我们在实践中往往遇到的问题是工程师们连基本的设计文档都不愿意写，他们经常说的一句话是“你要进度还是要文档？如果要写文档那么你就把项目延期!”面对这种情况应该如何处理? A18：汉捷咨询认为：文档是产品的一部分，没有完成文档也就是产品开发没有完成，需要树立这样的观念，在考核上也要与文档是否完成挂钩。有些工程师把文档和进度对立起来，这是一种片面强调短期进度的观点。如果由于缺乏文档资料，导致后面的制造、销售、服务、维护工作无法正常运行，影响产品的市场效果，也使知识资产流失，虽然产品好象已经做出来的，但这种局部的进度宁愿不要，因为它最终会影响整体的成功。 Q19：全流程的产品开发，讲究的是配合与协调，对于看重成就感的工程师来说，如何满足他们成就感的需求？全流程的开发消除的是对个人英雄的依赖，这样是否会让工程师觉得自己对组织的重要性不高，从而荣誉感不强？ A19：对于工程师来说，成就感来自于经过苦思冥想后终于解决了问题、某方面的创新改进，来自于开发项目高效推进，来自于自身能力的提升，更来自于产品赢得了竞争和客户认可，取得了良好的市场效果，全流程、团队协同的产品开发模式正是实现这些的根本保证。在汉捷咨询遇到的很多企业研发过程中，各部门各自为政，相互之间都倾向于单打独斗，开发进度不断延误，更要命的大家辛辛苦苦开发出来的产品没有什么客户要，严重挫伤研发人员的成就感和积极性。 在团队化协同开发模式下，不再突出个人英雄，但对于具备突出能力的工程师和管理者依然是至关重要的，不仅在评价和激励上将给予充分的体现，而且给他们提供更好的机会和机制去带领别人成功，这应该是他们获得的更大的成就感！ Q20：华为、思科实施IPD的模式是不是完全适合我们，哪些是我们这类公司可以借鉴 本文来源：https://www.wddqw.com/doc/f87b3ce689eb172ded63b776.html