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

1、人人都是产品经理读书笔记人人都是产品经理读书笔记20130320第三章：项目的坎坷一生项目的坎坷一生的详图，如下图所示重点一：产品 VS. 项目 and 产品经理VS.项目经理1.产品：是解决问题的东西2.项目：是一个过程。3.产品经理：靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。最重要的是判断力和创造力。4.项目经理：靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。最重要的是执行力和控制力。重点二：立项1.团队组建典型的项目组织结构，如下图：项目督导委员会：为项目提供各种资源，监督项目过程。PD:负责整个项目的需求

2、。开发经理及其团队：负责开发相关任务。测试经理及其团队：负责测试相关任务。UE(用户体验团队)：负责产品给用户的展现。服务团队：负责产品帮助的编写，以及上线后的服务工作等。如果项目牵涉到其他产品，还需要设置各种职能的接口人以协同工作。2.计划确定2.1里程碑确定：需要在更大的力度上把开发计划、测试计划、发布计划等合并为项目计划，确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线。2.2WBS拆分：有经验的项目可以利用原来用过的WBS模板，自顶而下地优化并套用，无经验的项目可以自下而上，列出一个个最小的任务点，再组装起来。2.3工作量估算：三点估算法“工作量=(最乐观+最悲观+

3、最可能)/3”或“工作量=（最乐观+最悲观+最可能X4）/6”2.4总结：做项目的本质就是保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。（TRQ：项目时间【Time】;项目资源【Resource】;项目质量【Quality】） 。重点三：需求1.需求开发文档说明：BRD：Bussiness Requirements Document 商业需求文档MRD：Market Requirements Document 市场需求文档PRD：Product Requirements Document 产品需求文档FSD：Functional Specifications Document

4、 功能详细说明2.PRD(产品需求文档)介绍：PRD模板目录结构示意图修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。项目概述：简单描述项目的背景、意义、目的、目标等。功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等。用户范围：对本PRD设计的角色、系统做出简单的说明。词汇表：对本PRD设计的专有词汇、术语、缩写等做出说明。非功能需求：如性能需求、数据监控的需求等。其他说明：其他任何需要说明的内容都可以写在这里。UC(User Case)部分：首先对用例的整体进行说明，接着就是对一个个用例进行说明(即用例文档)。2.1用例(Us

5、er Case)文档介绍：说明各个用例之间的关系，一般有类图、用例图、状态图、时序图、活动图等。现以“小明下馆子”为需求来举例说明各个图。类图：Class Diagram,描述系统中出现的各个对象之间的关系，以及和外部系统的关系。类图举例用例图：User Case Diagram,描述各个用例之间的关系。用例图举例状态图：State Diagram，表达系统里实体的状态转换。状态图举例时序图：Sequence Diagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。时序图举例活动图：Activity diagram，比较接近我们常说的

6、流程图，描述各个动作如何引起系统变化，善于表达泳道较多、分支较多的情况。活动图举例2.2UC模板参考UC_：用例概述业务描述需求描述行为者前置条件后置条件其他说明界面描述UI示意图：(给出Demo文件的地址)界面元素表单：名称类型|长度必填默认值规则界面元素列表：名称类型|长度排序规则界面元素按钮名称规则界面元素：名称规则业务规则序号规则1（UC通用规则写在这里，流程中某步的私有规则写在流程里）流程描述流程1(主流程)：触发事件：时序图 Or 活动图（尽量用途表达，下面的文字描述可选）步骤用户系统规则12分支流程-112.3产品Demo制作过程Demo一般会经历从低保真到高保真，从抽象到具体，

7、从全局到细节的渐变过程。重点四：概要设计与详细设计1.设计文档的书写原则：第一：不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。第二：细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。重点五：项目的变化变更事件：是指项目范围内需求的变化；搭车事件：是指项目范围的扩展；紧急事件：是指一般由较高层的老板确认后自上而下的推动，不受常规流程的限制的事件。重点六：文档管理1.建立自己的文档规范需求规范类：PD做什么；用户体验规范；通用原则。需求管理类：用户调研；产品需求列表(含需求管理流程)。流程管理类：日常发布流程；变更事件流程。项目管理类：项目管理制度；项目任

8、务书；Kick Off的PPT；项目组织结构；项目WBS(可生成进度);项目日报周报。日常工作类：会议记录；个人日报周报。总结：模板能让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容。重点七：流程管理1.流程中的评审会议，哪些可以省产品会议：必须有，决定“做不做、做多少”，实在太重要了，方向错了很可怕。Kick Off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并为一次会议。需求评审：必须有，需求评审就是PRD、UC、Demo评审。设计评审：在开发人员实力很强的情况下省略(他们在需求评审时会有很多问题)，而开发较弱、新人多、业务不熟的团

9、队，必须进行设计评审。TC评审：仅次于需求评审，这是项目KO以后第二重要的评审。功能评审：这其实也是必须的，而且需要项目干系人都参与。发布评审: 可以让开发经理决定是否需要。2.商业评审和技术评审商业评审的三个决定是：项目继续、重新定向、项目终止。【产品会议、功能评审】技术评审的三个决定是：项目继续、有风险的继续、必须解决问题某问题后再继续。【需求评审、设计评审、TC评审、发布评审】。重点八：敏捷方法1.敏捷方法特点：有计划，更要“拥抱变化”迭代周期内尽量不加任务集中工作，小步快跑持续细化需求，强调测试不断发布，尽早交付重点九：典型的“三边六拍”项目1.“三边”指的是：边计划、边行动、边修改2.“六拍”拍的是：脑门、肩膀、胸脯、桌子、屁股、大腿“拍脑门”决策；“拍肩膀”信任；“拍胸脯”承诺；“拍桌子”骂娘；“拍屁股”走人；“拍大腿”后悔。