既然方法论这么重要，那我们如何获得方法论呢。

所谓“真正获得”指的是不仅知道方法论的意思，还得从骨子里相信，并且在日常的工作中能够自然地不断指导自己的工作，让方法论对自己的日常产品工作产生真正的帮助。

对于方法论，我们是仅仅认可某个方法论，还是真正的相信它，这两者的区别其实很大。

比如我们都知道“过马路要注意安全”，但很多人并不是骨子里真正的相信，这也就导致了很多人还是会在过马路的时候出现玩手机，不看红绿灯等行为。

在日常的工作中，有这么一个工作的模板可以帮助大家建立自己的方法论，那就是“事前详细评估”，“事中不断反思”，“事后总结复盘”。

事前详细评估

就是在项目开始之前，需要不断的收集数据和信息，尽可能的收集全面的信息，这样才能保证方法论的应用是正确的。

这个重要性我相信是不言而喻的。

举个例子来说，你熟知前面列举的用户体验的要素这个方法论并且始终践行，任何事情哪怕细小的功能都会努力思考其在战略层和范围层的位置。

但很可惜的是，你连自己产品的用户是谁都没了解清楚，明明使用对象都是四五线的小镇青年，可偏用自己在一二线城市的白领生活习惯去做战略层的分析，这样能得出正确的结论吗？

收集足够且全面的数据确实是很难的，但这其实已经是在培养方法论的三个环节中，最简单的事情了，因为它有迹可循，只要足够细心，用心的初步锻炼的就能做到。

比如，当你接到一个新任务并且准备开始收集信息时，可以看看之前类似的任务收集了什么信息和数据，可以上网查查类似的任务大家都在关注什么，也可以多和有经验的同时聊聊，让他们帮助你打开思路。

我们还是以一个具体例子来帮助大家理解该怎么去收集数据。

假设你接到了一个任务，需要调研一下“元宇宙”这个概念，并且判断一下“元宇宙”这个概念是否可以与公司当前的产品结合，你该去收集哪些信息呢？可能有几个方向：

元宇宙是什么。你可以通过上网张贴百度百科或者维基百科对于元宇宙的定义，也可以找到相关文章，书籍进行定义的摘录。

元宇宙的起源。元宇宙这个概念为什么会兴起？历史上有哪些近似的概念，在历史上的表现是什么样子的。

元宇宙的实践。当前市面上有哪些元宇宙的产品，哪些公司在这个领域投入的最多，他们的投入和产出情况是什么样子的。

元宇宙的用户。什么地域什么类型的用户对于元宇宙这个概念接受度比较高，未来潜在的目标用户还有哪些，市场有多大。

元宇宙和自己公司当前现状的结合。自己当前的公司有哪些优势适合做元宇宙，有哪些不足和挑战。

收集了以上的信息之后，怎么判断信息是不是足够呢？可以上网把当前和“元宇宙”相关的热点信息与新闻都读一遍，看看是不是有一些信息没有被包含在内；也可以找相关的人进行沟通，看看他们感兴趣或者想知道的信息还有没有遗漏。

在收集信息的时候，需要尽可能去收集“全面”的信息。请注意“全面”这个词，它并不等于“全部”。

因为受限于时间，精力，和信息闭塞的存在（比如很多非母语且非英语的信息，中文阅读者就很难获得），我们永远也没法做到收集“全部”的信息，但“全面”则是要求对于决策有影响的关键信息，是应该在收集信息的时候应该具备的。

有了事前收集的信息之后，我相信大家都会依据信息做出决策。

但如何保证决策能够高质量的执行呢？就是“事中不断反思”。

事中不断反思

需要在项目中不断的思考当前的状况和初衷是不是仍然一致，以及目前突发的变化该如何应对，要保证这些变化不影响自己基于方法论的整体设计。

我们还是以“购物车”这个功能来举例，我们最开始收集的信息可能非常全面，所做的规划也非常完美，产品文档的设计无可挑剔。但即使这样，在项目进行中也可能会遇到各种各种在一开始大家都想象不到的阻碍：

“开发的时间不够了——在这一期购物车里面的商品只能浏览，不支持用户在购物车直接下单”——你的技术同学可能会提出这样的要求。

“微信支付和支付宝支付的手续费太高了，我们也没时间去审核合同，购物车里面的支付就只支持银行卡直接付款吧” ——商务或者财务同学可能则会提出这样的要求。

当然了，作为一个合格的产品经理，你可能已经意识到，这些要求无论从哪个方法论上去分析都显得不太合理，它们会违反你的最开始的战略假设（购物车里的商品不能直接支付会极大的影响订单成交）；或者会增加用户极大的替换成本（不能方便的支付会使得用户放弃使用你的产品）。

于是你想了办法去摆事实，讲道理，终于拒绝了这些同学的不合理要求，继续按照正常的预期推进项目。

但随后你可能收到了老板的直接反馈“我对购物车功能没有太大信心，你同时做一个收藏按钮吧，让用户有多种选择”。

这个要求似乎也能帮助订单的成交，能实现带动收入增长这个大的战略，所以看起来没问题是吗？

答案当然不是，在框架层就遇到了阻碍，因为这两个功能如此相近，会导致功能的重复，也会给用户带来困扰。

但假设老板的需求你作为产品经理不得不做，那怎么办呢？

我们还是回到框架层来重新设计。比如弱化某一个功能，把收藏的功能放到另一个页面上；再比如对不同的用户上线不同的功能进行尝试等等。

总之重要的是，这个时候必须要不断反思和调整自己方法论了。如果不进行反思和调整，很可能往下走着走着就面临越来越乱的功能设计和功能堆砌，最终影响了核心目标。

“事前详细评估”和“事中不断反思” ，都是在帮你打下形成方法论的土壤，让你可以有成功以及成熟的项目作为支持方法论的总结。但如何真正的形成方法论，如何迭代自己的方法论，就需要“事后总结复盘”了。

事后总结复盘

还是以“购物车项目”为例，让我们看看如果购物车功能顺利的上线需要事后复盘什么。

在结果上，需要复盘订单量和收入有没有按照预期的增长，这是购物车上线最重要的战略目标。如果自己App整体的订单和收入因为购物车的上线产生了增长，就可以证明在战略层面的思考没有发生大的偏差。

在过程上，需要研究用户在不同业务的浏览行为是不是有变化，这些数据是贯穿用户使用这个功能始终的。比如页面的浏览时长，不同页面的转化率，购物车这个功能的点击量和使用量，商品添加的数量，购物车产生的订单量等等，这些数据都有一些分析，就能基本地反映出每个节点的设计是不是有缺陷，当时的细节思考是不是足够。

用户的反馈有哪些。有些并不是数据能直接反馈出来的，比如很多功能的替换成本很高，但由于你下线的老的功能，App上只有新的功能，所以用户不得不用，这个时候使用率这样的数据还是会很高。但如果去收集用户的反馈，则可以通过调研收集的信息得到更多的分析依据。

除了对于项目的思考以外，最重要的是在这个项目中，自己有哪些思考被实践证明了是对的，哪些思考被事实证明需要被调整呢？

比如你沿着“战略层”“范围”“结构”“框架”“表现”这一个思考路径设计出了方案，但在战略层思考的时候忽略了当前公司的财务状况和融资环境，换句话说老板可能不需要这么完善的功能，需要一个能够快速上线的功能去支持下一轮的融资。那有了这个复盘和总结，在下次设计的时候就要记得把这些因素考虑在内了。

正如在前面文章中提到的，很多初级的产品经理会把项目上线当做一个终点，仿佛上线后就万事大吉了。

但其实在我眼中则正好相反：项目上线只是一个起点！是一个开始验证产品经理决策和判断是不是正确的起点。

不断通过上线后的产品表现去反思和总结，无论是产品未来的迭代，还是对于产品经理自身的发展都是至关重要的事情，这也决定不同产品经理成长的快慢。

转载保留链接！网址：http://blog.rlidc.com/post/1359.html