1-OR管理体系ppt课件.ppt_第1页
1-OR管理体系ppt课件.ppt_第2页
1-OR管理体系ppt课件.ppt_第3页
1-OR管理体系ppt课件.ppt_第4页
1-OR管理体系ppt课件.ppt_第5页
已阅读5页,还剩105页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

OR管理培训,Internal,Page2,目录,需求和包需求介绍客户需求管理流程需求管理的基本阶段销售项目需求管理需求管理组织结构需求质量管理产品包需求分层模型需求管理电子流,Page3,需求的演变,客户如此描述需求,项目经理如此理解,分析员如此设计,程序员如此编码,商业顾问如此诠释,项目文档如此编写,安装程序如此简洁,客户投资如此巨大,技术支持如此肤浅,实际需求原来如此,需求管理常见问题,对产品需求的理解、选择和定义不足市场需求的收集和分析没有成为一个例行的活动市场需求仅侧重功能,忽视了服务、性能、可靠性等市场人员反映了许多需求却得不到及时响应,打击了需求提交的积极性市场人员反馈的需求模糊不清,也无法得到进一步的回复无法在大量的信息中发掘用户的潜在需求用户、部门之间、员工之间对需求的理解无法得到统一需求不断的变化、调整使得产品始终难以定型对需求的分析、验证缺乏系统的工具,大家抱着走一步看一步的态度在需求管理问题上,市场与研发扯皮,Page4,需求的定义,Page5,IEEE工程标准词汇表(1997年)中定义需求为:(1)用户解决问题或达到目标所需的条件或能力(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。”,IEEE的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求,其关键的问题是一定要编写需求文档。定义隐含了需求的三个影响因数:问题域(范围)、干系人、目标,Page6,什么是需求,需求问题解决方案,需求在产品开发工程中的变迁,Page7,产品包需求(OR)管理流程,需求实现及验证子流程,.,概念阶段,计划阶段,开发阶段,.,理解市场/组合分析/业务计划,书面标准事实标准,质量属性DFX,客户需要,市场需求,内部需求,标准约束,产品包需求,设计需求,系统构架,产品概念,设计规格,模块设计,功能需求非功能需求,客户needs&wants,各类需求的定义,Page8,什么是产品包需求,Page9,客户需要的不仅仅是软硬件而是一个完整的交付这也是OR(OfferingRequirement)名称的由来,产品包需求从另一个角度看就是客户为什么购买产品的理由!,保修建议,融资发货,企业形象,品牌,其它客户的评价,感知的质量,功能,性能包装,价格,产品包,售前售后售中,无形影响,可获得性,Page10,$APPEALS是描述产品包需求的推荐方法,它关注客户在购买竞争性产品时是如何做决定的,Page11,客户购买标准分析($APPEALS),Page12,目录,需求和包需求介绍客户需求管理流程需求管理的基本阶段销售项目需求管理需求管理组织结构需求质量管理产品包需求分层模型需求管理电子流,Page13,需求管理的目标,需求管理的目标:建立公司范围内统一、分层、协调一致的需求管理体系,支持持续获得成功牵引瞄准靶心需求,准确把握机会点使版本火车更加有序化,Page14,OR管理的目的和原则,需求管理流程的目标:统一需求管理,实现端到端的可视化主动收集需求,准确把握市场机会点逐步降低紧急需求比重,提高版本交付质量提高中长期需求比重,为市场管理提供需求来源需求管理流程的原则和要求:所有需求必须被录入电子流电子流需求必须得到及时处理鼓励全员参与,并对高价值需求进行奖励,Page15,OR在IPD体系中的定位,SP/BP,路标,Charter,OR需求管理,需求,长期需求,中期需求,产品包需求,紧急需求,技术,商业战略,历史数据,市场评估,市场细分,机会点分析,制定业务计划,整合业务计划,业务计划管理&绩效评估,计划,开发,验证,发布,生命周期,概念,IPD流程,MM市场管理,PCR,做正确的事,正确地做事,MM:MarketManagementOR:OfferingRequestSP:StrategyPlanningBP:BusinessPlanningPCR:PlanChangeRequest,需求管理的基本阶段,Page16,验证需求,需求跟踪,需求变更控制,需求纳入,业务计划/路标规划,产品开发项目任务书,产品开发项目组的需求说明书,开发需求,新方案,新产品/新版本,变更正在开发的产品,收集需求外部需求内部需求,外部来源客户行业分析竞争对手展览杂志,需求过滤,解释,过滤,检视,需求分析,分类,排序,证实,验证,实现,收集,分析,分发,业务计划,产品线,路标规划,项目任务书,在研产品,(变更),需求,分发,决策,内部来源公司管理层PDTPMT售后服务预研营销研发其它部门,需求管理的基本阶段_收集,目的收集子流程确定并生成可能的产品包需求,为后续的分析、筛选和执行做准备。需求可能来自各种内部和外部渠道。收集子流程应采用市场和客户驱动的方法,生成高价值的客户需求。输入通过子流程的活动,收集子流程收集来自各个渠道的输入:外部渠道客户(现有的和潜在的客户)、行业分析、竞争对手、展览会、期刊杂志内部渠道即公司的内部部门,例如市场、办事处;研发;技服;PDT;预研;营销等外部和内部渠道并不是互相独立的,来自外部渠道的需求由公司内部功能部门收集,并输入需求管理流程。之所以将这两个渠道区别开来,主要是为了明确外部渠道,支持使用更为面向市场和客户的方法来收集需求。,Page17,需求管理的基本阶段_收集,活动收集子流程不单只是一个步骤或活动,它包括了公司各组织日常进行的一系列活动。例如,市场管理流程中产品线级别的竞争分析便是一个需求收集的渠道。而PDT进行的产品线级别的竞争分析则是另一种收集需求的渠道。呼叫中心也是一个典型的收集渠道。输出活动输出可能的产品包需求。IT工具(电子流)的支撑在需求递交活动中起非常重要的作用。应在电子流中记录可能的需求,随后处理。,Page18,需求管理的基本阶段_收集,直接从客户收集需求:一般公司的大部分需求来自于内部渠道,必须通过外部渠道,尤其是客户这一渠道,提供公司未来大部分需求。收集可提前预测客户需求的长期需求:目前的大部分需求都是短期需求,实现这些需求的产品必须在6个月或更短的时间内交付,将来公司应该有一大部分需求是那些交付时间为一年或一年以上的长期需求,这样公司便可以及时开发出高质量产品,而不是在最后时刻匆匆交付低质量产品。,Page19,Page20,需求管理的基本阶段_收集,收集什么样的需求如何收集需求谁来收集需求,Page21,需求管理的基本阶段_收集,收集什么样的需求客户需要的不仅仅是软硬件而是一个完整的交付收集的需求不仅仅只考虑功能和性能方面还要考虑易用性、价格、可安装、可服务等方面的需求,售前售后售中,Page22,需求管理的基本阶段_收集,如何收集需求,展会/行业会议,客户简报,决策支持中心,研发高层交流,解决方案团队,标杆研究,试验局,用服高层交流,现场支持,服务热线,客户顾问委员会,客户满意度,推荐的主动需求收集方法,Page23,需求管理的基本阶段_收集,谁来收集需求Marketing销售人员技术服务人员研发人员UCD专家,OM专家,标准研究专家所有人都应该收集需求,Page24,需求收集的有关规定,所有的需求必须以统一的渠道提交需求类型多样、数量巨大,提交人分散汇集某个产品的所有需求是后续分析处理的基本要求毕竟我们需要的是一个五脏俱全的产品,而不是零件的拼凑混乱的提交渠道曾经造成一系列的问题,?,需求该提交给谁,Page25,客户需求收集过程,客户分析,收集策划,需求收集,市场细分客户/用户/干系人分析决策分析关注点分析,多种收集途径收集途径选择需求访谈设计调查问卷设计电子流设计,需求收集技巧全方位收集需求客户需求十问听的技巧从需要/问题出发一线需求收集及管理需求收集质量控制构建例行化收集机制,Page26,客户分析:客户类型划分,广义的“客户”(customer)包括“购买者”(buyer,狭义的客户)、“用户”或“最终用户”(userorenduser)、干系人(stateholder,如提议者、渠道、合作关系等)。客户(狭义的)与用户可能是同一个人也可能不是同一个人。,Page27,客户分析:选定初步的细分市场,“初步的细分市场”,描述,$价值和选择的理由,A.,B.,C.,D.,E.,F.,G.,H.,Page28,客户分析:确定不同类型的客户,Page29,客户分析:决策影响分析,Page30,客户分析:关注要点分析,Page31,客户需求的收集途径,市场活动,销售活动,用服活动,公开信息,商业伙伴,专业数据,一手信息,二手信息,需求库,需求整理分析,报告交流,竞争者信息,统计报告,新闻剪报,订阅的报告,专家顾问团,高层交流,原型测试,用户访谈,客户大会,销售、投标,现场支持,标杆研究,需求调研,高层交流,售后反馈,Page32,十种常用采集途径的特点,Page33,需求采集途径:行业会议/展会,【简介】行业会议和展会是该行业及相关行业的重要展示平台,汇集国内外各知名品牌的信息。行业会议一般会邀请行业内龙头企业做产品介绍,参加会议和展会有助于获得业界的认知,提高公司知名度,吸引新的客户。它提供了与客户交流一对一交流,除带来直接与间接的销售以外,更为公司提供了收集业界与竞争对手情报的机会。【产品与时间范围】会议更适用于了解技术的发展趋势,国外知名企业的动向,国家政策的引导方向,行业的具体要求等;展会能更直接的接触客户与潜在客户,大批量收集各类客户的各种浅层次需求,了解竞争对手推出的新产品,新技术;,Page34,需求收集要点:行业会议/展会,【需求收集要点】政策导向:政策导向往往可以带来很大片市场,通过挖掘政策,做行业解决方案;行业特点,有无特殊需求:不同的行业有其特殊要求,一个行业的成功代表一个市场的成功;竞争对手技术发展:行业会议中能够了解到目前竞争对手的状态,也是了解竞争对手技术实力的一个重要手段;会议通讯录:会议通讯录中一般会有与会企业的联系名录,并且是该行业内的知名企业,通过收起会议通讯录能够收集客户信息,并为后续需求的收集带来方便;老客户反映的问题:老客户反映的问题是重要问题,是实践中出现的问题,需尽快解决,为短期需求;新客户提出的问题及需求:新客户可能代表一个行业的需求,通过收集的分析新客户的问题及需求,能够分析出行业的需求,一般为短期及中期需求。【会议/展会后】会议/展会后,需求收集人应尽快整理需求,分析有效需求与无效需求,需求分析小组应组织专门会议及该次需求进行评审并提交。,Page35,需求采集途径:一线销售/投标,【简介】一线销售走在市场的第一线,能够接触到各种客户与竞争对手。通过产品推广获得客户的各种需求,通过投标可以了解到其他投标企业的技术特点。【产品与时间范围】直接获得客户需求,在销售项目/投标过程中系统了解当前产品与客户要求的差距;但日常销售获得的需求比较散乱、模糊,失真现象较多,投标竞争方式下难以对客户需求进行有效的引导。需求为短中期、当前版本,Page36,需求收集要点:一线销售/投标,【需求收集要点】一线销售收集客户短期需求通过客户对产品的不满分析客户内在的要求通过客户将公司产品与竞争对手产品的比较,收集客户的真实需求通过招投标的成功与失败,收集客户的真实需求【要求】一线销售人员每次出差报告中添加需求收集项,将需求收集作为日常工作的重要组成部分,需求采集途径中长期需求调研,目的系统、针对性地收集并分析某细分市场或某领域的需求,调研类型产品线/产品需求调研某细分市场(如区域市场)需求调研某领域(如可服务性)需求调研预研需求调研等优点能够全面、系统地收集中长期需求缺点成本高需要的技能较高,管理难度较高特点需求为中长期,当前版本、未来版本,Page37,应用$APPEALS方法进行需求访谈,Page38,识别客户群,识别决策单位,识别参与访谈的客户,制作访谈计划,准备(包括访谈公司内部人员),一对一访谈或群组访谈(对客户公司成员),分析数据,输出调研报告,与客户确认,需求录入电子流,交付件归档,内部评审,更新$appeals子要素并进行优先级排序,客户需求访谈要点(举例),Page39,包装:机柜设计、布线、噪音、外观、运输包装。机柜设计:标准机柜尺寸,承重,易拆卸,易扩容,抗震性。布线:布线整齐,符合客户布线规范和业界标准。噪音:低噪音。外观:人性化设计(拉手条,显示灯),与现有设备的协调性,机柜标志和标签指示明显。运输包装:包装箱环保,易打开(防受伤),保护机柜,包装箱上麦头标志易识别,易运输,易储存。,易用性:易于维护、兼容性、业务包、可扩展性、高集成度、统一网管、环境适性、安全性。易于维护:易于学习和理解,自动故障检测和恢复,远程维护,热插拔。兼容性:与现有设备兼容(前向/后向)。业务包:个性化解决方案,可编程。可扩展性:易于功能升级,在线扩容;配置灵活性。高集成度:系统集成度,单板端口密度大。统一网管:以相同的风格对所有部件进行管理的能力。系统具有分级管理权限;提供上一级开放的网管接口。环境适应性:对环境的温度,湿度,电压不稳,电磁干扰等的适应能力。安全性:防止获取未授权用户信息。,调查问卷设计,Page40,封闭式问卷是非法(是与否)多项选择(三个以上答案供选择)李克量表(在坚决同意和坚决不同意间选择)语义级差(在最好和最差之间选择)重要量表(在最重要和最不重要之间选择)开放式问卷自由格式(无任何引导、暗示或限制)填充式(在不完整的语句中填入有关内容)联想式(对于给定的词汇、情节等进行联想)图示式(给予一幅图画,增添内容或进行联想),Page41,需求收集技巧:从需要/问题出发理解客户需求,“话机听筒的电缆应该有10米长”(客户需求),Why?,而客户真正的意图是,“可以拿着电话在房间的任何一个地方通话”,10M,要真正理解客户的意图!,Page42,十种需求采集途径的总结,着眼全局,中间站点、可能路线,反复确认、广泛征询!,亡羊补牢,Page43,构造例行化需求收集机制,构建需求收集IT系统形成需求收集报告机制组建需求收集分析专业团队与员工任职资格、绩效挂钩控制神经末梢(出差、展览、招标等),需求管理的基本阶段_分析,目的收集子流程通过市场和客户驱动的方法生成高价值需求后,分析子流程的重点确保必要的要素,可以对其进行分析和解释转化。目的在于在以后的子流程中可以分发、执行并验证分析过的需求。输入分析子流程的输入来自收集子流程,主要的提供人同收集子流程。活动分析子流程包括以下主要活动:-筛选提交的需求,确保需求创建人记录了所需的分析要素-将需求分类(例如:功能性需求与非功能性需求,单个产品需求与跨产品、跨产品线需求等)-将需求按照优先级排序(例如:客户的优先级,公司的优先级)输出所提交的需求经过分析子流程的处理后,输出分析和解释转化后的需求,在分发子流程中分配给各利益相关人,由他们决定如何处理需求。,Page44,Page45,需求管理的基本阶段_分析,4个基本步骤:解释过滤分类排序,Page46,需求管理的基本阶段_分析,步骤1:解释各种源头来的需求,需要进一步提炼,以正式的语言描述,解释,Page47,需求描述的5原则,以产品必须做什么,而非应该怎样做像陈述原始数据那样详细表达需要使用肯定句而非否定句把需要表达成产品的属性避免使用必须和应该,Page48,客户陈述需求描述,Page49,需求管理的基本阶段_分析,步骤2:过滤收集到的信息,有可能不是需求,例如:一线向总部提出的要人、要货的请求商务、法律方面的请求等这些信息需要被过滤出来,Page50,需求管理的基本阶段_分析,步骤3:分类需求有很多种分类的维度,需要针对性的处理:,功能性能可靠性可维护性包装,跨产品线需求,短期中期长期,产品特性包需求设计需求设计规格,按时间,按类型,按层次,Page51,需求管理的基本阶段_分析,步骤4:排序在成本,时间受限的前提下,需要对需求进行取舍,常用的排序方法有:$APPEALS方法Delphi方法,成本,价值,Page52,需求管理的基本阶段_分析,步骤4:排序Delphi方法,目的分发子流程的目的在于派发已分析的需求到对应部门决策:该需求应当被接纳实施,还是拒绝,或推迟。输入分发子流程接受分析子流程分析过的需求作为它的输入。活动分发子流程决定了分发需求的最合理路径。可能有以下的分发路径:-市场管理流程-IPD流程-技术开发流程决策流程不在需求管理流程范围之内。例如,对于PDCP后分配给PDT的需求,PDT负责提交PCR。假设虽然需求会引起GA日期的变化,PDT仍要支持它,就需要提交产品线IPMT决定进行支持或拒绝。这一决策机制(标准和权力)不在需求管理流程的范围之内。输出分发子流程决策出需求应当被接纳实施,还是拒绝,或推迟。如果需求被接纳,就会确定后续流程的责任人。,Page53,需求管理的基本阶段_分发,Page54,需求管理的基本阶段_分发,根据需求的类型把需求分发到对应的下游环节,需求,PDT,RMT,1.当前产品的单产品需求,2.中长期需求,3.跨产品需求,协调跨产品需求,实现接纳的需求必要时发起PCR,纳入BP,路标,Charter(市场管理流程),Page55,需求分发的角色与职责,RMT/RAT确定进来的需求所应该去的路径(例如MM流程、IPD流程或技术平台开发流程)管理分发到PDT的单产品需求(如果存在)管理分发跨产品、跨产品线的需求参与跨产品线需求的解决方案,PDT决定需求是否接纳支持跨产品/跨产品族/跨产品线需求的解决方案对PDCP后的需求使用PCR流程将需求状态反馈给RMTTDT与PDT类似,但是只应用于技术/平台需求,技术/平台需求管理管理分发到TDT的技术平台需求(如果TDT已运行)协调技术平台需求进入平台路标规划(如果相关的话)协调公司内部部门(如市场、研发)决定是否接纳和优先级,PMT决定需求是否接纳对于接纳的需求纳入到业务计划、路标规划或PDT项目任务书支持跨产品线需求的解决方案将需求状态反馈给RMT,Page56,分发到市场管理(MM)流程,到达市场管理(MM)的需求必须由PMT处理。如果被接纳,可能分发到:年度业务计划产品路标规划PDT任务书当PMT创建业务计划、路标规划或charter时,他们需要使用需求管理流程作为他们的需求来源之一浏览市场需求同时考虑被接纳和被拒绝的需求,Page57,一、概述使命、愿景及目标绩效/机会差距二、市场及业务评估A了解市场/见解宏观环境分析行业及市场评估竞争对手分析产品包分析客户分析B业务设计与支持原理客户选择细分与组合分析价值陈述总结活动范围获取价值/价值链战略控制增长管理,三、业务计划A业务计划要素产品包价格/条款销售渠道集成营销宣传技术支援订单履行B绩效/机会差距C建立组织的能力关键任务与流程正式的组织机构人力、技能及文化四、绩效评估A财务评估B风险分析总结整体风险评估风险管理计划,五、运作子计划A集成营销宣传子计划B技术支持子计划C分销渠道管理子计划,纳入到年度业务计划,Page58,典型的路标规划的内容包括以下部分:V版本启动时间、生命周期及主要特性;R版本启动时间、上市时间及主要特性;每个V版本及R版本的技术需求计划;每个V版本及R版本的人力资源需求计划;每个V版本及R版本的投入产出分析。,产品线1,平台产品11,平台产品12,平台产品13,产品线,平台产品(主版本Version),产品(子版本Release),纳入到产品路标规划,Page59,案例分析,某公司软件产品管理部正在制定网络数据管理平台未来的版本路标规划。需求数据库中显示,在对客户进行调查时,客户提出需要“数据加密上传功能”,产品经理李明在分析时建议在下一版本增加这项功能。在路标规划讨论时,项目经理王磊提出:“客户上网带宽小,文件又大,传输等待时间长已经打击客户使用平台的积极性了,如果再对数据进行加密上传,势必进一步降低传输速度。这样雪上加霜,客户满意度肯定会降低。”销售主管赵亮:“客户有一些机密文件,如合同、财务报告等,如果被复制或修改,会造成巨大损失。他们强烈要求高度安全的数据传输方式。”产品管理部经理陈东伟打断争论:“问题看起来是在功能方面,实际上是客户背景资料不清。请问,有多少客户在工作中主要上传工程文档和图纸,多少客户主要上传机密文件?”调研专员张兵答道:“我们已经了解清楚,主要是商务部和财务部需要上传机密文件。虽然只有两个部门,但他们都是重要部门,对是否采用我们的系统有很大的发言权。”,Page60,案例分析(续),看来客户确实有加密上传文件的要求。问题是如果在下一版本增加这项特性,会明显影响数据传输速度,而且会增加较多的开发时间。陈东伟犯愁了,他问项目经理王磊:“以你过去对客户业务的了解,他们过去是如何传递加密文件的?”王磊:“合同一般是书面存档管理,即使有电子版本,实际流转时也是用打印件,而且是不允许复制的。财务报表只有几位高层领导才可以查阅。”陈东伟想了想,似乎有了决定。您认为他应该如何决策?,Page61,正式启动项目指导PDT初步市场情况的总结和产品定位对项目提出高层要求和主要指标任命PDT成员,PDT任务书由PMT编制,主要作用是:,编制PDT任务书的同时,一般需要根据分发的需求包编制初步的产品包需求列表,与PDT任务书一道作为IPD开发流程的输入。,纳入到项目任务书(Charter),Page62,分发到正在开发的项目,需求可能在产品开发的任何阶段产生,但是OR分发子流程的关注焦点是在前期传递到概念阶段。在PDCP前,各领域来的需求通过端到端产品包需求模板汇集为未来产品包需求。PDT必须确保他们有关于该产品需求的完整清单他们必须(持续地)依据需求管理电子流更新此清单,确保清单中包含有最近录入电子流的需求他们必须检查作为基线的需求是否也被录入了需求管理工作流这些变更必须进行,即使变更控制尚未引入在PDCP后,新的/改变的需求必须通过PCR流程。从需求到PCR的关联会安排变更转化为正确需求的路径。通过这些关联确保更新相关需求和产品。,Page63,将需求状态反馈给RMT,需求状态需求处理结果预期的需求满足日期搁置、拒绝的原因修改产品包需求需求PCR,需求管理的基本阶段_实现(执行),目的执行子流程的目的是将接受的需求纳入到产品开发中,给予实现。需求管理流程的主要贡献是使得实现过程更容易,依赖于:-提升接收到的需求质量-保证需求在开发过程中流动时,可以被向前,否则向后进行追溯输入分发子流程所分发的需求是执行子流程的重要输入。活动执行子流程的活动遵循IPD流程的开发活动。主要活动有:-修正、执行开发计划,以适应新需求-对项目文档,要遵从需求变更控制的规则输出执行子流程的输出是在产品中实现所分配的需求,供验证。,Page64,Page65,需求管理的基本阶段_实现,从客户的需求到最终研发完成,需求会不断的转化和分解例子:乘客对飞机的需求很简单“更快”“更安全”“更便宜”,Page66,需求管理的基本阶段_实现,航空公司的需求会复杂的多飞行控制起飞巡航降落紧急处理航程,油耗,速度,噪音,维修,Page67,需求管理的基本阶段_实现,飞机制造厂的需求则极为复杂飞机总成的需求(数千条)发动机的需求(近千条)通讯系统的需求(近千条)控制系统的需求(近千条),Page68,产品包需求实现与系统工程,产品包需求(OR)管理流程,.,概念阶段,计划阶段,开发阶段,IPD开发流程,.,客户needs&wants,理解市场/组合分析/业务计划,MM,书面标准事实标准,质量属性DFX,客户需要,市场需求,内部需求,标准约束,产品包需求,设计需求,系统构架,产品概念,设计规格,模块设计,功能需求非功能需求,系统工程,Page69,产品包需求的划分,环保需求,UCD需求,安全性需求,可靠性需求,标准约束,可维护需求,性能需求,其他需求,非功能需求(属性需求),内部需求包括:可测试性、可制造性、可维护性需求、可用性需求等。这些需求需要通过不断积累,建立数据库,形成基线需求,在Charter编制或产品开发流程概念阶段选择确定。,分为功能需求、非功能需求,分为市场需求、内部需求,Page70,产品包需求的样例,产品包需求A:提供业务端口报文的统计功能某网络安全设备,产品包需求C:主机业务软件要实现系统不间断补丁功能某大型电信网络设备,产品包需求D:提供软件调试,支持debugmonitor和DSU调试模式某RSIC嵌入式处理器芯片,产品包需求B:减轻臂架自重,载荷能力提高20%某机械设备,产品包需求E:提供测试报告的自动生成与保存某性能测试工具,Page71,高质量产品包需求的标准,产品包需求,可行性,明确性,一致性,可验证性,完整性,有“杀手锏”,Page72,做法1:主要由PMT/RMT负责PMT/RMT在编制Charter时进行产品包需求分析、规整,输出初始的产品包需求,关注客户的价值需求;Charter后,由PDT(SE、MKPDT等)细化并补充其它需求、零散需求后,并经RMT评审后,输出完整的产品包需求。,做法2:主要由PDT(SE、MKPDT等)负责PMT/RMT在编制Charter时主要关注高层次产品包需求(问题、特性),输出包特性列表;Charter后,由PDT(SE、MKPDT等)进行产品包需求分析,经RMT评审后,输出完整的产品包需求。,谁来完成产品包需求定义?,Page73,举例:项目任务书开发流程(CDP),做法1:编制Charter时的需求分析,Page74,CDP和IPD之间的工作界面,Charter开发团队向PDT传递的产品包需求要分层描述,必须包括客户问题、系统特性、系统需求及其各层之间的跟踪关系;Charter开发团队依据产品包需求架构,重点关注与投资决策相关的关键价值需求,在charter汇报时交付初始产品包需求;PDT对Charter开发团队移交的初始产品包需求,依据产品包需求架构对其他未纳入的需求进行完善,并对产品包需求基线化;Charter开发团队与PDT,以及各级组织(如Marketing和研发)应遵循产品包需求架构进行需求管理职责的分工与协同。,Page75,做法2:PDT完成产品包需求分析,包特性(针对外部客户)PMT/需求专家负责,测试需求测试专家负责,制造需求制造专家负责,服务需求服务专家负责,产品包需求SE、LPDT负责,整合、折衷,Charter,Charter包特性列表(举例),Page76,形成产品包需求列表或说明书,需求编号领域需求标题需求描述必须的功能优先级改进目标衡量需求带来的利益.,产品包需求.,Page77,需求管理的基本阶段_实现,包需求,软硬件规格,设计规格,软硬件规格,软硬件规格,设计规格,设计需求,转化,转化,SE主导,MKPDT等参与,RMT评审,SE指导,各专业组及工程师负责,端到端的需求跟踪和变更管理成为必须,采用系统工程方法将产品包需求分解为设计需求、设计规格,需求管理的基本阶段_验证,目的验证子流程重点关注于实现需求后的需求验证,是对产品决定性的验证和确认。此外,该子流程生成了吸取的经验教训,在需求管理流程(收集子流程)中收集,将来传递给PDT。输入所执行的需求是验证子流程的输入。活动主要的活动有需求验证和确认。作为开发流程的一部分,-通过系统测试进行需求验证-通过用户接受性测试进行需求确认输出验证子流程的输出是验证/确认了所执行的需求。,Page78,需求管理的基本阶段_验证,备注虽然验证子流程是端到端需求管理流程中的最后一个子流程,但它并不是一项单独的活动。它实际上是IPD流程所管理的开发活动的一部分。需要重申的是需求验证活动可以在开发周期内的任何时间进行。实际上,提早验证/确认需求是一种可靠的做法,可以准确地了解需求。新成立的PDT可以在IPD的概念/计划阶段同目标对象(客户)召开需求验证会议。然而,这需要平衡所需要的努力/时间与追求的潜在价值间的关系。,Page79,Page80,需求管理的基本阶段_验证,并不是一个严格意义上的阶段,而是贯穿整个需求演化、分解、实现的一系列质量保证活动,包括:评审、测试等,客户所需,原始需求,包需求,设计需求,设计规格,测试,GA,Page81,RAT,需求管理的基本阶段_验证,RAT代表客户参与各TR点评审,TR1,TR2,TR3,TR4,TR4A,TR5,TR6,Page82,端到端需求变更必须同步,如何保证变更链的同步?,总部RAT,客户:想法变了,一线:项目取消,一线:环境有变,市场一线,总部:策略调整,研发:技术困难,研发:人力不足,公司总部,Page83,目录,需求和包需求介绍客户需求管理流程需求管理的基本阶段销售项目需求管理需求管理组织结构需求质量管理客户$APPEALS设计产品包需求分层模型需求管理电子流,Page84,销售项目需求管理,随着业务拓展的加快,因需求处理不当导致了很多严重的问题案例:,合同取消,市场拓展,草率承诺曲解客户需求未深入分析可行性需求传递遗漏、失真对待合同文本不严肃,满意度下降,交付困难,赔款,Page85,销售项目需求管理,为何会出现这些问题?,最终导致上述各种问题!,投标人员不具备专业的需求分析答复能力,Page86,销售项目需求管理的总体原则,需求承诺的接纳处理责任主体是各区域RMT,今后各PDT无权接受来自公司各行业部、国际国内销售体系(包括销售部及各办事处)、技术服务体系(包括公司及各办事处技术服务部)等各部门直接反馈的需求。所有需求承诺必须录入到客户需求/承诺电子流,以规范的方式传递给RMT,邮件、电话、传真等方式只可以作为必要的沟通手段。所有需求的对外答复必须以面向市场发布的产品功能清单(也包括市场技术指导书、业务签单附件等)为基础,对于功能清单未包括的需求,必须经过RMT给出答复口径,才能对外答复和承诺。凡未经RMT批准的答复和承诺,各产品线不承担提供的责任。发生任何客户投诉时,由办事处自行负责。,Page87,Page88,销售项目需求管理,RMT/RAT,PDT,RMT/RAT,各CCM,产品营销部研发总部其它代表,产品营销部行业部,Page89,重大销售项目需求管理,方法:RAT初选RMT评审以分析报告形式提交,Page90,需求争议解决机制,RMT/RAT团队达成一致,PMT审核,IPMT决策,IRB决策,日常需求处理,重大需求决策,Page91,需求快速决策通道,长期议而不决的需求,Page92,目录,需求和包需求介绍客户需求管理流程需求管理的基本阶段销售项目需求管理需求管理组织结构需求质量管理客户$APPEALS设计产品包需求分层模型需求管理电子流,Page93,需求管理涉及的角色,按需求的处理顺序,涉及的角色有:,收集,分析,分发,实现,验证,Marketing销售人员技术服务研发UCD专家OM专家法律法规专家标准化研究专家其余员工CCM,RMT/RAT,IRBIPMTPMTRMT/RAT,PDT,需求收集者需求分析者实现者,Page94,需求管理的组织结构,PL-PMT,PL-RMT,CCM,RAT,RAT,CCM,CCM,Page95,目录,需求和包需求介绍客户需求管理流程需求管理的基本阶段销售项目需求管理需求管理组织结构需求质量管理产品包需求分层模型需求管理电子流,Page96,需求质量管理,需求确认需求提交质量标准需求答复质量标准,Page97,需求质量管理-需求确认,需求确认做正确的事与客户交流我司的解决方案,确保双方理解无遗漏,无偏差不是所有的需求都需要确认PDCP前至少要做一次需求确认,Page98,需求质量管理-需求确认执行过程,RMT/RAT评审哪些需求需要确认,市场代

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论