事件背景：

做地图需求时，在一轮提测后发生重大产品方案变更：（有多重大呢，这样说吧，对RD来说除了UI，其他基本就算推倒重来···谢RD不杀之恩）

10月9日方案技术评审时原定目的地点和POI信息都进行自动加载的策略，测试时根据实际效果调整策略。

然而呢···然而，

迭代包期间，就多次根据效果调整策略（覆盖到地图缩放逻辑、根据移动距离的分层加载不同内容），一直到一轮提测10月30日，依旧发现自动加载的逻辑无法准确命中用户是想切换目的地还是只是想在不同区域内查看更多酒店，于是华丽丽的提了一个产品Bug（再次谢RD、设计、QA不杀之恩···）

分析原因：

虽然原因有种种，归根结底还是最简单的那句话：需求没想清楚。认真回想了一遍流程：做了竞品调研、产品方案多次评审、和设计撕扯几天，细思极恐，我还真得好好理理到底哪儿没想清楚！

Question1：你做的功能背后究竟是什么？

想起之前雪璇讲过的需求5问：用户为什么需要这个；用户什么时候需要这个；用户对入口的预期什么样子；用户对里面内容和操作的预期如何；需求是否经得起感性的体验和理性的逻辑性。

地图最关键的自动加载这事，我花很长时间想清楚了加载的效果，边界的逻辑，却偏偏把前面本质的内容没想透彻，没有用拷问的态度一遍遍去审视需求的合理性和实现方案的合理性，现在再来Review一次：

用户为什么需要自动加载？

自动加载是在用户关注某一内容并处于浏览状态时，为了减少操作成本而提供的服务

用户在地图场景下什么时候需要自动加载？

a.用户在移动缩放读取地图信息时自动加载地图信息

b.目的地比较明确的情况下浏览周围酒店时可以考虑自动加载

用户选择目的地的时候是否需要自动加载？（最大的问题点）

如果能精准命中用户的需求，当然可以考虑，但通过几轮实际效果验证后发现，其实是�有些自作聪明的设计。

我花费了很多时间细化尝试策略试图能覆盖用户操作所表达出来的意图，但是地图本身用户可操作性很大（缩放的比例、移动的距离、操作的速度...)加上每个城市不同面积的这些变量加起来，想要分清我这一次移动是为了看当前屏幕范围内的POI还是我要换一个目的地点的需求边界太困难了...

其实只要这个时候回头去想想第1个问题的答案，这个问题还是有机会可以想清楚的：用户浏览POI和用户选择目的地是2个完全不同的行为，如果用户只关注一个内容（单独浏览POI或者单纯只找目的地）时，自动加载OK。如果这2个行为可能交叉进行，自动加载明显是有缺陷的。

良心小结：真的再多想几遍，真的，真的去试着把内容抽象化思考，真的！

Question2：为何经过了多次产品评审，还是可能出来一个有缺陷的产品方案，如何错失了那些有可能纠正方案的机会？

最关键的原因分析完以后，再来看看产品方案正确性的另一道防线是如何被破掉的！

我必须承认，地图动态效果的内容远比我想象中多，它与其他列表页或者详情页的静态效果评审差异很大，这一点上在产品评审上，作为需求PM对各位参审PM的引导不够。大家在这一块上能想到的内容和问题自然也就比较少，很容易疏漏。想想平时静态的页面改版也会拿手机看看效果图，地图这东西真的可以考虑有个动态Demo。

但这部分比较重要的点就是：不要一开始就讲方案，把关于需求哪几个抽象的问题拿出来和大家讨论一下。辩一下。原因比较简单：参审的PM对需求的了解仅从你开口讲的那一刻开始，如果你先引导的是核心抽象的产品思路方面，大家可能从其他需求的经验上给你提供有价值的内容，如果你一上来就讲方案，大家自然就局限在方案细节的合理性上，可能产生的隐患是：过于细节、思考范围变窄，遇上对该模块�比较陌生的PM可能就无法帮你Review出问题。

Question3：竞品调研调研的到底是什么？

看功能，抽炼出其他竞品对那5个需求问题的回答会比一份详尽到细节的调研文档更让你收获与成长

接下来是血泪经验的小结：

1.多拷问自己需求！拿那5个问题不断拷问自己！才能让你的RD不会在开发的时候拷问你想清楚了没有...

2.抽象化的思考需求，特别是产品设计初期

3.明白做竞品调研的目的，拿那5个问题的思路去做竞品调研，会比单纯的比较页面功能比较更有价值

4.把握每一次需求评审的机会，初审审方向，复审审方案，终审过细节，你给参审的PM更大的思考空间，他们也会回馈你更精彩的产品建议

5.对于动态较复杂的需求，可以尝试花些成本在前期动态Demo上，首推Axure，另外有一个待评估的软件叫Marvel