《人人都是产品经理》读书笔记.docx
《《人人都是产品经理》读书笔记.docx》由会员分享，可在线阅读，更多相关《《人人都是产品经理》读书笔记.docx（11页珍藏版）》请在冰豆网上搜索。
《人人都是产品经理》读书笔记
《人人都是产品经理》读书笔记20130320
第三章：
项目的坎坷一生
项目的坎坷一生的详图，如下图所示
重点一：
产品VS.项目and产品经理VS.项目经理
1.产品：
是解决问题的东西
2.项目：
是一个过程。
3.产品经理：
靠想。
产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。
最重要的是判断力和创造力。
4.项目经理：
靠做。
项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。
最重要的是执行力和控制力。
重点二：
立项
1.团队组建
典型的项目组织结构，如下图：
项目督导委员会：
为项目提供各种资源，监督项目过程。
PD:
负责整个项目的需求。
开发经理及其团队：
负责开发相关任务。
测试经理及其团队：
负责测试相关任务。
UE（用户体验团队）：
负责产品给用户的展现。
服务团队：
负责产品帮助的编写，以及上线后的服务工作等。
如果项目牵涉到其他产品，还需要设置各种职能的接口人以协同工作。
2.计划确定
2.1里程碑确定：
需要在更大的力度上把开发计划、测试计划、发布计划等合并为项目计划，确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线。
2.2WBS拆分：
有经验的项目可以利用原来用过的WBS模板，自顶而下地优化并套用，无经验的项目可以自下而上，列出一个个最小的任务点，再组装起来。
2.3工作量估算：
三点估算法
“工作量=（最乐观+最悲观+最可能）/3”
或“工作量=（最乐观+最悲观+最可能X4）/6”
2.4总结：
做项目的本质就是保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
（TRQ：
项目时间【Time】;项目资源【Resource】;项目质量【Quality】）。
重点三：
需求
1.需求开发文档说明：
BRD：
BussinessRequirementsDocument商业需求文档
MRD：
MarketRequirementsDocument市场需求文档
PRD：
ProductRequirementsDocument产品需求文档
FSD：
FunctionalSpecificationsDocument功能详细说明
2.PRD（产品需求文档）介绍：
PRD模板目录结构示意图
修订历史：
写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。
项目概述：
简单描述项目的背景、意义、目的、目标等。
功能范围：
给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等。
用户范围：
对本PRD设计的角色、系统做出简单的说明。
词汇表：
对本PRD设计的专有词汇、术语、缩写等做出说明。
非功能需求：
如性能需求、数据监控的需求等。
其他说明：
其他任何需要说明的内容都可以写在这里。
UC（UserCase）部分：
首先对用例的整体进行说明，接着就是对一个个用例进行说明（即用例文档）。
2.1用例（UserCase）文档介绍：
说明各个用例之间的关系，一般有类图、用例图、状态图、时序图、活动图等。
现以“小明下馆子”为需求来举例说明各个图。
类图：
ClassDiagram,描述系统中出现的各个对象之间的关系，以及和外部系统的关系。
类图举例
用例图：
UserCaseDiagram,描述各个用例之间的关系。
用例图举例
状态图：
StateDiagram，表达系统里实体的状态转换。
状态图举例
时序图：
SequenceDiagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。
时序图举例
活动图：
Activitydiagram，比较接近我们常说的流程图，描述各个动作如何引起系统变化，善于表达泳道较多、分支较多的情况。
活动图举例
2.2UC模板参考
UC_<用例名称>：
<用例ID>
用例概述
业务描述
<商业目标，用户目的等业务内容>
需求描述
<产品需求，需要实现哪些功能点>
行为者
<该用例的Actor>
前置条件
后置条件
其他说明
<任何其他的说明信息等>
界面描述
UI示意图：
<页面名称>
<截图说明1>（给出Demo文件的地址）
界面元素——表单：
<表单名称>
名称
类型|长度
必填
默认值
规则
∨
界面元素——列表：
<列表名称>
名称
类型|长度
排序
规则
界面元素——按钮
名称
规则
界面元素——<其他>：
<通用描述>
名称
<……>
规则
业务规则
序号
规则
1
（UC通用规则写在这里，流程中某步的私有规则写在流程里）
流程描述
流程1（主流程）：
<流程名称>
触发事件：
<触发事件>
时序图Or活动图（尽量用途表达，下面的文字描述可选）
步骤
用户
系统
规则
1
2
分支流程-1
1
2.3产品Demo制作过程
Demo一般会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。
重点四：
概要设计与详细设计
1.设计文档的书写原则：
第一：
不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。
第二：
细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。
重点五：
项目的变化
变更事件：
是指项目范围内需求的变化；
搭车事件：
是指项目范围的扩展；
紧急事件：
是指一般由较高层的老板确认后自上而下的推动，不受常规流程的限制的事件。
重点六：
文档管理
1.建立自己的文档规范
需求规范类：
PD做什么；用户体验规范；通用原则。
需求管理类：
用户调研；产品需求列表（含需求管理流程）。
流程管理类：
日常发布流程；变更事件流程。
项目管理类：
项目管理制度；项目任务书；KickOff的PPT；项目组织结构；项目WBS（可生成进度）;项目日报周报。
日常工作类：
会议记录；个人日报周报。
总结：
模板能让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容。
重点七：
流程管理
1.流程中的评审会议，哪些可以省
产品会议：
必须有，决定“做不做、做多少”，实在太重要了，方向错了很可怕。
KickOff会议：
最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并为一次会议。
需求评审：
必须有，需求评审就是PRD、UC、Demo评审。
设计评审：
在开发人员实力很强的情况下省略（他们在需求评审时会有很多问题），而开发较弱、新人多、业务不熟的团队，必须进行设计评审。
TC评审：
仅次于需求评审，这是项目KO以后第二重要的评审。
功能评审：
这其实也是必须的，而且需要项目干系人都参与。
发布评审:
可以让开发经理决定是否需要。
2.商业评审和技术评审
商业评审的三个决定是：
项目继续、重新定向、项目终止。
【产品会议、功能评审】
技术评审的三个决定是：
项目继续、有风险的继续、必须解决问题某问题后再继续。
【需求评审、设计评审、TC评审、发布评审】。
重点八：
敏捷方法
1.敏捷方法特点：
Ø有计划，更要“拥抱变化”
Ø迭代周期内尽量不加任务
Ø集中工作，小步快跑
Ø持续细化需求，强调测试
Ø不断发布，尽早交付
Ø
重点九：
典型的“三边六拍”项目
1.“三边”指的是：
边计划、边行动、边修改
2.“六拍”拍的是：
脑门、肩膀、胸脯、桌子、屁股、大腿
“拍脑门”决策；“拍肩膀”信任；“拍胸脯”承诺；
“拍桌子”骂娘；“拍屁股”走人；“拍大腿”后悔。
升级会员 