1-OR管理体系课程教学课件.pptVIP

Page 2 * * * * 解释后的需求，应当达到可度量，可验证的程度 客户说”我希望有一个加速更快的车“，如果在提交时没有说清楚，在解释时就必须明确客户”需要一辆0～100KM加速时间为6秒的车“ * 之所以把过滤放到解释之后是要先判断一下需求到底是什么意思 * 需求内容复杂，类型众多，需要针对性的处理 可以就图中的分类简单介绍一下 * 图示是一个价值－成本权衡的例子，可以简单讲解一下，说明排序的作用：追求投入产出的最大化 * 简单的说：就是“分项打分” 综合考虑各种因素，给出需求处理的优先级 * 需要注意的是，需求分发之后，仍然在OR的监控范围之内，直至其最终交付 * * * * 需求的演化，是实现过程中所有管理活动（跟踪，变更）的触发源。 在演化的过程中，会有以下几个方面的变化 逐步从对问题的描述转化到对解决方案的描述（转化） 会补充很多用户不涉及的衍生需求（例如用户说我要一栋房子，用户不需要提出先打地基，这是修房子的人考虑的问题） 需求的数量会呈几何级数增长 同时在不同层次、类型的需求之间发展出复杂的关联关系。 这些变化直接导致了需求跟踪和变更管理的产生。 * * * * * 我们需要知道： 包需求 如何被设计需求满足 设计需求 如何被分解为设计规格 设计规格 如何被实现为软硬件需求 要达到这个目的，就需要对各层次需求之间做跟踪 通过需求跟踪，我们可以： 知道我们确实满足了我们的目标 精确的跟踪研发的进展 更好的平衡成本和收益 此外，当演化出这样的一张复杂网络之后，要保证各个层面的需求都能协调一致的变更也是一件复杂而困难的事情，需要在需求跟踪的基础上进行变更的控制，使我们能够 准确评估变更影响的范围 保证整个跟踪链的一致性 * 此胶片在IPD考试中出现过，重点了解学员的意见？ 需求在传递过程中是难免失真的，验证和确认就是减小失真的两种基本手段 二者的区别在于： 验证是公司内部的活动，包括各种评审、测试等。 而确认是我司与客户一起进行的外部活动。同时，确认还需要以我司的实现方案（可以是原型）为依托与客户进行的沟通，不是空对空的交流。 * 可以看作是需求跟踪，验证+确认的混合体。 * 此胶片在IPD考试中出现过，主要了解学员的意见？ 因为变更不同步，曾经导致严重的问题，包括： 研发中途取消需求，而一线还不知情 一线项目取消，而没有及时知会总部，导致资源浪费 变更必须站在端到端的角度来看。PCR只是某个版本在PDCP之后的变更控制方法。 PL-RMT/RAT受理所有的变更，这个就像PL-RMT/RAT受理所有需求的提交一样。 变更决策原则与需求决策的相同，也必须相同 * * “友好的”界面（对模糊的需求匆匆承诺） 客户标书中要求我司设备提供“友好的”用户界面，我司在未与客户确认“友好的”内涵的前提下，匆匆答复全部满足。首次交付产品后，客户认为没有满足要求，初次沟通后历时3个月完成了修改，但客户测试后认为仍未达到要求。我司于是派大批专家到客户现场进行沟通和界面原型设计，又经过3个月，才开发出符合客户要求的界面原型，全部开发完成需要1年时间。客户无法接受，后来该项目以我司赔偿结束合同。 1000条/秒短信（乱承诺） 某客户交付时提出我司设备性能与标书不符。只有400条/秒短信的能力。我司坚持当初谈判时就是400条/秒，可是拿出标书一看，上面清清楚楚写着1000条/秒。 完全支持XXX协议（超前承诺） 某合同“完全支持XXX协议”，该协议目前还未成熟，范围很广，业界也没有哪个供应商能够百分之百支持该协议。我司的“完全满足”使我们彻底的陷入了被动，客户要求什么我们就得实现什么，而且还是无偿的。 主动承诺的“优惠卡”功能（草率处理承诺） 某项目，我司承诺了“优惠卡”的功能。该功能客户并没有提出，甚至还不理解该功能是什么意思，是我司主动附送的功能。等到交付时发现研发根本就没有开发没有该功能。虽然我们再三解释该功能其实客户用不上，但客户按合同办事，既然承诺了，就应该实现。 GPRS上网（未理解潜在需求，匆匆承诺） 客户提出GPRS上网，我司以为是通过手机WAP2.0上网，答复“完全满足”，而客户真实的需求是通过数据卡上网。 * 答标人员往往不具备专业的分析答复能力 需求的分析需要综合考虑战略、战术层面的多方面因素，需要专业的分析技能和对相关领域的深厚积累，同时理解问题和解决方案。不应该由一线的投标人员来决定某个需求是否接纳 需求没有录入电子流 以电话、邮件等形式沟通需求，遗漏、失真严重 一线人员并不清楚我司设备到底有哪些特性 之前并没有完善的渠道知会一线人员我司的产品动态，这是MPP解决的问题，甚至客户已经在Google上搜索到我司有某特性，而我司的一线人员还不知情 * 片区RMT成员：主管：片区Marketin