《人人都是产品经理》读书笔记.docx

《人人都是产品经理》读书笔记20120320.docx《人人都是产品经理》读书笔记20130320
第三章:项目的坎坷一生
项目的坎坷一生的详图,如下图所示
重点一:产品 VS. 项目 and
产品:是解决问题的东西
项目:是一个过程。
产品经理:靠想。产品经理是做正确的事,其所领导的产品是否符合市场的需求,是否能给公司带来利润。最重要的是判断力和创造力。
项目经理:靠做。项目经理是把事情做正确,把事情做得完美,在时间、成本和资源约束的条件下完成目标。最重要的是执行力和控制力。
重点二:立项
团队组建
典型的项目组织结构,如下图:
项目督导委员会:为项目提供各种资源,监督项目过程。
PD:负责整个项目的需求。
开发经理及其团队:负责开发相关任务。
测试经理及其团队:负责测试相关任务。
UE(用户体验团队):负责产品给用户的展现。
服务团队:负责产品帮助的编写,以及上线后的服务工作等。
如果项目牵涉到其他产品,还需要设置各种职能的接口人以协同工作。
计划确定
里程碑确定:需要在更大的力度上把开发计划、测试计划、发布计划等合并为项目计划,确定项目的几个里程碑,也是监控点,通常是需求完成、编码完成、发布上线。
WBS拆分:有经验的项目可以利用原来用过的WBS模板,自顶而下地优化并套用,无经验的项目可以自下而上,列出一个个最小的任务点,再组装起来。
工作量估算:三点估算法
“工作量=(最乐观+最悲观+最可能)/3”
或“工作量=(最乐观+最悲观+最可能X4)/6”
总结:做项目的本质就是保证品质的前提下,在时间要求、人财物花费、项目范围三点上做平衡。(TRQ:项目时间【Time】;项目资源【Resource】;项目质量【Quality】) 。
重点三:需求
需求开发文档说明:
BRD:Bussiness Requirements Document 商业需求文档
MRD:Market Requirements Document 市场需求文档
PRD:Product Requirements Document 产品需求文档
FSD:Functional Specifications Document 功能详细说明
PRD(产品需求文档)介绍:
PRD模板目录结构示意图
修订历史:写清楚每次修订的日期、版本号、说明和作者,便于以后追溯。
项目概述:简单描述项目的背景、意义、目的、目标等。
功能范围:给出本PRD的业务逻辑图,重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等。
用户范围:对本PRD设计的角色、系统做出简单的说明。
词汇表:对本PRD设计的专有词汇、术语、缩写等做出说明。
非功能需求:如性能需求、数据监控的需求等。
其他说明:其他任何需要说明的内容都可以写在这里。
UC(User Case)部分:首先对用例的整体进行说明,接着就是对一个个用例进行说明(即用例文档)。
用例(User Case)文档介绍:
说明各个用例之间的关系,一般有类图、用例图、状态图、时序图、活动图等。
现以“小明下馆子”为需求来举例说明各个图。
类图:Class Diagram,描述系统中出现的各个对象之间的关系,以及和外部系统
的关系。
类图举例
用例图:User Case Diagram,描述各个用例之间的关系。
用例图举例
状态图:State Diagram,表达系统里实体的状态转换。
状态图举例
时序图:Sequence Diagram,也叫顺序图,描述事物变化在时间维度上的先后顺序,善于表达对象的交互,比如多个页面之间、多个角色之间。
时序图举例
活动图:Activity diagram,比较接近我们常说的流程图,描述各个动作如何引起
系统变化,善于表达泳道较多、分支较多的情况。
活动图举例
UC模板参考
UC_<用例名称>:<用例ID>
用例概述
业务描述
<商业目标,用户目的等业务内容>
需求描述
<产品需求,需要实现哪些功能点>
行为者
<该用例的Actor>
前置条件
<Pre-Conditions>
后置条件
<Post-Conditions>
其他说明
<任何其他的说明信息等>
界面描述
UI示意图:<页面名称>
<Demo截图1>
<截图说明1>(给出Demo文件的地址)
界面元素——表单:<表单名称>
名称
类型|长度
必填
默认值
规则
∨
界面元素——列表:<列表名称>
名称
类型|长度
排序
规则
界面元素——按钮
名称
规则
界面元素——<其他>:<通用描述>
名称
<……>
规则
业务规则
序号
规则
1
(UC通用规则写在这里,流程中某步的私有