对于所有的产品经理来说，把市场的问题，导出为需求，并进一步把需求形成有价值的产品特征，最后把这些特征形成可供其它业务团队参考和执行的说明，这个工作最终会以需求文档的形式的呈现出来。
而这类文档通常就是我们所说的产品需求文档（PRD，Product Requirement Document）,其实PRD只是我们呈现产品需求的一种文档形式，除此之外，还有用户故事（User Stories，采用了align开发模式的朋友可能对这个比较熟）和工作故事（Job Stories）这两种形式。
那么，为什么同样都是为了说明需求和特征，而有这三种不同的表现形式呢？
这就得从每种形式所具有的优势和不足来说明了。
1、传统形式：PRD
先来看PRD，国外把这种形式称为是“传统需求模式（traditional requirements）”，这种形式应该是最早出现的，从根上说，是基于IEEE的定义制定的。
IEEE认为，需求是一种声明，它识别了一个能力、物理特性或质量因素，这些因素限定了要追踪的一个产品或过程的问题（a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.）。
不过在IEEE的定义中，他们认为一个产品的需求类型说明只应该包括5个方面，分别是：功能；性能；约束条件；接口；安全。
但是对于一个产品来说，事实上涉及到的需求并不限于此，因此，还有8个非IEEE认可的需求部分需要进行说明，这样算下来，一个完整的PRD其实是应该含有13个部分的，见下图：
但是，这种形式的PRD有一些不足，主要有三点：
1、PRD更多的是说明了产品要实现的能力；
2、PRD无法让相关执行团队清楚的知道目标客户到底希望解决什么问题；
3、PRD通常篇幅会非常大，相关团队很少有耐心认真阅读。
总之一句话，PRD是基于“产品”的角度，而非“客户”的角度的一种需求说明形式。
有朋友会问了，我有其它的文档对目标客户有说明啊，没错，你是有，但是开发团队会看吗，并且最为关键的一点是，如果分为多个文档，对于产品经理来说不是问题，但是对于开发团队来说，就是问题了，他们是不太会有耐心去把客户细分、客户问题、需求说明、产品规格等独立的文档整合起来去看的，并且还涉及到一个文档保密级别的情况。
同时呢，PRD还有一个先天的缺陷，就是因为它是IEEE定义的，因此，它更多的是适用在IT、电子行业，而几乎无法在其它行业应用。
但是，随着现在很多企业开始越来越倾向于“市场驱动”的产品发展模式，以及希望越来越快，越来越准确的推出产品，让产品团队中更多的成员了解我们的客户和他们的问题，从而能够更到位的设计出解决方案，因此，需求的呈现就出现了“用户故事”这种形式。
2、用户故事
先来简单介绍一下这种形式的诞生，这是由麦克.科恩在《User Stories Applied》这本书中推出的一种需求呈现形式，他的核心观点就是，要将“客户”作为主导，而不是“产品”。
为什么他会提出这种形式呢，其实和他的背景有关系，他一直是从事技术工作的，很大可能是受不了传统PRD那种大篇幅的说明，以及一旦需求不准确，开发就要返工的状态，因此就琢磨着怎么能够改变这种情况，因此，用户故事的形式就出现了，并且这位老兄还是敏捷联盟的创始人之一，这就是为什么在敏捷开发中，用户故事是必备的。
用户故事的形式其实很简单，基本上就是如下格式：
As a [role] I want to [do something] so I can [achieve a benefit]
翻译过来，就是：
作为一个【角色】，想【做什么】，从而我能够【获得什么利益】。
举例如下：
作为一个【普通用户】，希望【微信能够对好友分组】，这样我就能【更高效的管理我的朋友】。
用户故事的形式看起来是简单，简短的，但是却可以表明三个可能对开发团队来说比较重要的信息：
1、目标用户是谁：普通用户
2、要解决的问题：微信好友不能分组
3、获得的收益：更高效
一旦开发团队明确了这三个信息，其实就可以从技术实现的角度评估如何实现高效的管理好友这个功能。
用户故事的好处在于它能够从各个级别来进行需求的说明，也就是说，我们既可以用一个用户故事来说明一个产品要实现的需求，这个被称为是epic，也就是大型的用户故事，也可以说明一个产品中很小的一个需求，也即是基于epic分解出来的小的用户故事。
比方说：
作为一个【普通用户】，我希望【微信能有和QQ一样的使用体验】，这样可以【符合我的使用习惯】。
这就是一个很高级别的用户故事。
而上面提到的分组就是一个低级别的用户故事。
此外，用户故事的好处还有一个，就是它可以应用到几乎所有的行业，因为它不是基于某类产品的，而是基于目标客户的。
比方说：
作为一个【注重健康的消费者】，我希望【当前的慕斯蛋糕能降低含糖量】，这样能够【让我在享受美食的时候不用担心身体发胖】
作为一个【糖尿病患者】，我希望【血糖仪的试纸能够通用】，这样可以【让我更方便的购买】
作为一个【孩子的父母】，我希望【卷笔刀的刀片能够方便更换，就像手动剃须刀那样】，这样可以【让我减少更换卷笔刀的成本】
作为一个【家用车的车主】，我希望【家用车能够有更多的储存空间】，这样可以【让我在车上存放更多的小物品】
……
有些朋友如果听过老汤的课，可能会想起，咱们产品经理在有了客户问题的时候，会做一个工作，叫问题分析矩阵，想一想，这个思路是不是很类似啊：
问题是什么->我们的解决思路是什么->我们的解决思路的特征是什么->我们的这个解决思路能够给客户带来什么样的收益
其实就是这个原则，只不过问题分析矩阵是独立管理的一个文档，也没必要完全展示给相关团队，因此，用户故事就成了一种不错的呈现给团队的需求形式。
但是，这样不错的形式，还是有人提出了意见，而他建议的形式被称为是“工作故事（Job Stories）”。
3、工作故事
谁对用户故事有意见呢，不是我，是一个叫艾伦.克莱门特的老兄，他就指出，用户故事有三个问题：
1、They use Personas.使用原型
2、They couple implementation with motivations and outcomes. 他们将动机和结果的实施结合在一起。
3、They ignore context, situations, and anxieties. 他们忽视了环境、状况和焦虑。
为了更好的阐明他的观点，他做了一张图来说明用户故事的问题：
先来看第一个问题，这位老兄提出了一点，原型在什么情况下有意义，就是当客户和产品团队存在距离的时候，但是现在随着沟通技术的发展，这种距离越来越小，因此，他认为原型存在的价值已经不大了。
同时，他还指出在很多时候，我们所谓的原型其实是按照人口统计（某人的年龄、性别、种族和周末习惯）进行确定的，这样就无法让团队理解到底谁是消费者，谁不是消费者。
比方说，某人花30秒的时间买了一个面包，并花30分钟的时间吃了它，但是为什么要吃它，这个动机是在用户故事里体现不出来的。
因此，他认为在用户故事中，原型很大概率上是没有办法说明用户动机的，也就是说，到底是哪些人真正需要我们的产品？原型很大程度上体现的是一群事实上和产品并不相干的人。
再来看第二个问题，这位老兄认为结果和动机在用户故事中是混为一体的，比方说刚才那个面包的例子，吃是结果，但在用户故事中，并没有体现出动机，或许是为了充饥，也或许是为了尝鲜，还或许是因为嘴馋。
因此，他认为应该进行明确的区分，而不是取决于我们的假设。
第三个问题，这位老兄认为所有动机的产生可能会受到环境的影响、所处的现实状况，以及客户内心深处的焦虑（现在不是流行贩卖焦虑吗，估计就是从这里来的），比方说人云亦云，爱面子，虚荣，安全感、归属感、圈子文化等，都会对动机造成影响。
最终，他提出，应该用工作故事来进行一个需求的说明，基本格式如下：
When [ ], I want to[ ] , so I can [ ] .
翻译过来，就是：
当【在什么样的情况下】，我会【产生什么样的动机】，为的是我能【得到什么】。
第一个括号处填写的是situation，也就是环境、情形、情况，第二括号处填写的是motivation，也就是动机，第三个括号处填写的是expected outcome，也就是预计结果
举例如下：
当【在陌生人居多的情况下，需要填写个人资料的时候】，我希望【能够有效和陌生人区隔】，这样我就能【无须担心个人隐私的泄露】。
关于工作故事的详细思路，咱们有时间再说，这里只简单提一下。
尽管用户故事和工作故事，都包含有“故事”二字，猛一看起来，似乎两者完全不一样，但是如果仔细分析后，我们就会发现，其实PRD、US、JS，只不过是在从不同的角度在说明需求罢了，具体区别见下图：
我们（也就是图中的企业/产品团队）通过产品和客户产生关系，那么，需求也是在这样的流程中循环的，因此，从流程中的任何一个点都可以对需求进行说明。
PRD和用户故事、工作故事之间的区别好理解，它就是从产品这个点进行说明的。
主要是用户故事和工作故事稍微有些不太好理解，简单点说吧，两者都是基于客户的角度来描述需求，但是用户故事是以“你们（我们分析出的客户）想要什么”的视角来描述需求，而工作故事则是以“我（客户自己）想要什么”的视角来描述需求，可以理解为是一只手的正反面。
好，关于需求的三种表现形式就先谈到这里，尽管讲了这么多，但是我的本意可不是要讲如何来用这三种形式去描述需求，而是我在看了这么多相关的资料后，发现一个有趣的现象，就是所有的这些需求表现形式，没有一个是产品经理提出来的，不是技术背景的，就是UX背景的，不过这也正常，对于他们来说，咱们写的无论是哪种形式的需求，他们都是读者，读者自然要对作者的文风、文笔、形式提出自己的想法了。
但是，作为作者的我们，是否真的认真思考过如何才能把客户的需求，通过团队最愿意、最习惯接受的形式传达到位呢？或者再大点说，我们如何才能保证我们提供的每一个需求是真实且有序的呢？
关于这一点，我会在下一篇文章中进行说明。
最后，咱们一起来做个小调查，看看大家目前需求说明的形式都是什么情况。
在上一篇中，我们提到了我们交付给团队（主要是研发团队和营销团队）的需求呈现形式有三种：PRD；用户故事（User Stories）；工作故事（Job Stories）。
并且在最后也提到了一点，就是所有的这些呈现形式都是由我们的团队成员，而不是由我们这些产品经理设计出来的，这其实说明了两个问题：
1、对于实现需求的团队来说，他们到底需要什么样的需求；
2、对于产品经理来说，如果从我们的角度来看的话，我们该做些什么。
在本篇中，我们就来聊一下如何解决这两个问题。
先来看第一个问题，什么样的需求更能适合现在团队成员的要求。
这个我们就得站在他们的角度来分析。
作为实现需求的团队，我们向他们提供的每一个需求应该具有三个特征：1、清晰；2、合理；3、可实现。
接下来，我就通过三个真实的案例进行说明，这些案例都是我曾经做过的一个产品真实的需求情况。
先来看“清晰”。
什么是“清晰”呢？就是这个需求必须要能说明在产品中一个明确的实现目标。
其实这个看起来简单，但是在做的时候却容易出一些问题。
最容易出问题的地方是什么呢？就是一个需求没有被分割好，从而让实现团队无法准确理解这个需求的目的到底在哪里，简单说，就是看起来是一个需求，事实上则存在多个需求目的在里面。
比方说，有这样一个需求：
可以定义输入DV设备上的影像，通过我们的软件直接播放或者制作成某种格式的视频文件。
当时，我提这个需求的目的是实现一个功能，就是我们的软件可以直接支持DV传输过来的视频（在那个时候，通常是AVI格式的）进行播放和编辑。
这个需求看起来似乎是说明了这个问题，但是当时开发就给我提了四个问题：
1、这个“定义”是指什么？
2、这个“直接播放”是指什么？
3、这个“制作”是指什么？
4、这个“某种格式”是指什么？
然后我就开始给他们解释：
“定义”是指可以让用户自定义输入的AVI格式的相关参数，比方说要保存的文件夹，文件名，视频文件的选择（单个导入，还是批量导入），文件排序等。
“直接播放”是指文件导入完成后，可以提供两种播放模式，一种是直接播放，一种是选择播放，这个可以在设置中进行管理，默认为直接播放。
“制作”是指可以对导入的文件进行后期编辑，后期编辑包括帧的删除、合并，添加水印、添加字幕、片段截取等。
“某种格式”是指可以把制作完的文件导出为mpeg1、mpeg2、mpeg4、rmvb、asf这些格式。
在我解释完后，开发的伙计只说了一句话，你解释这么多，干嘛不在PRD中分开写出来呢。
是啊，为什么不把这一个需求分成四个需求写呢，这样多清晰啊。
因此，清晰也可以这样理解，就是我们一定要把需求尽量分割为最小可执行的单位，千万不要有笼统的说明。
再来看“合理”。
什么是“合理”呢？就是这个需求必须要存在现实意义，确实是要解决消费者的某个真实存在的问题。
很多时候，我们只是假设某个需求是有现实意义的，这只是我们的主观认为，而不是消费者的客观需要。
比方说，有这样一个需求：
可以输出定义的画面，进行声音的分离，把声音独立输出为DAC格式可以导入到PDA中。
这个需求我是参考了当时一个电视产品的一个功能，或许有些朋友有印象，就是“打开电视听音乐”，什么意思呢，比方说你正在电视上看一个音乐剧，但是呢，你只是想听音乐，而不想看画面，有了这个功能，你就可以关闭屏幕，只听声音，说的通俗一点，就是把电视当音响用。
暂且不说这个电视的功能是否有合理性，但是至少有一点，就是这个功能是很容易操作的，只要用遥控器把电视屏幕一关就可以了。
但是如果放到电脑软件上，仅仅这个操作就是很麻烦的，首先得导入视频，然后通过软件把声音和图像分离，只导出DAC的音频文件，然后把文件再导入到PDA这些移动设备中，很麻烦的。
但是否存在这样的现实场景呢？我其实是不知道的，只是觉得这是个噱头，是个自认为有意思的特征。
这就是不合理的需求，有了不合理的需求，才会有了不合理的特征，才会做了一大堆没有现实应用价值的功能，也才会有了不被市场认可的产品。
最后看“可实现”。
什么是“可实现”呢？就是指一个需求必须适配于企业当前的资源。
清晰的，具有合理性的需求，如果实现不了，其实也就失去了现实的意义。
比方说，有这样一个需求：
无线模式的互转，可以使电脑和家电之间进行内容（音频，视频，图画）的交互。
这个需求好不好，其实挺不错的，毕竟当时电脑的屏幕尺寸还是集中在15-17寸，如果能够像投影一样把电脑上的多媒体文件传输到电视上会大大提升视听体验的。
但是，这个需求要实现的关键是“无线传输”，这在05年左右，还真的是一个技术难题。
靠什么传输？在当时的民用领域中，我能想到的就是蓝牙，但是就靠当时蓝牙2.0的版本，想都别想，即使是现在最新的5.0的版本，传输速度也就是2M，现在用蓝牙听个歌还有延迟，更别说传输动辄几百兆，上G的视频文件了。
或许公司有自己的黑科技我不知道，但现实的情况是，这个功能一直没有实现。
通过以上三个案例，我们知道了，对于实现团队来说，他们希望的是需求是什么样子的呢？
如果用一句话来概括的话，就是：拿过来就可以直接开始执行，且不会出现工作浪费的的需求。
但是，现实的情况却是，我们很多产品经理提交的需求会让实现团队的伙计们动不动就把菜刀拿到桌子上，因此，我们怎么样才能提交清晰、合理、可实现的需求给伙计们，关键不在伙计们，而在于我们。
这就涉及到本文要探讨的第二个问题：面对这样的期望，我们应该做些什么。
要回答这个问题，我们首先还是得搞清楚客户遇到的问题和我们要实现的需求之间是什么关系，见下图：
基本上就是这样，但是，这也仅仅是说明了“问题”和“需求”之间一种简单的关联性，而我们也知道，在市场中，不可能存在这种简单的关系的，两者是在一个复杂的市场环境中存在的，因此，我们这张图就变成了这样，见下图：