时间: 2021-07-30 10:19:08 人气: 7 评论: 0
不要带着疑惑去处理需求，因为这个就像滚雪球，随着更多业务的不断增加，因为一开始的疑惑，而导致更多的不理解出现，这是一个令人懊恼的过程。因此在需求伊始，一定要将自己对需求的疑惑，充分地表达出来，好让需求方自检的同时，也好对你的问题进行一遍梳理。
需求在我们的日常生活中可以说是无处不在。比如你早上起床你需要洗漱，徐需要吃饭，需要做很多习以为常的事情。
那么在日常的产品工作中，当我们遇到一个需求，我们要怎么做呢？答案肯定不是不分青红皂白的拿来就做，这样的做法很可能导致的结果就是一而再再而三的改稿。所以有以下几种方式，能够提高你对理解需求的方式。
我们在需求方发布的需求的时候，如果可以要尽量在场，不管你是被邀请的，还是自己主动要参加，都可以；尽量让自己在场，让自己知道 ，需求诞生的背景，这样能够非常有利于你的后期设计。可能有的小伙伴**说我如果很忙或者因为职位的级别不够等种种不可能抗力因素怎么办？其实这个很好解决，如果你实在是无法置身其中，那你就要打起十二分的精神，和向你传达需求的小伙伴好好请教，势必问到自己心中没有疑惑，在和小伙伴沟通的过程中，不妨用用下面几个小方法：
在需求传达的初期，往往需求本身也不是很完善，这个时候，你一定要和pm紧紧的搞在一起（开玩笑），因为你的反馈对他来说也很重要。从需求的制定背景，需求的等级，需求的开发时间，需求自身的重要程度等方面来进行交流，交流下来，你可能发现这只是一个因为竞品做了，所以我们也要做的需求，或者只是因为业务方为了kpi的好看，当然也有可能最后的结果是这是一个很重要很严肃的需求。
不要带着疑惑去处理需求，因为这个就像滚雪球，随着更多业务的不断增加，因为一开始的疑惑，而导致更多的不理解出现，这是一个令人懊恼的过程。因此在需求伊始，一定要将自己对需求的疑惑，充分地表达出来，好让需求方自检的同时，也好对你的问题进行一遍梳理。
对于怎么更好的理解需求，先说这么多；接下来是当你对于需求重逢理解之后，要如何去处理需求。大致也分为以下几个部分：
调研的方式有很多，比如通过数据进行一个趋势分析，或者通过桌面研究，竞品分析，定量定性的研究种种，但是你在具体实施的时候要考虑需求的等级，其时间周期以及本身的资源限制，来进行，不然这一步是无法开始的。但是基本的调研还是要有的，不然你无法应付后期的审稿模块。
假设如果没有这些先天的条件，那你就要依赖自己的专业能力和经验来解决了，但是同时也可以在需求的处理过程中，去烦一烦pm，尽可能的阐述自己的具体解决办法。
产品上一直有句话叫“先有再说”，听起来好像不是那么负责任，其实这里的的先有再说，不是意味着有了之后就不管了，抛诸脑后，而是先将某个功能做上去，然后通过版本的不断叠加，最后达到产品的完美。你可能**说为什么在一开始就让它达到完美？但是其实在真实的环境中，一个功能需求的诞生和上线，时间都是非常紧凑的，你如果想在上线的初期就让产品趋于完美，那就需要大量的时间成本和人力成本来进行保障，但是这样往往解决了功能的不完美性，但是再上线，发现其他产品早就开始下一个产品亮点的推进了。
在需求处理的末尾，你需求整理自己的稿件，标好相关信息进行，将自己的想法以及界面的相关信息进行整理，然后发到承接此项目的小伙伴手中。但这仅仅只是开始，你还要在具体的开发过程中，随时待命，比如一些技术限制，需求优先级，逻辑漏洞等，这些问题**陆陆续续的找上你，你要有解决这么矛盾冲突的地方，并解决它。关于推动，不仅要跟踪开发的进度，还要是不是关心一下是不是项目遇到了什么问题，有时候自以为制作的产品逻辑上都没有问题，但是开发小哥哥可以灵光一闪的告诉你同样一个解决问题的更简单的方法，让你钦佩不已。
当然在需求的具体实施中，你可能要参加审稿大**，你要接受各个方面的质疑，也就是撕逼，他们考虑问题的角度和出发点都和你不一样，所以要善于倾听和接受，实在是无法妥协的地方可以再找一些方法来进行验证，比如灰度发布 a／b测试等。但是不能找身边的人举手表决，个人认为不是很专业，公平性也有待商榷。
没有说太多**性的东西，只是说了一些工作中的细节，我不是说**性的东西不好，**是基石，是想法的源泉，但是在和业务，pm争得面红耳赤的时候，更多的是对自己怎么去掌控各方的意见，和寻找突破口。
作者：秦东源，个人公众号：海鲜君的设计物语
本文由 @秦东源 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
