《人人都是产品经理》读书笔记 看自己的书，终有所学

这本书是很多人推荐我们刚入门的人看的，于是便买了，在读的过程中却经常听到一些负面的言语，这本书讲的都是没用的、就是吹牛逼一类的言辞。但无论是怎么样，我想我至少应该读完它，才有资格去评价。

我感觉这本书是成功的，至少它的定位非常准确，-1到3岁的产品经理，我正处于-1的阶段，完全不懂什么是产品经理，产品经理在工作中都是什么样的，所有的人事关系如何，为什么产品经理是经理却没有人真是属于你？等等这一系列的问题，这本书都有所涉及，虽然主讲的是阿里的工作情况，每个公司具体情况有所不同，但还是有很多可以借鉴的内容。

对于产品经理，在我看来这本书系统的阐述了：为什么要做产品经理，产品经理都做什么，如何做产品经理。给未进门或者刚进门的产品们一个预防针，产品经理虽然看着什么都没做，但确实事事要考虑周全，负责的。

从在生活中抱怨某个东西设计的不合理，开始有自己的想法，到有激情做一个产品经理准备从菜鸟开始的勇气，再到对于做不做，做多少有自己的决定，最后能提出需求带领一个团队完成自己的项目，你就完成了一个产品经理的进化过程。

需求从何而来，又到哪里去

提出需求并不是凭空瞎想，我们必须明确，我的要做的东西是为了谁做，从用户中来到用户中去，才能实现产品的价值，用户是需求之源。为了获得用户需求，我们可以采用调查问卷、用户访谈甚至是先模拟好产品样本，让用户做可行性测试。当然，用户需求并不能决定我们要做什么，第一，对于从用户中采集的需求也不是全部需要满足的。第二，用户告诉你的也许只是最后的需求，我们要深入思考用户的需求到底是什么。理解用户也是我们做产品经理的重要素质之一。

在一轮采集与思考之后，如果你的需求经过内部评审，你的BRD足够吸引老板，被看好了，也许会因为经费和时间的问题面临着一些需求要被砍掉。那也只好如同书中所说：“情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子”。少做就是多做。我在做项目中也深有体会，要头脑风暴时想的功能点都想加进去，加完之后，发现自己的产品没有了亮点，变成大杂烩了。所以把握住自己的重心才能体现自己产品的价值。

生孩子容易，养孩子难

我很喜欢作者的这个比喻，把一个项目比做是孩子，从需求到立项再到项目最终上市，是母亲十月怀胎，一朝临盆。过程艰难程度可想而知，但是你的项目上市之后，并没有完，还需要苦心经营，把它养育成人。其中不免会有早夭的孩子。

Kick off 开始立项首先是组建团队，因为虽然你的名字里有经理

二字，但是你手上真的没有可以用的人，项目所需的人要跟不同团队主管去要。团建是很有必要的，为了以后大家沟通更方便。之后可以建一个项目督导会，主要是公司的上级，可以以防不时只需帮你被黑锅。项目计划，开发人员更喜欢有条理的工作，把每件工作安排的井井有条可以保障进度又能让大家明确目标。BRD、MRD、PRD统统都归你。写完之后一轮一轮的评审该来了，评审改错，再评审再改错。十月怀胎终于结束了，发布过程既欢喜也劳累。

孩子总算是生出来了，短暂的休息之后，又开始制定计划，如何让它生长的更好，最终给公司带来效益。运营起到了很大的作用。 产品的背后是团队

一个成熟的产品背后注定有一个伟大的团队，大家齐心协力才能完成这个产品。首先是对产品的设计，产品经理的定位，UI、UE的设计，让产品有了样子。其次是技术团队作为坚强的后盾，把一项项功能一一完成。然后是运营团队，通过各种方式让产品被大家知道，回归到用户中。最后还有为整个团队提供资金支持的老板们。一个团队，大家好才是真的好，最后别忘了请大家吃饭。

自我能力的提高

随着产品的上线，我们的能力得到了提高，但不要放弃前进的脚步，互联网行业更新速度太快，机会稍纵即逝，把握自己的位置，确定自己的方向，一步一步去实现自己的梦想。爱生活，爱产品，有梦

想，我们才不会变成咸鱼，做一个有价值的产品经理，才能不被时代所淘汰！

第二篇：《人人都是产品经理》读书笔记20xx0320

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

第三章：项目的坎坷一生

项目的坎坷一生的详图，如下图所示

重点一：产品 VS. 项目 and 产品经理VS.项目经理

1. 产品：是解决问题的东西

2. 项目：是一个过程。

3. 产品经理：靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。最重要的是判断力和创造力。

4. 项目经理：靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。最重要的是执行力和控制力。

重点二：立项

1. 团队组建

典型的项目组织结构，如下图：

项目督导委员会：为项目提供各种资源，监督项目过程。 PD:负责整个项目的需求。

开发经理及其团队：负责开发相关任务。

测试经理及其团队：负责测试相关任务。

UE(用户体验团队)：负责产品给用户的展现。

服务团队：负责产品帮助的编写，以及上线后的服务工作等。

如果项目牵涉到其他产品，还需要设置各种职能的接口人以协同工作。

2. 计划确定

2.1 里程碑确定：

需要在更大的力度上把开发计划、测试计划、发布计划等合并为项

目计划，确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线。

2.2 WBS拆分：有经验的项目可以利用原来用过的WBS模板，自顶而下地优化并套

用，无经验的项目可以自下而上，列出一个个最小的任务点，再组装起来。

2.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 功能详细说明

2. PRD(产品需求文档)介绍：

PRD模板目录结构示意图

修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。 项目概述：简单描述项目的背景、意义、目的、目标等。

功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关

系、全局的商业规划等。

用户范围：对本PRD设计的角色、系统做出简单的说明。

词汇表：对本PRD设计的专有词汇、术语、缩写等做出说明。

非功能需求：如性能需求、数据监控的需求等。

其他说明：其他任何需要说明的内容都可以写在这里。

UC(User Case)部分：首先对用例的整体进行说明，接着就是对一个个用例进行说明

(即用例文档)。

2.1 用例(User Case)文档介绍：

说明各个用例之间的关系，一般有类图、用例图、状态图、时序图、活动图等。 现以“小明下馆子”为需求来举例说明各个图。

类图：Class Diagram,

描述系统中出现的各个对象之间的关系，以及和外部系统

的关系。

类图举例

用例图：User Case Diagram,描述各个用例之间的关系。

用例图举例

状态图：State Diagram，表达系统里实体的状态转换。

状态图举例

时序图：Sequence Diagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。

时序图举例

活动图：Activity diagram，比较接近我们常说的流程图，

描述各个动作如何引起

系统变化，善于表达泳道较多、分支较多的情况。

活动图举例

2.2 UC模板参考

2.3 产品Demo制作过程

Demo一般会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。

重点四：概要设计与详细设计

1. 设计文档的书写原则：

第一：不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。

第二：细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。

重点五：项目的变化

变更事件：是指项目范围内需求的变化；

搭车事件：是指项目范围的扩展；

紧急事件：是指一般由较高层的老板确认后自上而下的推动，不受常规流程的限制的事件。

重点六：文档管理

1. 建立自己的文档规范

需求规范类：PD做什么；用户体验规范；通用原则。

需求管理类：用户调研；产品需求列表(含需求管理流程)。

流程管理类：日常发布流程；变更事件流程。

项目管理类：项目管理制度；项目任务书；Kick Off的PPT；项目组织结构；项目WBS(可生成进度);项目日报周报。

日常工作类：会议记录；个人日报周报。

总结：模板能让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容。

重点七：流程管理

1. 流程中的评审会议，哪些可以省

产品会议：必须有，决定“做不做、做多少”，实在太重要了，方向错了很可怕。 Kick Off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并为一次会议。

需求评审：必须有，需求评审就是PRD、UC、Demo评审。

设计评审：在开发人员实力很强的情况下省略(他们在需求评审时会有很多问题)，而开发较弱、新人多、业务不熟的团队，必须进行设计评审。

TC评审：仅次于需求评审，这是项目KO以后第二重要的评审。

功能评审：这其实也是必须的，而且需要项目干系人都参与。

发布评审: 可以让开发经理决定是否需要。

2. 商业评审和技术评审

商业评审的三个决定是：项目继续、重新定向、项目终止。【产品会议、功能评审】 技术评审的三个决定是：项目继续、有风险的继续、必须解决问题某问题后再继续。【需求评审、设计评审、TC评审、发布评审】。

重点八：敏捷方法

1. 敏捷方法特点：

? 有计划，更要“拥抱变化”

? 迭代周期内尽量不加任务

? 集中工作，小步快跑

? 持续细化需求，强调测试

? 不断发布，尽早交付

?

重点九：典型的“三边六拍”项目

1. “三边”指的是：边计划、边行动、边修改

2. “六拍”拍的是：脑门、肩膀、胸脯、桌子、屁股、大腿

“拍脑门”决策；“拍肩膀”信任；“拍胸脯”承诺； “拍桌子”骂娘；“拍屁股”走人；“拍大腿”后悔。