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

《人人都是产品经理》

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

产品经理这个概念更多地侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容。

做好成为产品经理的准备：例如：研究几十家公司的产品经理招聘广告。而后去应聘产品经理。

做项目通常要再保证品质的前提下，在时间要求T、人财物花费R、项目范围Q三点做平衡。

武器

商业需求文档（BRD）

Business Requirement Document，简称 BRD。这是产品生命周期中最早的文档，内容涉及市场分析、销售策略、盈利预测等。通常给大老板演示PPT，主要为了获得认可，争夺资源。

• 项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
• 商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般还会预测一下相关数字的变化，提出这个项目的商业目标。
• 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，最好能画出业务逻辑关系。搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧，可以试试， 但不要在这上面太花心思。
• 非功能需求描述：提一下重要的非功能需求，如果有的话。
• 资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
• 风险和对策：有的项目会有一些潜在风险，不妨给老板们看一下，并且给出自己的对策，说不定你觉得很大的麻烦，老板那里一句话就搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。

 从 BRD 中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。

举个例子：

---

市场需求文档（MRD)

Market Requirement Document，简称MRD。产品进入实施阶段，需要写出MRD，有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等等。实际工作中，常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。

产品需求文档(PRD)

Product Requirements Document，简称PRD。对产品功能的进一步细化。文档主要包含整体说明、用例文档、产品Demo等。

---

功能详细说明（FSD)

Functional Specifications Ducument，简称FSD。从这一步开始会出现很多技术内容，用例文档、产品界面、业务逻辑等都要确定。与此同时，硬件系统的设计、数据库设计、表结构设计等也开始由架构师、系统分析师们编写了。

---

统一建模语言（UML）

Unified Modeling Language，简称UML。它试图将软件工程的过程规范化。

• 类图：Class Diagram，描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述。
  -
• 用例图：Use Case Diagram，描述各个用例之间的关系。
  
• 状态图 ：State Diagram，表达系统里实体的状态转换，同样也是贯穿多个用例的。
  
• 时序图：Sequence Diagram 也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互。
  
• 活动图：Activity Diagram 接近我们常说的流程图，描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。

泳道：在活动图中，每条泳道代表整个系统的工作流程中，某个部分的活动。

• 协作图：Collaboration Diagram，表达不同对象之间是如何互相影响的。理论上它和时序图是可以等价转换的，不过时序图关注交互在时间上的步骤，协作图关注交互过程中各个对象间的关系。

用例文档（UC）

UC是需求人员写给开发人员的一种最基本的文档。
UC概述：

• 用例的唯一标识
• 用例名称：一个UC写一个任务，任务的粒度可自行把握。
• 业务描述：商业目标、用户目的等业务描述，说明为什么要做这个UC。
• 需求描述
• 行为者
• 前置条件：触发用例的前提是什么？
• 后置条件：用例完成，后续动作是什么？
• 其他说明
• 界面描述：截图，界面上各种元素的说明，并且会和Demo关联起来。或者单独写界面文档与UC文档互相引用。
• 业务规则：整个用例的通用规则，比如限制条件。但界面元素或流程中的私有规则不适合写这。
• 流程描述：分主干、分支和异常三种，描述这个用例由什么事件触发，系统和用户之间产生何种交互步骤。尽量用时序图和活动图代替文字描述。

产品经理 VS 项目经理

**产品经理——靠想。**产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。 ——内部驱动，判断力和创造力。
**项目经理——靠做。**项目经理事把事情做正确，把事情做的完美，在时间、成本和资源约束的条件下完成目标。——外部驱动，执行力和控制力。

项目历程

组建团队

PD,负责这个项目的需求，他们中的某一个可能兼任项目经理；开发经理及其团队，负责开发相关的任务。
UE，User Experience 用户体验师/交互设计师/视觉设计师/美工

项目的启动大会（kick off）

项目背景；项目意义、目的与目标；需求、功能点概述；项目组织架构；项目计划；沟通计划。

需求

一个需求的生老病死：

用户研究/需求采集
明确目标、选择采集方法、制定采集计划、执行采集、资料整理

用户访谈问题以及对策：

• “说”和”做“不一致的问题
  尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”。
• 样本少，以偏概全的问题
  首先，尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，以增量的方式做访谈。举个例子，先访谈5 个用户，得出基本结论，然后再访谈5个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。
• 用户过于强势，把我们往沟里带
  时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束。
• 我们过于强势，把用户往沟里带
  牢记访谈的目的，并且管好自己的嘴。

数据分析转化为商业价值:先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。

用户需求 VS 产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

我们存在的价值:
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西.

需求来源于理想与现实的差距，那么减小这个差距就有三种方式：改变现状,降低理想,转移需求
产品设计的最高境界——创造需求！

产品需求列表

注：开发量/工作量=（最乐观+最悲观+最可能）/3
或=（最乐观+最悲观+最可能*4）/6

需求的基本属性

需求种类

WBS

Work Breakdown structure 工作分解结构

Demo

Demo由产品和UE部门主导。在项目开始就要准备好，拿到KO会上讨论。
纸面——>线框图——>原型图——>界面

概要设计与详细设计

评审

每一种评审都可能有多轮，评审会议的组织者，可以考虑由QA担任，或者由每次评审的主讲人发起。

QA:Quality Assurance，质量保证人员，负责产品品质保证的相关工作，比如流程控制，不同于测试人员。

需求评审

是PRD评审、UC评审、Demo评审的统称。评审会上PD把PRD和UC说给开发和测试听，Demo评审则由UE的同学主讲。

设计评审

在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。

测试评审

俗称TC评审，在TC编写完成以后，测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PD、开发听。

开发阶段

测试阶段

开发工程师在设计与编码的同时，测试工程师会继续细化和调整测试计划，并完成TC编写任务，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

冒烟测试：Smoke Test，名称可以理解为该测试耗时短，例如如果存在设计缺陷，通电，板子冒烟。

后面PD还会代表用户做更详细的UAT或者“验收测试”。

UAT：User Acceptance Test，用户接受度测试。

接下来测试进行多轮测试，“发现Bug，开发修正，测试验证，发现新Bug”，叫做回归测试。

Bug级别定义标准

一般对一个Bug的描述有几个关键点：缺陷级别；所属产品、项目；Bug名称；Bug描述。

项目发布

SVN:subversion，版本管理工具

发布计划的评审需要运维人员的确认。对于用户影响较大的升级，采用“分流发布”或者叫“灰度发布”，即让一部分用户先用，收集反馈再决定大面积发布的时机。发布计划还要加上回滚方案，一旦发布不成功，赶紧把产品退回原来的状态。

发布注意事项举例：

项目小结

通过项目的日报或周报随时记录每天的情况，到总结的时候就水到渠成了。

不确定因素

• 变更事件：项目范围内需求的变化。
• **搭车事件：**项目范围的扩展。尽量搭顺风车，找内容相关的项目。尽量早搭车，再“需求冻结”之后一般不要再提。
• 紧急事件：一般由较高层的老板确认后自上而下的推动。

文档、流程、敏捷

建立自己的文档规范

文档只是手段

需求规范类

需求管理类

流程管理类

项目管理类

日常工作类

流程也是手段

设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。流程目的是改善路况。

敏捷更是手段

定制属于自己的敏捷方法：

• 有计划，更要“拥抱变化”
• 迭代周期内尽量不加任务
• 集中工作，小步快跑
• 持续细化需求，强调测试
• 不断发布，尽早交付

大产品、大设计、大团队

产品之大

时间之大：产品生命周期
空间之大：商业、产品、技术

好产品还需市场化

包装、定价、促销、销售、渠道

设计之大

五个层次：战略层、范围层、结构层、框架层、表现层
具体在我的另一篇博文《用户体验要素》阅读中有介绍。

团队之大

团队文化

管理 VS 领导

• 让优秀的产品经理在专业线路上拥有高级别；
• 对于产品、业务的决策有充分的话语权；
• 可以参与管理会议的业务讨论；
• 可以拥有临时的资源支配权，并给管理层提供同事的考核建议；
• 但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。

如何让团队更开心：

• 大中之小不如小中之大：送1000块的围巾好于送一件1200的衣服
• 有用的不如无用的：吃不掉、用不掉、送不掉也扔不掉的东西
• 需要的不如想要的
• 有选择不如无选择
• 小奖不如没奖
• 晚说不如早说
• 一次送不如两次送：好消息要分开说，坏消息一起说
• 公开不如不敢看
• 涨工资不如发奖金

奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。

灵魂

以企业价值观为根基，思考公司或产品的使命和愿景，培养大局观。

使命：我们为什么而存在，要做什么事情
愿景：我们希望成为什么

可行性分析

思路：

1. 我们在哪儿
   从市场扫描开始,PEST分析,分析四个方面的机会和威胁。
   
   竞争对手分析
   行业分析报告、资讯公司为我们做调研。
   深刻的自我剖析
   SWOT分析：包括分析企业的优势（Strength）、劣势（Weakness）、机会（Opportunity）和威胁(Threats)。
2. 我们去哪儿
   宏观上的用户需求：某一目标用户群体面临的问题是什么？
3. 我们怎么去
   用什么产品满足需求？产品的核心竞争力是什么？

出发

• 产品路标规划
  
• KPI
  SMART原则
  

产品经理的自我修养

主要职责

• 市场调研
• 产品定位与设计
• 项目管理
• 产品宣介
• 产品市场推广
• 产品生命周期管理

核心技能

• 沟通能力
• 无授权领导能力
• 学习能力
• 商业敏感度
• 热爱产品
• 注重细节，追求完美
• 日常产品管理能力

《 人人都是产品经理》 读后感

  读完《人人都是产品经理》这本书，了解到产品经理这个概念更多地侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容。并且做项目通常要再保证品质的前提下，在时间要求T、人财物花费R、项目范围Q三点做平衡。全书以讲故事的方式让我能形象的理解产品经理日常工作与生活的种种细节。
  首先，了解到作为产品经理应该拥有的“武器”：商业需求文档（BRD），市场需求文档（MRD)，产品需求文档(PRD)，功能详细说明（FSD)，统一建模语言（UML）中的类图、用例图、状态图等，用例文档（UC）等。
  其次，从灵魂上了解产品，以企业观为根基，思考公司或产品的使命和愿景，培养大局观。在产品开始前做可行性分析，思考我们在哪儿、我们去哪儿、我们怎么去，制定产品路标规划。
  清晰的学习了产品的诞生历程：组建团队（了解团队人员的具体职能），项目启动大会（kick off)中说明项目背景，项目意义、目的与目标，需求、功能点概述，项目组织架构，项目计划，沟通计划。需求采集（明确目标、选择采集方法、制定采集计划、执行采集、资料整理)、概要设计与详细设计、评审(需求评审、设计评审、测试评审)、开发、测试（Bug级别定义标准）、项目发布(版本管理)、项目小结（项目日报）。
  也学会在工作中的一些小技能，比如建立自己的文档规范、善于使用流程（在于保证“无论谁来做这个产品的设计，都能达到80分”）和定制自己的敏捷方法。了解到产品、设计、和团队以及团队文化（管理VS领导），如何让团队更开心。
  最后学习了产品经理的自我修养，了解了产品经理的主要职责是市场调研、产品定位与设计、项目管理、产品宣介、产品市场推广产品生命周期管理，产品经理的核心技能有沟通能力、无授权领导能力、学习能力、商业敏感度、热爱产品、注重细节、追求完美、日常产品管理能力。
  产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么你就是产品经理。