产品规划十步法教学提纲.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,从概念到产品需求分析过程,Something about grammar&literature,产品经理社区,开始的话,2,引子：不仅仅纯技术,人文比科技重要！,方法比技能重要！,初做者,有经验者,监督者,专家,管理者,高级专家,领导者,资深专家,3,学习态度？,一天，三年甲班的杨过忘了交作业，导师郭靖问他：“为什么没交作业？”,杨过答曰：“作业为什么要交？交了不一定是自己写的；,写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼）,会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响）,考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶）,过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变）,毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见）,找得到工作又不一定保得住工作；（萧峰夺门而出）,？”,只见现场沉默三秒之后，众人联手围殴杨过,4,先从语法课讲起,用户是一个或者多个名词；,产品是名词，一般由很多个名词组成；,产品设计过程,功能需求就是找出“动宾短语”的集合,性能需求就是找出“形容词”的集合,5,订书机为例（仅供参考）,产品,订书机,:n.,一种装订文件的文具,订书机包括：,杠杆结构：,n.,进钉结构；,n.,压钉结构；,n.,钉书钉,(,消耗品,):n.,用户,用户：,n.,使用订书机的人，应大于,3,周岁；且有手或者类似可以发出至少,1kg,力量的人。最常用,(80%,以上,),为女性,(21-40),。,需求,功能需求,装订文件；,Load,钉书钉；,Unload,钉书钉；,性能需求,外观、颜色、省力、材质,.,6,产品设计过程,定义好,用户,定义好,产品,先分析,功能需求,再分析,性能需求,80/20,的误区：,产品日趋同质化，,公司之间的差别，,市场竞争的成败，,往往是由性能决定,7,互联网本质论,计算机为什么叫计算机？,互联网其实是一个大数据库,大部分应用都是数据库应用,Search?,B2B,、,B2C,、,C2C?,Gaming?Avatar,？,Blog?,小部分应用是即时的存储转发类,IM,VoIP,复习数据库的知识,!,8,课程概述,9,课程内容,Use Case,分析方法,找寻用户,定义产品,发掘功能需求,性能需求的“套路”,需求文档的撰写,产品经理常用“技法”,工作组织方法,常用图表和绘图方法,10,需求分析与人文,需求分析是一个工业化的写作过程,80,的套路,20,的创意,好的语文水平：,有利于抓住关键词汇,有利于培养数字敏感,有利于增强形容能力,有利于组织文档结构,有利于提高沟通能力,读书吧！,写博客吧！,11,Use Case,分析法,12,USE-CASE,的历史,1967,年,Jacobson,在爱立信工作的时候开始使用这种思想,这种想法最早应用于大型交换机系统的需求获取,1971,年完成了这种方法的最初原型,1985,年推出了改进版，并发布了面向对象的,OOSE,方法,大部分面向对象技术都采用这种需求方法，,UML,建模语言也已将它包容进去,它还被广泛的应用于工业领域,13,需求获取的前提,用户,必须告诉你他想要什么,你必须完整地了解,用户,的业务,你必须知道与系统有关的,任何人和任何东西,如果,用户,不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的,从专家那里了解用户业务的原理和规则,你是去了解要做什么而不是怎么做,14,首先，您需要把系统看成黑盒,一开始就深入细节的产品经理，忙乱而又没有绩效,往往陷入细节的泥坑，甚至是技术细节，甚至,UI,细节,被层出不穷的需求点和例外处理困扰,控制不住满脑袋乱冒的,ideas,请相信！,系统内部无论多么复杂,他总是可以被“使用说明书”说清楚,15,Actor,16,需求分析的第一个问题,谁是这个产品的用户？,或者，谁是这个产品系统中的,角色,？,17,什么是角色,(Actor),与系统发生交互作用的、系统之外的任何东西都是角色,可以是人,也可以是机器,角色不等同于使用者,角色存在于,系统外部,角色不是活动的准确描述,使用者是行驶某个角色职责的系统的使用人员,如小王是个采购员,我是角色,Actor,！,18,角色（续）,每个,Actor,都通过不同的方式使用系统，除非他们是相同的,Actor,Actor,使用系统的每一种方式就是一个,Use Case,群普通用户,群管理员,群股东,群创建者,群股东,19,角色分类,主动角色：,Use Case,的动作序列是由他先发起的，通常系统返回最后结果,主叫方，采购人员，票据录入员等,被动角色：系统通过调用角色来完成,Use Case,的动作序列（或其中的某一个动作）,不是初始动作的发起者,当系统需要它们帮助的时候,最终是为了满足主动角色的需要,通常是机器或其他系统,Actor,Use Case1,Use Case2,Actor,Actor,20,Script,21,脚本,Script,脚本是一个角色与系统之间的一组交互作用,通常具有详细的真实数据及实际的期望输出值,一个应用系统可能具有成千上万个脚本,即使同一件事，所得到的脚本可能也会有细微的区别,脚本是描绘,Use Case,的重要的背景信息,22,脚本示例,1,：小王输入他的账号,#413597,2,：小王输入他的密码,#119823,3,：小王查询,98.7.1,至,98.12.31,日之间的平均余额,4,：系统显示余额,1,：小张输入他的账号,#413343,2,：小张输入他的密码,#646788,3,：小张查询,98.3.1,至,98.5.31,日之间的平均余额,4,：系统显示余额,1,：小李输入她的账号,#346780,2,：小李输入她的密码,#435645,3,：小李查询,98.7.1,至,98.12.31,日之间的平均余额,4,：系统显示余额,23,脚本与,Use Case,一个,Use Case,代表一组潜在的脚本,通过研究一组相似的脚本，可以得到它们内在的逻辑,相似的脚本通常遵循相似的模式工作，并提供相似类型的结果,一个,Use Case,通常关注某一个目标,例如：查询存折余额,Use Case,24,Use Case,25,转让群,通过,Use Case,描述系统功能需求,一个系统具有无限个潜在的脚本,但一个系统可以被有限的,Use Case,完整说明,系统的每一个,Use Case,都必须列举，否则系统将会遗漏功能,创建群,解散群,加入群,赞助群,邀请加入群,群内发言,授权群管理,26,Use Case,描述系统提供的交互功能,一个,Use Case,可以被其他的,Use Case,调用,Use Case,可以组合完成某一项更大的功能,Use Case,说明系统需要提供什么而不是怎么提供,用户并不关心你如何给他们提供所需要的功能,Use Case,一般是用“动宾”短语命名,创建群,解散群,加入群,赞助群,邀请加入群,群内发言,授权群管理,27,Use Case,Use Case,不是分析设计文档,虽然它们支持后续的分析设计工作,Use Case,不是操作脚本,它不是用户使用系统时实际操作的具体步骤的记录,虽然它可能是通过操作脚本得来的,28,Use Case,是很好的测试单元,Use Case,清晰地描述了系统的功能界面,测试人员可以在开发初期制定测试计划,每一个,Use Case,都严格地说明了系统的某一项功能,它的输入,它的输出,期间的交互作用,Use Case,是黑盒测试的基准,29,Use Case,的阐述,应该包含,Use Case,的所有重要细节,应该包括角色与系统交互的关键步骤，可以使用顺序图（,Sequence Diagram,）,要表述有关角色的信息,要分清哪些是角色所具有的职能、哪些是系统所应提供的,要列清使用这些功能是所应满足的前提条件,如果某些功能具有质量上的要求（如性能），也要列出来,创建群,Dddddddddddd,Dddddxxafsdfads,Dddddddddddd,Ddddfcadsfasd,ddddccdasdwe,30,Use Case,：标记方法简单,Actor,名称,Use Case,名称,31,Use Case,：主动角色,经纪人,下单,投资人,报价审查,货币存取,经纪管理系统,32,Use Case,：被动角色,经纪人,下单,投资人,报价审查,货币存取,经纪管理系统,银证转账系统,33,画,Use Case,图规则,主动角色画在图的左边,被动角色画在图的右边,每个,Use Case,必须为用户提供确切的功能,Use Case,名称必须写在椭圆里面,保持图面整洁,每一张图里不能有太多的,Use Case,为每一个,Use Case,编号便于检索,为,Use Case,建立目录（编号和名称）便于管理,34,Use Case,高级概念,35,Use Case,高级概念,通过分析,Use Case,图，分析人员可以找出不同的业务过程之间的共性,扩展、包含、派生、使用等关系,通过这些关系可以降低系统的复杂度,为重用提供了条件,将共性提出来，可以帮助我们发现重复的过程,二次开发应该关注的地方,36,Actor,的继承,类似于,Use Case,的扩展，角色之间可以继承,其他银行不仅具有储户的所有功能，还有其他的功能,37,Actor,继承的好处,在不丢失信息的前提下，简化了,Use Case,图,继承说明了角色间的层次关系,派生者继承了父角色的所有能力,父角色不知道派生者,38,扩展关系：,extend,扩展关系通常用来表示某一个,Use Case,的可选择部分,扩展关系允许分析人员在没有改变基,Use Case,的情况下增加或修改基,Use Case,的功能,复杂的可替代途径应该使用扩展关系把它们分成多个,Use Case,也可以这样看扩展关系：,在基,Use Case,上插入功能，而基,Use Case,本身不知道这个扩展,39,扩展关系,(extend),示图,40,使用关系,如果,Use Case A,包含,Use Case B,，表示在执行,Use Case,的动作序列过程中，在某一点上将开始执行,Use Case B,的动作序列，完成后将回到同一点上继续执行完,Use Case A,的动作序列,它与扩展关系的区别是：,扩展是可选的,包含是必做的（更象一个子过程）,和扩展关系一样，一个,Use Case,可以包含很多个子,Use Case,，也可以被很多个父,Use Case,所包含,41,包含关系,(include),示例,42,包含关系,(include),示图,43,关于扩展和包含关系,44,Use Case,发掘实操,45,Use Case,发掘过程,定义,Actor,发掘,Actor,使用系统的脚本,Script,总结,Use Case,组合,研究,Actor,之间的继承关系,研究,Use Case,之间的,include,、,extend,关系,贯穿始终：维护一套词汇表,CE,46,词汇表！词汇表！,词汇表有多重要,?,可以建巴别塔,代码中的变量,需求文档的重要组成部分和线索,维护词汇表应该是产品团队最重要的工作之一,Buddy,？面板联系人？通讯录联系人？,电话好友？手机好友？,QQ,联系人？邮件好友？,IM,联系人？过滤联系人？,47,词汇表示例：被叫号码,本节所述之被叫号码，其格式要求为：,符合,E.164,电话号码编号计划规范。,对于,PBX,分机号码，应为,1,8,位数字；,对于普通电话号码，合法格式为：,以“,+”,、“,-”,分隔的,1-21,位数字字符串；,可选包含以“,+”,引导的国家代码；,如,+86,代表中国，,+1,代表美国；,必须包含地区代码和电话号码，其间用“,-”,分隔；,如,0755-26441099,；,010-38454233,；,如果包含国家代码，则地区代码的长途前缀（如“,0”,）应省略；,如,[phone],；,[phone],如果某外线号码包含分机号码，其间用“,-”,分隔；,如,0755-26551099-384,；,[phone]-384,对于中国移动电话号码，合法格式为：,国家代码和移动电话号码,如,[phone],或移动电话号码,如,13509345659,，在被叫号码中无需根据对外地手机加入,0,前缀。,不包含,Omni PCX,交换机的外线拨号前缀。,如某,Omni PCX,交换机的外线拨号前缀为“,9”,，但在,RTX,系统中的电话号码资料中不需要具备这个外线拨号前缀。,RTX Omni PCX,插件软件需求规格说明书,.doc,48,Use Case,的,Pattern,大部分互联网服务本质上是,DB,：,增删改查,导入导出,批量操作,计算机应用的基础支撑功能：,安装卸载,启动停止重启动,OAM,（运营、管理、监视）,49,自定义头像的,Use Case,用户,Server,组管理员,PMM,第三方头像,CP,设置自定义头像,从本机设置,从网络硬盘设置,从第三方系统设置,第三方,头像系统,网络硬盘,系统,extend,extend,extend,添加第三方,CP,查看头像运营数据,50,Use Case,阐述,51,Use Case,：开始走向需求规格说明书,Use Case,图并不是需求文档的必备部分,Use Case,分析是过程，不是结果,Use Case,阐述，等于：,52,Use Case,阐述的基本四要素,进入条件,描述,Use Case,在何种情况下进入,如用户必须具备什么条件？之前发生了什么？,基本流程,不考虑任何异常例外，没有,if then else,从用户角度阐述,Use Case,如何运作,结束条件,Use Case,成功结束后，发生了什么变化,用户发生什么变化？系统发生什么变化？,例外流程,逐个阐述在基本流程中某个环节出现异常时的处理,53,Use Case,阐述的几个禁止,禁止假设系统由哪些技术实现模块组成,“系统从,服务器基础,DB,中删除好友关系”,禁止假设用户可以使用哪些,UI,界面,“系统弹出,错误提示窗口,”,禁止使用没有主谓宾的语句,“给出提示”,禁止使用没有任何意义、意义不全的语句,“系统给出,状态提示信息,”,“系统,立即,显示”、“,等,”、“,或者,”、“,其他,”、“,通常,”,禁止给出没有值域的定义,“系统显示,天气温度,信息”,54,Use Case,阐述的逐步细化,1,基本流程,a),当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。,b),邮件用户可以按照以下的一个或多个步骤执行：,c),按照发送这或主题整理邮件信息；,d),阅读邮件信息的内容；,e),把邮件信息保存为文件；,f),把邮件信息的附件保存为文件；,g),当邮件用户要求退出管理新来邮件信息时，功能夹终止。,55,Use Case,阐述的逐步细化,2,期望扩展,a),当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。,用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。,b),邮件用户可以按照以下的一个或多个步骤执行：,c),按照发送这或主题整理邮件信息；,d),阅读邮件信息的内容；,e),把邮件信息保存为文件；,f),把邮件信息的附件保存为文件；,用户必须能够看见附件的文件类型,g),当邮件用户要求退出管理新来邮件信息时，功能夹终止。,56,Use Case,阐述的逐步细化,3,补充值域,a),当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。,用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。,平均每,100,个同时显示的未读邮件消息中，其中,90%,的消息主题行少于,40,个字符。,b),邮件用户可以按照以下的一个或多个步骤执行：,c),按照发送这或主题整理邮件信息；,d),阅读邮件信息的内容；,平均消息内容包括,100,字符。,e),把邮件信息保存为文件；,f),把邮件信息的附件保存为文件；,用户必须能够看见附件的文件类型,这种情况下，,95%,的邮件都少于,2,个附件。,g),当邮件用户要求退出管理新来邮件信息时，功能夹终止。,57,Use Case,阐述的逐步细化,4,补充发生概率,a),当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。,用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。,平均每,100,个同时显示的未读邮件消息中，其中,90%,的消息主题行少于,40,个字符。,b),邮件用户可以按照以下的一个或多个步骤执行：,c),按照发送这或主题整理邮件信息；,(,在这种情况下，有超过,60%,做了此项操作。,),d),阅读邮件信息的内容；,平均消息内容包括,100,字符。,e),把邮件信息保存为文件；,(,在这种情况下，少于,5%,做了此项操作。,),f),把邮件信息的附件保存为文件；,用户必须能够看见附件的文件类型,这种情况下，,95%,的邮件都少于,2,个附件。,(,在这种情况下，有少于,30%,做了此项操作。,),g),当邮件用户要求退出管理新来邮件信息时，功能夹终止。,58,Use Case,阐述后,发现词汇，并给以定义,详细的解释，值域的描述,形成需求文档中的“定义”,发现功能需求和性能需求,整理文字，形成功能需求规格说明和性能需求说明,59,性能需求,60,性能需求的,Pattern,性能指标,易用性,安全性,兼容性,可扩展性,可维护性,可延展性,可移植性,可编程性,可靠性,可测试性,产品关注,技术关注,61,性能需求的专业化撰写态度,产品经理应忘记自己懂技术、交互,从用户、市场角度把要求提出来,弄清楚自己的专业发展方向,User-Oriented,，,Market-Oriented,其他的，不妨“扮猪吃老虎”,62,Good News,：天下文章一大抄,在一个产品系统中，性能需求是可以,Copy,的,第一份性能需求是重点，大家一起作,之后的需求文档往往只需改变：,性能指标,可扩展性,易用性,可延展性,安全性,兼容性,可维护性,可移植性,可编程性,可靠性,可测试性,这里简简单单几句话要求，,让开发同事、设计师作半年,63,需求规格说明书,64,没有高质量的需求,软件就象一个巧克力的盒子,你不会知道你将要得到什么,65,高质量需求叙述的特性,正确,可行性,必要性,优先权,明确,可证实,66,高质量需求叙述的特性,1/6,正确：,每个需求必须精确描述要交付的功能。,正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。,只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。,67,高质量需求叙述的特性,2/6,可行性：,在已知的能力、有限的系统及其环境中每个需求必须是可实现的。,为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，这个开发人员应能检查,在技术上什么能做什么不能做,哪些需要需要额外的付出或者和其他的权衡。,在抽象阶段应该有市场人员参与。,68,高质量需求叙述的特性,3/6,必要性：,每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。,每个需求源于你认可或者具有授权的原始资料,跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户（特别是,Boss,）的意见。,如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。,69,高质量需求叙述的特性,4/6,优先权：,为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。,客户或其代理都应有强烈的责任建立优先权。,如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。,优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。,Must Have,Nice To Have,Can Delay,70,高质量需求叙述的特性,5/6,明确：,需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。,自然语言极易导致含糊。要避免使用一些对于,SRS,作者很清楚但对于读者不清楚的主观词汇，如：,用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。,每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。,检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。,71,高质量需求叙述的特性,6/6,可证实：,看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。,如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。,需求之间不一致，不可行，不明确也能导致不可证实。,任何需求如果说,产品将要支持什么,也是不可证实的。,72,高质量需求说明书的特征,完整,一致性,可修改性,可追踪,73,高质量需求说明书的特征,1/4,完整：,不应该遗漏要求和必需的信息。,完整性也是一个需求应具备的。,发现缺少的信息很难，因为根本不存在。,在,SRS,中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。,在需求抽象上，应用,Use Case,方法会发挥很好的作用。,能够从不同角度察看需求的图形分析模型也可以检查出不完整性。,使用,TBD,（,to be determined,）,标准标志已知的缺失,当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。,如“,Vista,表现”,74,高质量需求说明书的特征,2/4,一致性：,一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。,需求中的不一致必须在开发开始前得到解决。,只有经过调研才能确定哪些是正确的。,修改需求时一定要谨慎,如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。,75,高质量需求说明书的特征,3/4,可修改性：,当每个需求的要求修改了或维护其历史更改时，你必须能够审定,SRS,。,每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。,通过良好的组织可以使需求易于修改，如：,将相关的需求分组，建立目录表，索引，以及前后参考,Feature List.xls,是很好的工具,76,高质量需求说明书的特征,4/4,可追踪：,应能将一个软件与其原始材料相对应,如高级系统需求，用例，用户的提议等。,能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。,可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。,77,几个不好的需求,“,产品应在,不少于每,60,秒（？）,的,正常周期（？）,内提供,状态信息,”,“产品应,瞬间,在显示和隐藏,不可打印字符,间切换”,“,HTML,分析器可以产生,HTML,标记,错误报告,，帮助,HTML,入门者,快速,解决错误”。,“,如果可能,，主管号码,应,通过联机校验，而,不是,通过,主全体主管号码列表,校验”。,78,编写高质量需求的方针,句子和段落要短,采用主动语气,使用正确的语法，拼写，标点,使用术语保持一致性，并在术语表或数据字典中定义它们,以开发人员的观点看需求是否被有效的定义,需求编写者还要努力正确地把握细化程度,要避免包含多个需求的长的叙述段落,把正常流程和异常流程分开,密切关注多个需求合成了单个需求,通篇文档细节上要保持一致,避免在,SRS,中过多的重复需求,在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。,使用,Word,的“超链接”功能！,换位思考，不要太自信,Review,再,Review,，朗读自己的作品！,当成高考作文来认真对待！,79,一份需求规格说明书的内容,1/6,文档标题：,准确、言简意赅、遵守,SCM,规定,给产品取个好的英文简称,RTX Omni PCX,插件软件需求规格说明书,修订记录,认真对待，仔细填写,80,一份需求规格说明书的内容,2/6,关 键 词,、,摘 要,：,就像写您的学位论文一样去写,摘要可以最后补充，先标红免得忘记,81,一份需求规格说明书的内容,3/6,缩略语清单,：,对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释,。,参考资料清单：,请在表格中罗列本文档所引用的有关参考文献名称、作者、标题、编号、发布日期和出版单位等基本信息。,82,一份需求规格说明书的内容,4/6,引言,背景,A.,用一个名字标识要生产的软件产品。,B.,说明软件产品将干什么,如果需要的话,还要说明这个软件产品不干什么。,产品定义,本节必须给出易发生混淆的术语的定义,把词汇表都放这里,83,一份需求规格说明书的内容,5/6,概述,1,。系统描述,一般整个系统作一份，所有需求文档都,Copy,2,。系统功能,推荐用表格来说明本文档所列的功能需求,3,。开发环境,一般整个系统作一份，所有需求文档都,Copy,4,。开发环境,一般整个系统作一份，所有需求文档都,Copy,84,一份需求规格说明书的内容,6/6,产品需求,功能需求,到肉了，把功能需求一个个的写,UI,需求,找设计师,性能需求,天下文章一大抄,把握产品重点的性能要求,85,常用方法和工具,86,思维导图,87,鱼骨图,88,Pareto,图,89,一张图胜过百句话,UML,中的几种图表：,动态的观察系统：,Usecase,图,序列图,(Sequence Diagram),协作图,(Collaboration Diagram),状态图,(Statechart Diagram),活动图,(Activity Diagram),静态的观察系统：,部署图,(Deployment Diagram),组件图,(Compoment Diagram),对象图,(Object Diagram),类图,(Class Diagram),90,更多的,.,请参考,RUP 2000,中文版本,学习各种图表工具,学习工作方法,不是去学,UML!,记住：,产品经理的图，应该是用户可看懂的,不是程序设计图,可以不用,Visio,，用,Powerpoint,就可以画出来,不会超过,One Page,的规模，最好是,Half a page,91,以 马 内 利,仁爱、喜乐、和平、忍耐、恩慈、良善、信实、温柔、节制,92,