2019-12-05

我觉得做产品经理最大的快乐来源于实现自己的想法，而不是执行别人给的任务
1、从无到有，从有到优
2、产品规划，数据分析，用户研究，需求分析，功能设计，项目管理，敏捷方法
3、对市场有洞察力，深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品

在资源不足的情况下，把事情做成
1、信息不足以决策
2、时间不足以安排周密的计划
3、人员不足以支持工作强度和难度
4、资金不足以自由调配
这是常态

需求收集方法：
1、1 数据分析
1、2 调查问卷
1、3 用户访谈
尽可能多的采集
明确目标
选择采集方法
制定采集计划
执行采集
资料整理

需求分析：
听用户的但是不要照着做，必须明确我们存在的价值是 把用户需求转化为产品需求
1、4 确定需求的基本属性
1、5 分析需求的商业价值
1、6 初评需求的实现难度
1、7 需求的性价比（是否值得做）
1、8 精简，活下来的是少数，少做就是多做，尽可能的放弃

发现一个问题，然后设法将他转换为一个任务来解决

满足需求的三种方式：
之前我们说过：需求来源于理想与现实的差距，那么减少这个差距就有三种方式：
1、改变现状
2、降低理想
3、转移需求

案例：
电梯不够用，最上面的几层要20分钟才能到3楼餐厅吃饭
1、改变现状：增加电梯数目，加快电梯电梯运行速度，成本高 否定
2、降低理想：隔壁的物业最上面的下楼吃饭要40分钟
3、转移需求：
让下楼的人走楼梯（比如，爬楼有益身体健康）
让上楼的人，装个镜子在等电梯的地方，整理仪容，减低等待的不耐心
又或者电梯广告，又或者错开各楼层的就餐时间

最高境界--创造需求（胡思乱想的创造好的产品）

给需求做一次DNA检测：
大纲：：需求转化->确定基本属性->分析商业价值->初评实现难度->计算性价比
特别提醒的是，这里确定的是产品需求的各种属性，不同于之前提到的"单向需求卡片"，那张卡片里描述的是用户需求的各种属性

一、需求转化
1、统一记录需求的方式：excel，word或者思维导图
2、讨论，头脑风暴，对需求有全面的了解，然后在每个人分一块，转化为产品需求，最后记录在一起
3、Feature list（功能列表）（条件格式的筛选，单元格有效性，单元格锁定，隐藏等）

PD:直译为产品设计师,也可能叫产品规划师、需求分析师

二、
确认基本属性：
详细见excel 2、需求属性

三、分析需求的商业价值
一个公司做任何产品，一个产品做任何需求，最终目的就是满足一定的商业目的
需求的商业价值是最关键的内容，可以利用群体智慧，举行“需求讨论会”

我们可以从三个指标来衡量
******需求的商业价值
需求属性 属性说明
重要性 重要程度，辅助确定商业价值
紧急程度 紧急程度，辅助确定商业价值
持续时间 持续时间，辅助确定商业价值
商业价值(*) 商业优先级，不考虑实现难度，群体决策

重要性：可以参考时间管理里面的“重要和紧急”的概念
紧急性：在时间的维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题
持续时间：需求是有生命的，排期，核实的时间点上线很重要
商业价值：商业优先级，是对上述几种商业价值值班的综合评判，这一条是整个需求列表中最核心的部分

四、初评需求的实现难度：
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不去做
1、人力成本->工作量->开发量
******需求的开发量：
需求属性 属性说明
开发量(*) 需求的开发工作量，表征实现难度

开发：不明确每个需求怎么做，就无法准确的评估开发量
产品：没有时间明确到每一个需求该怎么做
导致死循环

开发量是必须要评估的，我们叫它"初评",允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师，架构师 评估的单位是 人/天

相对于"初评"，在项目启动之后，制定项目开发计划的时候，还有一次更加精确的评估，那时候需求怎么做也知道，由哪位开发来做也知道，可以推算出精确的工期，[工期和工作量是有很大区别的]

五、计算性价比
我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性，种类，商业价值，开发量，现在似乎开始写文档，干活了，但是经验告诉我们不是这样的：
比如：2009年 浏览器用户 99%使用IE，1%使用firefox
需求是采集到了，需求列表里面，但是一直放着没做;
那么该怎么解决这个问题？
"不要试图满足所有用户，一切只看性价比"

性价比=商业价值/实现难度(简化为开发量)
现在可以做决定了。我们把产品需求列表按照 "性价比" 一列从大到小排序

********需求的性价比
需求属性 属性说明
性价比(*) "商业价值/开发量"，用于决定先做哪个

实际工作中，对性价比的判断会有偏差
比如多和开发接触：会倾向于做实现难度小的（开发抱怨需求麻烦）
比如多和运营接触：会更多的考虑商业价值（运营要数据）

上面对于需求的DNA检测结束了，我们将迎来一场残酷的"战争"

2.4 活下来的永远是少数
产品会议，用进行准备的商业需求文档去争夺，人力资源，开发工程师，测试工程师

需求筛选：需求打包-BRD制作-产品会议-立项

在早先的时候：公司是按照产品线划分部门的，对于某个产品来说，有自己的产品设计师，开发与测试等，下一时间要做哪些需求。
现在：变成了按照职能划分团队，有了统一的产品中心，（也就是说 你开始需要抢资源了，有上级拍板，根据你的商业需求文档）

按照产品线划分的优点：对产品本身有利，产品经理的权限大，可以按照自己的想法做，资源有保障，产品规划不容易被改动，开发的头，测试的头都向产品经理负责

按照职能划分：有利于多产品之间的资源共享，但是效率不高
在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头冲
在有几个成熟产品之后，就多用职能线来充分的利用资源

准备出发：把需求打个包
做项目，终极目标就是：多快好省，即 范围大，时间短，品质高，资源省
对比经典的项目：TRQ：项目时间(Time)，项目资源(Resource),项目质量(品质和数量)

第一，“需求打包” 最好打包类似的功能点，是否类似取决于需求的基本属性
一般来说业务上逻辑关系密切的需求才会包含在一个项目里，

第二，需求依赖，功能互相之间有依赖关系，功能与人力资源之间的依赖关系

第三，需求粒度大小问题，在需求列表里面的任意一行，工作量最好不要超过5天

需求打包好了，就开始资源争夺了
一般来说 产品会议是一个月一次，这个和产品性质有关，如果你们公司的产品周期长，也可能两三个月一次

1、先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大的需求变更，已经发布的项目有什么问题等等；
2、商业需求文档(BRD)
1、1 项目背景：我们在哪里，我们为什么要做这个项目，解决什么问题（阐述项目的必要性）
1、2 商业价值：我们去哪里？最关键的点！做了这个项目之后，有什么价值，一定要说在点上，一般会预测一些相关数字的变化，提出一个商业目标
1、3 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打包好的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系
1、4 非功能需求描述：提一下重要的非功能需求，如果有的话。
1、5 资源评估：第二个重点！大老板们要看成本，他们在了解到达成项目需要多大的花费以后，才能做出决策
1、6 风险和对策：有的项目会有潜在风险，你可能觉的是很大的麻烦（在老板来说就是一句话），而且由于信息不对称，有可能和公司将来的战略有冲突，这个时候提出来，可以把把关

从BRD中的"商业价值""资源评估"两个重点就能发现，老板也是在追求性价比
大家都希望花费最少的资源获得最大的商业价值

2.4.2 别灰心，少做就是多做
用100%的质量去实现75%的数量，其实吸引用户的只是功能模块里面的一到两个点
我们留100%的质量就够了，这样留给客户的是升级的期待，如果反过来，功能铺的很开，但是每个点都不爽，反而喧宾夺主，埋葬了闪光的地方

情愿把一半的功能做到竟可能完美也不要把全部的功能都做成半吊子，当功能可以可无的时候，我们要有明确的选择：不做！！少做就是多做

做得少不如做得巧：
话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。
于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团
队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至 5%以内。
问题基本解决。
再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解
决之,经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。

我们应该在动手前先找找有没有成本低，收效大的解决方案！

3、项目的坎坷一生
项目是一个有重点的事情，产品是一个时序更迭的事情
1、kick off 会议的意思是项目启动会议,也可以叫做开工或者开踢会议。
确认了 团队成员，时间计划，沟通方法
立项->需求开发->开发->测试->发布
文档管理->流程管理->敏捷方法

产品经理：靠想，产品经理做的是正确的事，其所领导的产品是符合市场的需求，是否能给公司带来利润
项目经理：靠做，项目经理是把事情做正确，把事情做完美，在时间，成本和资源约束的条件下完成目标

立项：需求筛选->团队组建->计划确定->kick off

项目督导委员会
项目经理
PD（开始写需求文档） 开发经理（开始制定开发计划） 测试经理 UE(用户体验团队) 服务团队
开发工程师 测试工程师

项目沟通的方式各有不同：
周期：以 天或者 周 为单位，主要取决于项目时间的长短以及变化的频率
渠道：会议，邮件，需要在成本和效率之间取得平衡
发起者：一般由项目经理，开发经理，测试经理主导相应的沟通
参与者：发起者确定参与者，不要遗漏项目边缘的同事

方法可以是：
项目晨会：
项目日报：项目经理每日发给所以干系人，测试开始后以测试日报为主
评审会：相应PD召集需求评审，开发人员召集设计评审，测试人员召集TC(测试用例)评审
产品可用后，项目经理锦葵科召集功能评审，项目所有干系人参与评估
项目变更申请：项目发生重大变更，项目经理和项目督导委员会沟通后确认变更
发布预告以及公告：项目经理在项目发布前两个工作日发预告给项目所有干系人，项目发布成功后发公告给所有干系人

WBS-工作分解结构

需求采集-需求分析-筛选需求-立项-团队组建-计划制定-KO-写文档

产品需求文档：PRD
1、总体说明
1.1 修订历史
1.2 项目概述
1.3 功能范围
1.4 用户范围
1.5 词汇表
1.6 非功能需求
1.7 其他说明
2、UC部分
2.1 整体说明
2.2 UC正文
2.2.1 UC_<用例名称1>
2.2.2 UC_<用例名称2>
1.1 修订历史：写清楚每次修订的日期，版本号，说明和作者，方便以后追溯
项目概述：简单的描述项目的背景，意义，目的，坐标等，描述业务领域知识，让读者知道这个项目是为什么而做，这部分内容可以参考KO会议的PPT，如果此prd没有包含项目全部的需求的话，也应做相应的说明这部分1.2 需求是什么，其他需求在哪里等
1.3 功能范围：给出本PRD的业务逻辑图，重点描述系统中的角色职责，与周边系统的关系，全局的商业规则等；
1.4 用户范围：对本PRD涉及的角色，系统做出简单的说明
1.5 词汇表：对本PRD涉及的专有词汇，术语，缩写等做出说明
1.6 非功能需求：比如性能，数据监控，功能上线后额可以对新功能设置监控点，上线两周后由PD给出数据分析报告，以验证是否达到预期的商业目标，从而不断改善前期判断的精准度
1.7 其他说明：其他任何需求要说明的地方的内容都可以写在这

总体说明之后，是用例文档部分，首先要对PRD中所有的用例来个活命，给出可视化的表示，说明各个用例之间的关系，一般由类图，用例图，状态图，几种表示方法，其中用例图最关键

最后一部分"对单个UC的说明" UC(use case,用例)是需求人员写给开发人员看的一种最基本的文档
我常用的PRD模板里面有如下内容
注1：视觉层面的描述通常直接通过Demo表达，（页面大小，颜色，字体，字号）
注2：界面细节，引用界面规范文档（表格中文字的对齐方式）
注3：交互细节，引用交互规范文档（出错提示的方式）
注4：文案细节，引用文案规范文档（各种提示文案）

学一点UML：类图，用例图，状态图
UML：统一建模语言，它试图将软件工程的过程规范话
类图：哐哐图 和箭头
用例图(UC图)：描述各个用例之间的关系，行为描述
状态图：表达系统里的实体的状态转换，同样也是贯穿多个用例的（状态）

在产品会议之前，画demo（UE原型图）

概要设计与详细设计
第一：不以写的东西需求还是设计区分职责，而以"业务"或"技术"区分
比如在业务上需要对"公司长度"做限制由PD决定，而"公司名称"的数据在数据库里面如何存储，由工程师决定

第二：细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范，比如上例，通过几次协商，确定了以后产品中出现的各种字段限制规范，下次再写C的时候，可以直接引用

需求评审:PRD评审，UC评审，DEMO评审

测试环境，开发环境，预发布环境，生产环境

开发过程：设计-设计评审-编码-单元测试
测试过程：TC编写-TC评审-冒烟测试-功能评审-测试
验收测试：对于外包项目，需要由PD于测试共同完成，除了测试，还要检查项目交付物，比如，项目阶段文档，用户手册，是否符合规范

出现BUG的描述：
缺陷级别：5级一般大于3级就是严重问题
所属产品、项目：有的人需要同时处理很多产品，项目，这个属性可以用来筛选
BUG名称：一个短句，对此Bug的简单说明

项目发布：发布评审-预发布-发布-线上验证
预生产环境测试-发布-回归测试

3.5 山寨级项目管理