前段时间平安某子公司产品经理提出了一个需求:"手机主题颜色随手机壳颜色变化"，触及程序猿大哥盲区，其认为这需求提的和摘下天上的月亮一样，你咋不去摘呢！于是扭打起来，据说最终产品和程序猿双双被开除

如果当时产品提需求的时候，带上这份需求清单，讲明了背景、流程，从产品角度探寻可实现的方法（手机主题颜色随手机壳颜色变化的各种可行方案汇总，请移步：https://new.qq.com/omn/20180804/20180804G09186.html）等，会不会不同结局？

是什么需求清单那么神奇，请看下文。

1.需求来源

讲明需要来源（标明需求不是产品经理YY的）

一般需求来源分为：用户调研、竞品分析、客户需求、老板指示。针对不同的来源，我们需要进一步探寻需求的本质，或者说真正的需求是什么（如何发现真正的需求可参见我的另一篇文章：http://www.woshipm.com/pmd/1860832.html）

并具体的讲解说明。

以社区通知为例，需求来源有以下几个方面：

1. 现场调研时，医生表示社区中心有活动、消息需要通知居民；

2. 项目经理反馈现场客户提及产品提供社区通知功能；

并且，笔者对竞品进行了调研，发现竞品XXX也提供了通知公告发布功能

2.需求分析

表明产品经理对需求进行了思考、分析，不是拍脑袋

需求分析主要包括：

1. 涉及哪些类型的用户，涉及哪些端产品（如产品包括不同端产品）

2. 属于现有产品的什么模块，哪个流程

3. 影响现有产品的哪些功能

4. 如果有竞品已有此功能，竞品的具体情况是什么，竞品是怎么实现的

3.产品的定量/定性目标，如何达到

每个公司都要生存，做一个功能，公司会要求投入产出比，毕竟资源、人力都有限，如何最优地利用资源，产品也需要多加思考。

产品的定量目标一般包括：

1. 获客，此功能上线后，能让进入的用户增加多少？

2. 收入，功能上线后，能让公司走感谢多少收益？

3. 促活，如果不能增加获客，不能增加收入，那能促进多少活跃，是否能让留存多一丢丢？

当然，我们做产品，也不是那么势利的，有时候客户要求的功能，或者是基础的功能，比如登录，找回密码什么的，是不能增加获客、提高收入，促活，但功能要有哇，那么这里就是定性的目标。定性的目标，一般是功能上线后能实现的功能，达到的效果。

4.目标实现和当期实现

一般敏捷开发2周一个迭代，一个大的需求功能在一个迭代里完不成，就会设计到目标实现和当期目标。目标实现是指最终要实现的产品功能，类似共产党要实现的共产主义社会；而本迭代由于资源有限，只能实现的某个阶段，也就是当期目标，类似当下的社会主义社会。当期目标应以MVP为标准，实现最小可用。

5.现有的系统和流程

针对现在的需求，是已经存在的功能，需要迭代和优化，还是一个全新的功能？如果是已有的，那么现在的系统和流程是什么？你可能会说，如果是已有的，优化下 ，大家肯定都知道，就不用再说了。你必须说清楚，因为：1.有新来的开发、测试同事（互联网公司的更迭速度快）；2.过去做的功能很多时候记忆会变得模糊。因此，为了后续扯皮，尽量在事前让大家的信息保持一致，同频很重要。

6.可利用的资源

产品在分析需求的时候要综合考量，有大局观，你要关注你做的东西是否有可以借用的资源，包括现已有的功能、或者人力资源等。你做的需求功能不是孤立的，会和其他产品模块、功能相关联。比如说上文提到的通知公告的需求，给居民端推送公告通知的时候，我们就可以借助基础部门已经构建起来的站内信实现，而不需要自己再做一套功能。

那就需要我们在平时多和其他业务部门人多交流，一方面，可以了解其他业务部门现有产品功能，以及未来要做的，如果有业务结合点，可以一起做更大的业务；另一方面，在此过程中拓展人脉，会做事也要回为人。产品不能闭门造车，切忌做两耳不闻窗外事，一心只读圣贤书的秀才。

7.法律合规及其他限制因素

针对需求是否涉及用户的敏感信息、是否处方国家法规、或是道德规范等等，产品都需要考量。如果公司有法律合规部门，则需要和相关人员评审。对大公司，此部分很重要，如果没提前考虑到，到发版时突然出这方面问题，发版怕是没希望了。

8.责任方/干系人说明

需求责任方一般涉及：产品、开发、测试、运维人员。分别有各自的职责，比如产品，提供产品画布，功能流程图、原型及相关说明、PRD文档。

9.功能范围

功能要实现具体功能是什么，针对什么人群，采用什么方式，实现什么效果，是否有时间限制，新功能上线后怎么引导用户使用等。

10.业务流程图

功能范围里描述了要实现的功能，相对较散。业务流程图能将功能串起来，让听的人明白整条逻辑线，做的时候也更清晰。推荐使用Visio画流程图。

业务流程图示例

11.用例说明

用例说明可以让各方以用户的角度考虑问题，在编写前，需要提前注明使用产品的各个参与者和介绍。如果不是新产品，此步骤可以省略。

我们在第10步已经画了流程图，这一步需要将各个功能环节以用例的方式展示，用例涉及：

用例名称：此功能环节的名称

参与者：参与或操作(执行)该功能的角色

前置条件：参与或操作(执行)此功能的前提条件

后置条件：执行完毕后的结果条件

基本事件流：用最少的文字描述一下该用例的需求过程

可选流：参与者在执行基本事件流时可能面临的选择及相关简要说明

例外流：参与者在执行基本事件流时是否会出现例外情况，如果会，是什么

说明：其他上述内容未覆盖的情况

角色用例

12.数据流转和说明

请求是从哪个客户端发起，经过怎样的路径到达服务端，是否还需要流转，流转到哪里，在哪里处理后返回结果， 返回的结果又经过怎样的路径到达客户端？

可以用时序图、或网络拓扑图提现数据流转

数据流转时序图

13.异常处理

用户在使用吃功能过程中存在哪些异常情况，比如网络信号差图片加载不出来，付钱时余额不足等，是否有提示和指引？

14.数据埋点

上线了功能，我们需要看此功能是否有人用，用的人数多不多，进来后有没有真正使用，还是进来就出去了，使用过程中哪个节点用户流失率最大，通过埋点，做漏斗分析，我们就可以解答以上问题。

如果你提需求的时候，能把以上14点分析到位，对答如流，再也不用 担心被程序猿小哥哥打了 ，你说是不~