《人人都是产品经理》读书笔记.docx
- 文档编号:27246304
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:11
- 大小:299.09KB
《人人都是产品经理》读书笔记.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.“六拍”拍的是:
脑门、肩膀、胸脯、桌子、屁股、大腿
“拍脑门”决策;“拍肩膀”信任;“拍胸脯”承诺;
“拍桌子”骂娘;“拍屁股”走人;“拍大腿”后悔。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 人人都是产品经理 人人 都是 产品 经理 读书笔记