《需求分析的六个原则（五）》由会员分享，可在线阅读，更多相关《需求分析的六个原则（五）（5页珍藏版）》请在金锄头文库上搜索。
1、用最简单的文字工具记录需求需求是信息的具体表现，我们知道，一个信息进行一次传递，需要具备以下5个条件：1、信息本身2、信息发出者3、信息承载介质4、信息接收者5、信息所处的环境这5个条件的综合作用决定了这个信息最终的质量。具体到需求这种和产品经理每日息息相关的信息上，我们都必须面对一个非常现实的问题，就是：如何来保证我们获得的信息的衰减性是最小，并且我们又如何能把这种信息尽量少衰减的传递给下一个接收者。既然本章的标题是“用最简单的文字工具记录需求”，并且在本系列的第三章中，我提供了一个自己整理的需求反馈文档模板，属于记录市场需求的第一个工具，因此，在本章里，就以这个模板工具为例，详细来说明一下
2、如何把需求记录好。 第一部分：这个部分比较简单，主要是说明原始需求提出者的信息，具体包括三项：1、需求来源：我这里是以我所在公司的情况写的，大家可以根据自己情况来定，其实这部分就是说明需求的市场细分，这个需求是个人终端客户提出的，还是企业级客户提出的。2、来源方名称：说明需求提出者的名称，如果是个人，就是姓名，如果是企业，就是企业名称。3、来源时间：说明需求提出者的反馈时间。这项比较关键，因为咱们通常会发现，客户向公司的是市场人员反馈了一个 需求后，市场人员往往不能及时反馈给我们，要么是想起来的时候才说，要么就是等着开会的时候才说，要么就是右耳朵进，左耳朵出，
3、根本没放在心上。因此，我在公司里一直强调有需求一定要及时通过这个文档反馈给产品部，当然，要让相关部门的每个人都真正重视起来，一是需要时间，二是需要规范。 第二部分：这个部分就是针对内部第三方的了，主要是说明需求获取方的信息，在前面的文章说过了，许多行业的产品经理很少有直接面对客户的机会，因此，我们往往还是通过第三方来得到市场需求，具体包括5项：1、需求提交人：这里用需求提交人，而不是需求来源，就是为了区别客户和第三方。2、提交时间：说明这个需求是第三方什么时候加入到需求池中的。3、所在部门：说明第三方所在的部门。4、工作职位：说明第三方在该部门内的工作岗位。5、PST位置：PST是什
4、么呢？就是产品战略表（Product Strategy Table），关于PST的解释这里不多说，对于第三方来说，只要说明这个需求是针对那个产品线或者产品的即可。 第三部分：这个部分就是针对需求本身的了，大家可以看出来，一共就三部分，非常简单，为什么呢？就是因为大家要知道，对于客户来说，他们在提出需求的时候，根本不可能按照我们期望的那样分门别类的告诉你。有一次，我们的一个产品经理和一个客户进行需求沟通，他首先问客户“你对我们产品的功能有什么想法呢？”对于客户来说，产品功能还是比较熟悉的，也多少说了一些，但是接下来问题就出现了，他又问客户“你对产品的UI有什么想法呢？”。客户一下子就糊
5、涂了，想了半天，问他“UI是什么？”，他可能也意识到这个词太专业了，于是又给客户解释说“UI就是界面，也就是产品的外观”，客户这次似乎是多少明白了一些，但是明显感觉在说的时候有些不够放开了，为什么呢？大家可以分析一下，你把UI就解释为界面或者产品外观，实际上在限制客户的思维，客户在每说一个需求的时候，就会想“我说的这个是和界面或者外观有关系的吗？”。这或许还好一些，UI还比较容易解释，如果是UE呢，谁敢说能让客户很清楚的知道UE是什么意思呢？用户体验？估计用户会更没体验了，呵呵！其实就是这样，对于客户来说，越是专业的词汇，越是把需求分的很细，在省了我们事的时候，反而会让客户很费事，我们要知道，
6、获取需求的时候，一定是要让客户在思维上不受限制，让客户想到什么说什么就可以了。在第三部分，也就是需求说明中，只有三个部分，即使是这三个部分，也不是由客户直接填写的，而是由公司第三方在获得了客户需求后，稍微进行整理后填写的，相对于第三方来说，他们要比客户更了解一些产品方面的知识，即使是这样，对于第三方而言，我们也不能太专业了。1、产品需求：针对产品介质本身的需求内容，通常包括功能、性能、UI和UE上的，不要细分，用户怎么说的，就怎么写。2、业务需求：针对产品营销层面上的需求内容，通常包括用户对产品的渠道、价格、销售、服务等方面的需求，撰写要求同上。3、个性需求：有时候客户会提出一些我们看起来异想
7、天开或者是我们没有预料到的需求，千万记住了，对于这些需求，不要一笑而过，一定要让第三方记录下来，有时候这些需求往往能够让我们的产品另辟蹊径，获得意想不到的成功。 第四部分：这部分就比较简单了，就是要让第三方留下自己的联系方式，因为如果我们对某个需求有不解或者想进一步沟通的时候，可以通过第三方找到提出这个需求的客户，便于我们进行直接沟通。从这个模板中可以看出，文章开头说到的信息传递的5个要素中，这个模板包括了4个，分别是：1、信息本身：模板中的第三部分。2、信息发出者：客户是需求的反馈者，第三方是需求的提交者。3、信息承载介质：需求反馈文档。4、信息接收者：第三方是客户需求的接收者，我
8、们是第三方需求提交的接收者。只有一个元素没有涉及到，就是信息所处的环境，这个环境虽然决定不了信息的传递过程，但是会非常影响信息传递的效果，也就是会影响到信息的衰减程度。这个环境包含的内容比较多，我也没有很好的整理过，就不往下结论了，但是有一点是我体会非常深的，就是信息传递的环境包含一个非常重要的因素，就是“信息传递的环节”。我们都知道一个传话的游戏，一个本来很有效的信息，经过的传话环节越多，那么到最后，可能已经和原始的信息大相径庭了，如果每个环节之间还是相互封闭的，问题会更多。这就是需求分析原则五中强调的第四点：保持沟通的通畅，是了解需求的保障。这个通常首先是每个环节之间一定要开放，二是每个环
9、节的传递介质一定是统一的，三是要传递的信息一定是标准的。许多企业花大力气建设CIS（企业信息系统），其实根本目的就是为了让部门间的信息流转能够畅通和高效，最终让企业的运转成本降低下来。在做一些企业级产品的时候，我们通常会不断地和客户进行需求的交流和确认，如果采用快速原型法的开发模式，那么，我们还会在原型开发完成后，和用户进行需求的最终确认，这个时候，就会有一个问题出现了，就是“这个原型一定是要让客户无需太多思考就可以理解的”。有时候我们会认为原型又不是成型的产品，差不多就行了，其实不然，对于客户来说，他们看到原型的时候就会认为最终的产品也是如此，因此，在原型上，不但不能掉以轻心，而且要更加重视
10、才可以。记得有一次，我们为一个客户做了一个产品原型，因为是原型，开发部门也没怎么当回事，许多细节地方都带着开发部门的专业印记。例如，这个产品中其中有一项很简单的功能，就是在选项里可以设置是否“自动读取放入光驱中的光盘”。但是在原型中，开发没当回事或者认为写中文太费事，于是直接就写上了“AUTO READ CDROM”，开发当然明白这是啥意思了，可是给客户看的时候，客户就是搞不清楚这CDROM是什么，解释了半天后，客户还是很认真地问“这个CDROM就是VCD吧，那CD能不能放呢？”。后来我和开发说这个事情的时候，开发还满不在乎的说“不就是一个原型吗，没必要那么费事吧！”我经常会遇到这样的事情，开
11、发和产品经理说“产品原型差不多就行了吧，简单表示一下就可以了吧”，那个产品经理认真地说“嗯，意思一下就可以了，没必要花太多精力”。还是前面提到的那句话：我们省事就意味着客户要费事。因此，需求分析原则五中第三点强调的就是：不要希望客户能花更多的时间来了解需求转换后的模型。 要做到这点，就只能在我们获得用户需求的那一刻起，就要想着“我费些事，客户就可以省点事”。 总结一下需求分析第五个原则的中心思想： 1、需求分析第五个原则：用最简单
12、的文字工具记录需求。客户并不麻烦，需求也不复杂，麻烦的是我们把一切做的太复杂了。 2、原则第一点：所有人都能懂的东西，最不容易出错。没有人喜欢复杂的东西，需求也不例外。 3、原则第二点：不需要再学习的东西，最不容易出错。产品是需求的表现，没有人喜欢复杂的产品，要做到这一点，就从需求开始吧。 4、原则第三点：不要希望客户能花更多的时间来了解需求转换后的原型。我费些事，客户就可以省些事，客户省事了，我们最终也就省事了。 5、原则第四点：保持沟通的通畅，是了解需求的保障要实现需求的清清楚楚，就要做到沟通的反反复复。
