《人人都是产品经理》读书笔记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. “六拍”拍的是：脑门、肩膀、胸脯、桌子、屁股、大腿

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

第二篇：人人都是产品经理笔记

产品究竟是什么？

产品是一组将输入转化为输出的相互关联或相互作用的活动的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。

产品的狭义概念：被生产出的物品；

产品的广义概念：可以满足人们需求的载体。

我的理解则更直白一点：产品就是用来解决某个问题的东西。

产品就是要同时解决用户的问题和公司的问题，一个都不能少！

现代产品经理

侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情.

为什么要注重用户体验

传统行业产品的用户知道，东西是买来的，花了钱的，所以有点不爽的地方也就 凑合着用，不至于把产品扔了立刻去再买个新的。而互联网、软件产品就不同，大多 数都是免费的，每类产品雷同的还很多，所以只要这个产品用得稍稍有点不爽，用户 马上就能很方便地找到另外一个试试。

于是，互联网、软件产品更重视用户体验，相应的，出现了很多产品经理会涉及 的工作内容，如交互设计、视觉设计、文案设计等。举个例子，有时候为了确定两个 按钮是上下分布好，还是左右分布好，我们有可能做大量的用户实验。在互联网、软 件行业中，产品经理能真正体会到“用户是上帝”的感觉，辛辛苦苦做一个产品，给 用户免费用，还要尽量让用户免费用得比付费的都爽。

避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准

备好问题清单，但清单只起一个引导作用，并不用照着读。

. 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用

户为什么这么做。为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作所谓“According to the data(根据数据)”是最难被驳倒的。

. 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、 片面。

. 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。 . 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。

答案的顺序，可能产生“顺序偏差”或“位置偏差”，即被调查者选择的答案可能 与该答案的排列位置有关。有研究表明，对陈述性选项被调查者趋向于选第一个或最 后一个答案，特别是第一个答案；而对一组数字，如价格和打分，则趋向于取中间位 置。为了减少顺序偏差，可以准备几种形式的问卷，每种形式的问卷选项排列的顺序 都不同。

用户是为想要的东西买单，而不是需要的。

满足需求的三种方式

我们通过产品需求来满足用户，顺着这个思路，就是要做一些用户真正需要的功 能或服务，虽然这是最常用的办法，但也是最“劳民伤财”的。在甩开膀子干活前， 我们有必要扩展一下思路，从问题的本质出发，寻找新路。

之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式： 改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。

降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子 想必大家都经常听到。

转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会 觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行 为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。

给大家说一个写字楼电梯的故事。

某写字楼可能是因为建造得比较早，考虑不周，电梯明显不够用，每天中午吃饭

的时候总是很挤，最上面几层的小白领们平均要等 20 分钟才能下到 3 楼的餐厅吃饭， 于是抱怨很多，他们给物业提意见，要求解决。物业公司找到了大毛，大毛帮他们分 析了一下。

改变现状。对现有产品做一些改进，在这个案例中就是增加电梯数目，或者加快 电梯运行速度，但成本太高，直接被否定。

降低理想。告诉楼里的小白领们，隔壁那个写字楼中午要等 40 分钟呢。俗话说“不 患寡而患不均”，人们更在意的是相对而不是绝对，这样确实可以减少抱怨，但是一种 低水平的满足需求，对产品美誉度没有帮助。

转移需求。电梯门上贴一些锻炼身体的公益广告，当然内容是说爬楼有益身体健 康。有效，部分用户走楼梯去餐厅了，但是刚吃过饭怎么办？爬几十层楼要得阑尾炎 的。最后，采用了一个看起来很傻的方案，在电梯门旁边安装一面镜子，让等待的人 们可以整理一下仪表，或者搔首弄姿一番，不至于那么无聊。

我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力， 减少抱怨，而且对写字楼来说，既不用花钱，又额外挣得一笔广告费；又如错开午饭 时间，让人们都能更少地等待。所有这些，都是想告诉大家，满足用户的需求，不一 定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。

模块：一般来说，根据人类记忆的特点，产品有 5±2 个模块比较合理，如果超过 7 个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站 产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构 16领域的知 识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。

信息架构（Information Architecture），简称 IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。

鲶鱼效应:即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业。其实质是一种负向激励，是激活员工队伍之奥秘.

有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动， 反之亦然，所以我们应该在动手前先找找有没有成本低，收效大的解决方案！