需求评审总被研发diss？给你们8个实用的产品建议

一直从事产品和运营方面的工作，经常会面临被研发diss的情况，比如下面这几种：

遇到这种情况怎么办？那种情况你们考虑了么？

你们知道这里面涉及的逻辑是怎样的么？

这根本实现不了！

甚至很多时候评审会都进行不下去，双方唇枪舌剑面红耳赤差点就干起来了。其实并不是产品同学不努力，也不是研发同学故意要刁难谁，反而，这是他们比较负责任的表现。大家想想，如果他们不去提醒你，原原本本按照你的需求去做，你猜大概率谁会去背锅？

产品对上线负责，这一点一定要明确，研发同学其实只需要负责实现，更好更快的实现，结果是产品来抗的。所以遇到这种情况，大家反而要去感激他们，是他们找出了大家在产品中的缺漏与疏忽。

虽然这些事情很难避免，因为代码实现不是产品完成的，很多出了产品功能流程上的问题，还有很多技术上面的问题，比如并发、响应速度、技术方案等等，都会影响到最终的产品质量。但尽量减少这样无畏的冲突，进而获得更多的信任，是区分一个好产品和一般产品的很重要的点。产品一向被认为是小ceo，那么信任你能够听你指挥来打仗，这是一个很重要很重要的技能。很多人的创业项目的搭档都是之前同事，所以作为一名优秀的产品经理，就一定要想好各种方法来减少这种疏漏，不断树立起自己的权威和信任。

那么如何去做呢？

我觉得这里面有一个很基础的点，我觉得是很多产品书籍中都没有提到的，那就是要明白代码的实现逻辑。懂技术方案对很多产品同学来说应该是没啥问题，耳濡目染也能知其所以然，但真正有几个人去想过代码实现的逻辑么？其实很简单，一行一行去执行，从上往下，没有跳跃，一旦执行不到最后一行不会停下来。所以知道这个逻辑，你就明白码农同学们的思维是怎样的，他们是按照这样的思想去想你的产品需求的。case1，balabala；case2，balabala……所以对他们来说，所有的情况执行完，才能结束。一般有异常情况没有考虑到，程序就不知道怎么走了，就会报错。错了就得重头再来，不会从中间续着往下走。而人却不同，上一秒还在思考学习，下一秒可能就在外太空遨游了，再下一秒继续学习。

这个逻辑解释起来很简单，那么有几个产品经理好好去想过怎样按照这样的思路去设计产品呢？大家可以随便去看看一个接口文档就很清楚，A发起一个Request给B，B给A一个Response说我这里通的，然后A才开始通过json把相应的数据请求发给B，这才有B把相应的json数据返给A，A再告诉B说我收到了。

这里面其实非常的单纯，是不是类似于大家在QQ微信上的聊天呢？

A：在不？

B：在

A：请教个事儿呗？明天你来上班么？

B：来

A：那我请你吃午饭哈

这里面存在的情况就会很多：

1）request没发过去；2）一直pending；3）发过去对方没回复；4）对方告诉我收到了，但系统一直没收到；5）同样接下来A的json数据又发不出去；6）或一直pending；7）发过去对方没回复；8）对方发给我了我接受不了；9）对方告诉我处理中……

这里面任何一种情况下，都有n中可能性：

比如我们分析一下case1）：代码有没有bug？网络有没有问题？是我们的网络还是运营商的网络？case3）网络有没有问题？有没有丢包？要不要重试？怎么个重试机制？重试几次？

是不是突然感觉产品还是蛮幸福的，甩手掌柜可以说，我们要对接这个接口，把这个功能给我实现了。认真点的，可能细一点，根据对方返回错误码，成功的我们处理，不成功的我们去拉一遍或者等他们再推一遍。貌似就这样的就已经是很负责任得了吧，但是和刚才想的那个比呢？是不是大巫见小巫的感觉？是不是觉得很幸福？

当然很多人可能会反驳说，现在很多东西都是流程化的，没那么复杂。没错，这个必须要承认，但关键时刻若出问题了，你猜大家怎么去排查问题？是不是一项一项逐一去看？可能还有嘴硬的同学，说debug会告诉你哪里错了，不用那么麻烦，甚至很多大公司代码写的巨牛逼，用代码去监测代码 的问题，但是又有几家会那么幸福的？

所以无论怎样，产品同学若是不理解代码实现的逻辑，就无法理解中间为什么会有那么多状态、问题，无法理解技术同学那么坚决而坚定的diss你，其实即便他们这样diss你，或者你怎么努力去迎合，依然有很多很多的东西是被他们默默地盖住了。当然你也可以很义正言辞的diss我说，产品主要关注业务细节，不用关注那么细的实现细节，也没错，可很多时候，细节的东西会变得非常非常的麻烦，今日不做，后患无穷。

比如举个例子，当你的用户量级只有1万的时候，接口我只需要考虑成功和失败就好了，失败的再来一下就好，简单点儿，快速上线。但是当你的用户量级在100万甚至更高呢？可能失败的其中一个很小的情况，就会影响几千几万人。如果你恰好在主流程的节点上，再恰好主流程上有很多的节点，一个垒一个，若你背着转化率的kpi，你信不信效果肯定不太容易能提上去？越大体量，这样的问题就越严重，细节就越能决定产品的最终成功与失败。所以细节决定失败也就这样诞生了。

虽然产品同学应该更多的关注业务，但我还是觉得大家要多多的注意这些细节，一方面锻炼了自己的业务能力，另一方面也能够树立起威信以承担更大的项目。

我倒是有一些还不错的建议，大家可以去借鉴和参考。

1、之前的产品文档，甚至开发设计的流程仔仔细细的阅读，一点都不要落下；

2、老老实实画流程图、时序图等，不会就赶紧去看看怎么回事；

3、涉及到实体与实体之间关系的，想想二者之间的关系，类似E-R图。

4、流程的关键节点，根据流程图等好好想想都有什么状态；

5、页面交互跳转逻辑等别偷懒，一个一个画好；

6、接口对接返回的错误码一个都不要放下，怎么处理都处理好，可以简单不可以遗漏；

7、善于收集各种参照竞品，想想他们的实现逻辑，必要时拿出来给技术同学参考；

8、多找研发抽烟吃饭沟通，提需求前可以先私下聊聊先验证可行性。

最后，真遇到被diss了不要慌，先认怂，没啥的，赶紧补上就是，线下多走动走动关系，努力改善下。下来多总结多思考，你的努力和付出都会有回报。