产品规划十步法

从概念到产品－需求分析过程Somethingaboutgrammar&literature产品经理社区引子：不仅仅纯技术•人文比科技重要！•方法比技能重要！初做者有经验者监督者专家管理者高级专家领导者资深专家4学习态度？•一天，三年甲班的杨过忘了交作业，导师郭靖问他：“为什么没交作业？”•杨过答曰：“作业为什么要交？交了不一定是自己写的；–写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼）–会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响）–考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶）–过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变）–毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见）–找得到工作又不一定保得住工作；（萧峰夺门而出）–……？”•只见现场沉默三秒之后，众人联手围殴杨过……5先从语法课讲起•用户是一个或者多个名词；•产品是名词，一般由很多个名词组成；•产品设计过程–功能需求就是找出“动宾短语”的集合–性能需求就是找出“形容词”的集合6订书机为例（仅供参考）产品订书机:n.一种装订文件的文具订书机包括：杠杆结构：n.进钉结构；n.压钉结构；n.钉书钉(消耗品):n.用户用户：n.使用订书机的人，应大于3周岁；且有手或者类似可以发出至少1kg力量的人。最常用(80%以上)为女性(21-40)。需求功能需求装订文件；Load钉书钉；Unload钉书钉；…性能需求外观、颜色、省力、材质….7产品设计过程•定义好用户•定义好产品•先分析功能需求•再分析性能需求80/20的误区：产品日趋同质化，公司之间的差别，市场竞争的成败，往往是由性能决定8互联网本质论•计算机为什么叫计算机？•互联网其实是一个大数据库•大部分应用都是数据库应用–Search?–B2B、B2C、C2C?–Gaming?Avatar？–Blog?•小部分应用是即时的存储转发类–IM–VoIP9课程概述10课程内容•UseCase分析方法–找寻用户–定义产品–发掘功能需求•性能需求的“套路”•需求文档的撰写•产品经理常用“技法”–工作组织方法–常用图表和绘图方法11需求分析与人文•需求分析是一个工业化的写作过程•80％的套路＋20％的创意•好的语文水平：–有利于抓住关键词汇–有利于培养数字敏感–有利于增强形容能力–有利于组织文档结构–有利于提高沟通能力12UseCase分析法13USE-CASE的历史•1967年Jacobson在爱立信工作的时候开始使用这种思想•这种想法最早应用于大型交换机系统的需求获取•1971年完成了这种方法的最初原型•1985年推出了改进版，并发布了面向对象的OOSE方法•大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去•它还被广泛的应用于工业领域14需求获取的前提•用户必须告诉你他想要什么•你必须完整地了解用户的业务•你必须知道与系统有关的任何人和任何东西•如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的•从专家那里了解用户业务的原理和规则•你是去了解要做什么而不是怎么做15首先，您需要把系统看成黑盒•一开始就深入细节的产品经理，忙乱而又没有绩效–往往陷入细节的泥坑，甚至是技术细节，甚至UI细节–被层出不穷的需求点和例外处理困扰–控制不住满脑袋乱冒的ideas•请相信！！！！！！！！！！！！！！！！！！！！–系统内部无论多么复杂–他总是可以被“使用说明书”说清楚16Actor17需求分析的第一个问题谁是这个产品的用户？或者，谁是这个产品系统中的角色？18什么是角色(Actor)•与系统发生交互作用的、系统之外的任何东西都是角色–可以是人–也可以是机器•角色不等同于使用者•角色存在于系统外部•角色不是活动的准确描述•使用者是行驶某个角色职责的系统的使用人员–如小王是个采购员我是角色Actor！19角色（续）•每个Actor都通过不同的方式使用系统，除非他们是相同的Actor•Actor使用系统的每一种方式就是一个UseCase群普通用户群管理员群股东群创建者群股东20角色分类•主动角色：UseCase的动作序列是由他先发起的，通常系统返回最后结果–主叫方，采购人员，票据录入员等•被动角色：系统通过调用角色来完成UseCase的动作序列（或其中的某一个动作）–不是初始动作的发起者–当系统需要它们帮助的时候–最终是为了满足主动角色的需要–通常是机器或其他系统ActorUseCase1UseCase2ActorActor21Script22脚本Script•脚本是一个角色与系统之间的一组交互作用•通常具有详细的真实数据及实际的期望输出值•一个应用系统可能具有成千上万个脚本•即使同一件事，所得到的脚本可能也会有细微的区别•脚本是描绘UseCase的重要的背景信息23脚本示例1：小王输入他的账号#4135972：小王输入他的密码#1198233：小王查询98.7.1至98.12.31日之间的平均余额4：系统显示余额1：小张输入他的账号#4133432：小张输入他的密码#6467883：小张查询98.3.1至98.5.31日之间的平均余额4：系统显示余额1：小李输入她的账号#3467802：小李输入她的密码#4356453：小李查询98.7.1至98.12.31日之间的平均余额4：系统显示余额24脚本与UseCase•一个UseCase代表一组潜在的脚本•通过研究一组相似的脚本，可以得到它们内在的逻辑•相似的脚本通常遵循相似的模式工作，并提供相似类型的结果•一个UseCase通常关注某一个目标•例如：查询存折余额脚本功能夹UseCase25UseCase26转让群通过UseCase描述系统功能需求•一个系统具有无限个潜在的脚本•但一个系统可以被有限的UseCase完整说明•系统的每一个UseCase都必须列举，否则系统将会遗漏功能创建群解散群加入群赞助群邀请加入群群内发言授权群管理27UseCase•描述系统提供的交互功能–一个UseCase可以被其他的UseCase调用–UseCase可以组合完成某一项更大的功能•UseCase说明系统需要提供什么而不是怎么提供–用户并不关心你如何给他们提供所需要的功能•UseCase一般是用“动宾”短语命名创建群解散群加入群赞助群邀请加入群群内发言授权群管理28UseCase•UseCase不是分析设计文档–虽然它们支持后续的分析设计工作•UseCase不是操作脚本–它不是用户使用系统时实际操作的具体步骤的记录–虽然它可能是通过操作脚本得来的29UseCase是很好的测试单元•UseCase清晰地描述了系统的功能界面•测试人员可以在开发初期制定测试计划•每一个UseCase都严格地说明了系统的某一项功能–它的输入–它的输出–期间的交互作用•UseCase是黑盒测试的基准30UseCase的阐述•应该包含UseCase的所有重要细节•应该包括角色与系统交互的关键步骤，可以使用顺序图（SequenceDiagram）•要表述有关角色的信息•要分清哪些是角色所具有的职能、哪些是系统所应提供的•要列清使用这些功能是所应满足的前提条件•如果某些功能具有质量上的要求（如性能），也要列出来创建群DdddddddddddDddddxxafsdfadsDdddddddddddDdddfcadsfasdddddccdasdwe31UseCase：标记方法简单Actor名称UseCase名称32UseCase：主动角色经纪人下单投资人报价审查货币存取经纪管理系统33UseCase：被动角色经纪人下单投资人报价审查货币存取经纪管理系统银证转账系统34画UseCase图规则•主动角色画在图的左边•被动角色画在图的右边•每个UseCase必须为用户提供确切的功能•UseCase名称必须写在椭圆里面•保持图面整洁•每一张图里不能有太多的UseCase•为每一个UseCase编号便于检索•为UseCase建立目录（编号和名称）便于管理35UseCase高级概念36UseCase高级概念•通过分析UseCase图，分析人员可以找出不同的业务过程之间的共性–扩展、包含、派生、使用等关系•通过这些关系可以降低系统的复杂度•为重用提供了条件•将共性提出来，可以帮助我们发现重复的过程–二次开发应该关注的地方37Actor的继承•类似于UseCase的扩展，角色之间可以继承•其他银行不仅具有储户的所有功能，还有其他的功能查询余额存钱储户银行取钱费用结算其他银行38Actor继承的好处•在不丢失信息的前提下，简化了UseCase图•继承说明了角色间的层次关系•派生者继承了父角色的所有能力•父角色不知道派生者39扩展关系：extend•扩展关系通常用来表示某一个UseCase的可选择部分–扩展关系允许分析人员在没有改变基UseCase的情况下增加或修改基UseCase的功能–复杂的可替代途径应该使用扩展关系把它们分成多个UseCase•也可以这样看扩展关系：–在基UseCase上插入功能，而基UseCase本身不知道这个扩展使用柜员机查询余额《扩展》用户选择查询余额40扩展关系(extend)示图查询余额存钱柜员机用户柜员机取钱使用柜员机《扩展》用户选择查询余额《扩展》用户选择存钱《扩展》用户选择取钱41使用关系•如果UseCaseA包含UseCaseB，表示在执行UseCase的动作序列过程中，在某一点上将开始执行UseCaseB的动作序列，完成后将回到同一点上继续执行完UseCaseA的动作序列•它与扩展关系的区别是：–扩展是可选的–包含是必做的（更象一个子过程）•和扩展关系一样，一个UseCase可以包含很多个子UseCase，也可以被很多个父UseCase所包含存钱打印单据《包含》42包含关系(include)示例1.输入员工信息2.输入工资额3.输入职位4.保存5.系统进行合法化检查6.如果正常，系统建立新的员工记录1.摄像2.插入空白卡3.新建工卡包含的插入点父功能夹“增加新员工”子功能夹“新建工卡”43包含关系(include)示图查询余额存钱柜员机用户柜员机取钱使用柜员机《扩展》用户选择查询余额《扩展》用户选择存钱《扩展》用户选择取钱打印单据《包含》《包含》44关于扩展和包含关系45UseCase发掘实操46UseCase发掘过程•定义Actor•发掘Actor使用系统的脚本Script•总结UseCase组合•研究Actor之间的继承关系•研究UseCase之间的include、extend关系•贯穿始终：维护一套词汇表}CE47词汇表！词汇表！•词汇表有多重要?–可以建巴别塔–代码中的变量–需求文档的重要组成部分和线索•维护词汇表应该是产品团队最重要的工作之一Buddy？面板联系人？通讯录联系人？电话好友？手机好友？QQ联系人？邮件好友？IM联系人？过滤联系人？48词汇表示例：被叫号码•本节所述之被叫号码，其格式要求为：–符合E.164电话号码编号计划规范。–对于PBX分机号码，应为1－8位数字；–对于普通电话号码，合法格式为：•以“+”、“-”分隔的1-21位数字字符串；•可选包含以“+”引导的国家代码；–如+86代表中国，+1代表美国；•必须包含地区代码和电话号码，其间用“-”分隔；–如0755-26441099；010-38454233；–如果包含国家代码，则地区代码的长途前缀（如“0”）应省略；–如+86-755-26441099；[phone]•如果某外线号码包含分机号码，其间用“-”分隔；–如0755-26551099-384；[phone]-384–对于中国移动电话号码，合法格式为：•国家代码和移动电话号码–如+86-13509345659•或移动电话号码–如13509345659，在被叫号码中无需根据对外地手机加入0前缀。–不包含OmniPCX交换机的外线拨号前缀。•如某OmniPCX交换机的外线拨号前缀为“9”，但在RTX系