需求是信息的具体表现，我们知道，一个信息进行一次传递，需要具备以下5个条件：

  1、信息本身

  2、信息发出者

  3、信息承载介质

  4、信息接收者

  5、信息所处的环境

  这5个条件的综合作用决定了这个信息最终的质量。

  具体到需求这种和产品经理每日息息相关的信息上，我们都必须面对一个非常现实的问题，就是：如何来保证我们获得的信息的衰减性是最小，并且我们又如何能把这种信息尽量少衰减的传递给下一个接收者。

  既然本章的标题是“用最简单的文字工具记录需求”，并且在本系列的第三章中，我提供了一个自己整理的《需求反馈文档》模板，属于记录市场需求的第一个工具，因此，在本章里，就以这个模板工具为例，详细来说

  明一下如何把需求记录好。第一部分：

  这个部分比较简单，主要是说明原始需求提出者的信息，具体包括三项：

  1、需求来源：我这里是以我所在公司的情况写的，大家可以根据自己情况来定，其实这部分就是说明需求的市场细分，这个需求是个人终端客户提出的，还是企业级客户提出的。

  2、来源方名称：说明需求提出者的名称，如果是个人，就是姓名，如果是企业，就是企业名称。

  3、来源时间：说明需求提出者的反馈时间。

  这项比较关键，因为咱们通常会发现，客户向公司的是市场人员反馈了一个需求后，市场人员往往不能及时反馈给我们，要么是想起来的时候才说，要么就是等着开会的时候才说，要么就是右耳朵进，左耳朵出，根本没放在心上。

  因此，我在公司里一直强调有需求一定要及时通过这个文档反馈给产品部，当然，要让相关部门的每个人都真正重视起来，一是需要时间，二是需要规范。

  第二部分：

  这个部分就是针对内部第三方的了，主要是说明需求获取方的信息，在前面的文章说过了，许多行业的产品经理很少有直接面对客户的机会，因此，我们往往还是通过第三方来得到市场需求，具体包括5项：

  1、需求提交人：这里用需求提交人，而不是需求来源，就是为了区别客户和第三方。

  2、提交时间：说明这个需求是第三方什么时候加入到需求池中的。

  3、所在部门：说明第三方所在的部门。

  4、工作职位：说明第三方在该部门内的工作岗位。

  5、PST位置：PST是什么呢？就是产品战略表（Product Strategy Table），关于PST的解释这里不多说，对于第三方来说，只要说明这个需求是针对那个产品线或者产品的即可。

  第三部分：

  这个部分就是针对需求本身的了，大家可以看出来，一共就三部分，非常简单，为什么呢？就是因为大家要知道，对于客户来说，他们在提出需求的时候，根本不可能按照我们期望的那样分门别类的告诉你。

  有一次，我们的一个产品经理和一个客户进行需求沟通，他首先问客户“你对我们产品的功能有什么想法呢？”

  对于客户来说，产品功能还是比较熟悉的，也多少说了一些，但是接下来问题就出现了，他又问客户“你对产品的UI有什么想法呢？”。

  客户一下子就糊涂了，想了半天，问他“UI是什么？”，他可能也意识到这个词太专业了，于是又给客户解释说“UI就是界面，也就是产品的外观”，客户这次似乎是多少明白了一些，但是明显感觉在说的时候有些不够放开了，为什么呢？大家可以分析一下，你把UI就解释为界面或者产品外观，实际上在限制客户的思维，客户在每说一个需求的时候，就会想“我说的这个是和界面或者外观有关系的吗？”。

  这或许还好一些，UI还比较容易解释，如果是UE呢，谁敢说能让客户很清楚的知道UE是什么意思呢？用户体验？估计用户会更没体验了，呵呵！

  其实就是这样，对于客户来说，越是专业的词汇，越是把需求分的很细，在省了我们事的时候，反而会让客户很费事，我们要知道，获取需求的时候，一定是要让客户在思维上不受限制，让客户想到什么说什么就可以了。

  在第三部分，也就是需求说明中，只有三个部分，即使是这三个部分，也不是由客户直接填写的，而是由公司第三方在获得了客户需求后，稍微进行整理后填写的，相对于第三方来说，他们要比客户更了解一些产品方面的知识，即使是这样，对于第三方而言，我们也不能太专业了。

  1、产品需求：针对产品介质本身的需求内容，通常包括功能、性能、UI和UE上的，不要细分，用户怎么说的，就怎么写。

  2、业务需求：针对产品营销层面上的需求内容，通常包括用户对产品的渠道、价格、销售、服务等方面的需求，撰写要求同上。

  3、个性需求：有时候客户会提出一些我们看起来异想天开或者是我们没有预料到的需求，千万记住了，对于这些需求，不要一笑而过，一定要让第三方记录下来，有时候这些需求往往能够让我们的产品另辟蹊径，获得意想不到的成功。

  第四部分：

  这部分就比较简单了，就是要让第三方留下自己的联系方式，因为如果我们对某个需求有不解或者想进一步沟通的时候，可以通过第三方找到提出这个需求的客户，便于我们进行直接沟通。

  从这个模板中可以看出，文章开头说到的信息传递的5个要素中，这个模板包括了4个，分别是：

  1、信息本身：模板中的第三部分。

  2、信息发出者：客户是需求的反馈者，第三方是需求的提交者。

  3、信息承载介质：需求反馈文档。

  4、信息接收者：第三方是客户需求的接收者，我们是第三方需求提交的接收者。

  只有一个元素没有涉及到，就是信息所处的环境，这个环境虽然决定不了信息的传递过程，但是会非常影响信息传递的效果，也就是会影响到信息的衰减程度。

  这个环境包含的内容比较多，我也没有很好的整理过，就不往下结论了，但是有一点是我体会非常深的，就是信息传递的环境包含一个非常重要的因素，就是“信息传递的环节”。

  我们都知道一个传话的游戏，一个本来很有效的信息，经过的传话环节越多，那么到最后，可能已经和原始的信息大相径庭了，如果每个环节之间还是相互封闭的，问题会更多。

  这就是需求分析原则五中强调的第四点：保持沟通的通畅，是了解需求的保障。

  这个通常首先是每个环节之间一定要开放，二是每个环节的传递介质一定是统一的，三是要传递的信息一定是标准的。

  许多企业花大力气建设CIS（企业信息系统），其实根本目的就是为了让部门间的信息流转能够畅通和高效，最终让企业的运转成本降低下来。

  在做一些企业级产品的时候，我们通常会不断地和客户进行需求的交流和确认，如果采用快速原型法的开发模式，那么，我们还会在原型开发完成后，和用户进行需求的最终确认，这个时候，就会有一个问题出现了，就是“这个原型一定是要让客户无需太多思考就可以理解的”。

  有时候我们会认为原型又不是成型的产品，差不多就行了，其实不然，对于客户来说，他们看到原型的时候就会认为最终的产品也是如此，因此，在原型上，不但不能掉以轻心，而且要更加重视才可以。

  记得有一次，我们为一个客户做了一个产品原型，因为是原型，开发部门也没怎么当回事，许多细节地方都带着开发部门的专业印记。

  例如，这个产品中其中有一项很简单的功能，就是在选项里可以设置是否“自动读取放入光驱中的光盘”。

  但是在原型中，开发没当回事或者认为写中文太费事，于是直接就写上了“AUTO READ CDROM”，开发当然明白这是啥意思了，可是给客户看的时候，客户就是搞不清楚这CDROM是什么，解释了半天后，客户还是很认真地问“这个CDROM就是VCD吧，那CD能不能放呢？”。

  后来我和开发说这个事情的时候，开发还满不在乎的说“不就是一个原型吗，没必要那么费事吧！”

  我经常会遇到这样的事情，开发和产品经理说“产品原型差不多就行了吧，简单表示一下就可以了吧”，那个产品经理认真地说“嗯，意思一下就可以了，没必要花太多精力”。

  还是前面提到的那句话：我们省事就意味着客户要费事。

  因此，需求分析原则五中第三点强调的就是：不要希望客户能花更多的时间来了解需求转换后的模型。

  要做到这点，就只能在我们获得用户需求的那一刻起，就要想着“我费些事，客户就可以省点事”。

  总结一下需求分析第五个原则的中心思想：

  1、需求分析第五个原则：用最简单的文字工具记录需求。客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。

  2、原则第一点：所有人都能懂的东西，最不容易出错。没有人喜欢复杂的东西，需求也不例外。

  3、原则第二点：不需要再学习的东西，最不容易出错。产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。

  4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。

  5、原则第四点：保持沟通的通畅，是了解需求的保障要实现需求的清清楚楚，就要做到沟通的反反复复。