产品经理如何活着走出需求评审会_大数跨境｜跨境从业者专属的媒体平台

那么产品经理如何活着走出需求评审会呢？今天就来说说我的看法。

1、告知团队成员为啥做这个项目

不仅要告诉项目成员做什么，怎么做，还需要告诉他们为什么做这个需求。不要说是老板提的，我也没办法。项目成员需要你过滤需求，而不是需求的传话筒。也别说就做了试试看，你这样说，说明你内心也不清楚需求的价值。

最好能明确清晰的传达项目的目标，想要达到的目的，以及这样做可以给产品/团队带来的好处（比如有奖金等），有的时候技术成员知道为啥做这个需求，也会提出一些他们的意见和想法，而有的想法和意见还不错，产品经理完全可以采纳。

2、最好能绑定团队成员的KPI

有的公司，开发资源可能需要产品经理去争取，尤其是对于一些大公司来说，都需要PK需求的优先级。如果你的项目在公司的优先级比较高，公司领导正视，那肯定利于推行。如果你的需求公司领导不重视，而你想推动的话，最好能让你的领导向上反馈，将XX需求上线/XX 业绩指标达到多少，成为开发团队的KPI，这样对方也更愿意配合你。

3、需求逻辑严谨，无遗漏

每个需求务必做到逻辑严谨，无遗漏，这样才不会在会议上被开发diss，如果需求逻辑不严谨，经常有没考虑到的点，那你的权威将会大打折扣，技术人员会看不起你，也不愿意做你的需求。

怎么办呢？

要建立自己的交互设计自查表
站在开发的角度来实现需求
站在测试的角度体验功能
找技术人员给你参谋一下

要建立自己的交互设计自查表

我在辅导学员作业的时候，就有发现一个问题，那就是在涉及列表的时候，很多人并没有考虑排序的情况，我就说你把这一项加入到你的自查表里面，下次写完文档的时候拿出来看看，一项一项对照一下，你就能发现你不足的地方了。

其实这个和我们小时候做作业搞的错题本一个道理，上学的时候我们做作业，遇到做错的题目都会专门整理到一个错题本上，然后不断的看，反复的看，这样下次就不会做错了。

这个和人的大脑机理有关，当你不建立错题本的时候，你的神经递质就建立不起来，你下次遇到类似的题目还会错，所以我们必须建立我们自己的错题本。

那产品的交互设计自查表有哪些呢？看参考：

b. 站在开发的角度来实现需求

其实就是没有学会站在开发的角度来考虑需求，此时如果产品经理有技术基础会更容易明白，没有的话经过项目的实践积累也能够做到。把自己当成开发，如果要实现这些需求的话，我需要哪些条件说明呢？

比如获取数据的粒度问题。产品新人的文档中很可能有这样的描述：记录订单提交的时间、密码不能支持特殊字符…然后就没有然后了。可是在写代码的时候，开发需要知道时间是精确到分呢还是秒呢？密码不能支持特殊字符，哪些算是特殊字符？

再比如要给出足够明确的规则。产品新人很可能会写：推荐销量最多的商品…然后又没然后了。可是开发实现的时候需要知道销量是按照件量还是订单数计算呢？销量是计算多长时间呢？如果是一周的话，是自然周呢？还是之前7天的数据就可以了呢？

这样的例子不胜枚举。总体思路就是，作为产品不仅要需求描述出来，还需要站在开发的角度来考虑如何实现需求，如果你是开发需要哪些说明和条件才能用代码实现出来呢？虽然不需要写代码，但思考技术的实现路径能更好地帮助我们把需求描述得更加详细。

c. 站在测试的角度体验功能

除了开发会来问问题，测试人员在写测试用例的时候也会经常来骚扰产品经理，因为在某些测试场景下，软件/系统到底如何反应或者如何处理才是被当做是正常的呢？哪些又是bug呢？产品新人很可能又忘了做出相关的说明。

测试人员通常习惯在各种极端情况下来测试产品功能，虽然在用户实际使用中很少有这种情况，但是既然存在可能性就要考虑清楚应对方案。所以作为产品经理，也要学会站在测试人员的角度“变态”的体验功能，考虑需求。

比如同样是在输入项，测试人员就会喜欢试：输入特殊字符会怎么样？超出了字数限制会是什么反应呢？必填项不输就点下一步又会是什么提醒呢？需求文档中把正常的流程描述的很清楚，可是这些特殊情况的处理是否都想到了呢？

再比如在付款或其它流程中，测试人员又开始变态的尝试了：我中途退出应用行吗？突然断网了我该怎么办？还可能会尝试一下多设备登录是否可行呢？咦，你这个优惠活动，我可不可以钻个漏多参加几次呢？

测试人员就是这么一群人，不管三七二十一的采用各种可能的手段来体验功能点，找到bug是他们的目的，可是把正常的反应和意外的bug定义清楚就是我们产品经理的职责。学会站在测试人员的角度来体验产品、测试功能，能很好地帮助我们把需求定义得更加精准。

d. 找技术人员给你参谋一下

每个产品经理最好有一两个玩的比较好的公司技术人员，这样当你写好文档的时候，发给他，让他给你提提意见，而不是直接上评审会，有的时候，他们会从技术角度提出很多问题，这都有利于你在评审前完善自己的方案。

成为一名思维缜密的产品经理，不是一朝一夕的事情，需要项目的实践，不断的思考总结。

4、开会前最好打通关键人员

什么叫打通关键人员呢？相信每个团队都有说话分量比较重的人，可能是技术总监，也有可能是技术前辈，一般他没意见之后，团队其他大多数成员都没啥意见。所以，你在写好文档后，先发给这样的人看，有啥问题私下沟通，这样，开发就相当于走一下形式，不会浪费太多时间，产品经理也不会被diss。

5、开会资料在会议前发给团队成员预览

当然，如果觉得还不保险，可以把文档先发给团队成员看一下，让他们给你提意见，你遇到不同意见的人，私下沟通达成一致，这样会进一步减少你在会议上遇到的阻力。