一、发现问题

发现问题通常有以下三种方法：

1. 线上效果评估

线上效果评估，最常见的方式是：利用随机查询集合，逐个在线上检索查看质量。

若为了更快更明显的看到问题，通常会和竞品进行比较。很多时候，竞品的做法或效果，未必是最好，为了从理想角度探究效果，我们也采用以理想为标杆的对比和发现问题。

这种方式的好处是：全面发现问题、问题影响面客观、容易量化，例行开展还可以进行历史数据比较，观察产品的变化情况；而问题是，线上整体效果越好，发现问题需要花费的力气就越大——即发现问题的效率非最高。

在以评估为手段的问题发现中，PM需要清楚把握用户需求，根据线上实际效果，对用户的满足状态给出判断，需要给出每次查询用户面临什么样的问题，以及严重程度。

2. 线上监控

在网页搜索技术分支增加、策略日渐复杂的趋势下，人工去排查系统每个模块给用户带来的影响，是一种非常不经济的方式。线上监控作为一种自动、实时、针对效果的问题 发现方法，日趋重要。

其中，自动是指利用机器去执行；实时,是可以持续不断地对效果进行监控，且能在问题产生第一时间获知。自动和实时，都大大减少了人力成本。

针对效果是指：针对实际用户感受（或影响因素）进行监控。

监控的问题是：精度有限，特别是针对网页搜索效果的监控精度，提升过程比较缓慢。所以，目前的监控，还比较多的停留在一些相对粗粒度的统计指标。如：autorank、位置点击率、结果/站点展现、站点导流情况等。

也正因为精度有限，监控往往难以直接定位问题，而是和其他人工手段配合确定最后的问题。

PM在监控工作中的职责，主要体现在：将“用户感受”的每个影响要素进行拆解，并找到相对独立的、可机器量化的指标，这些指标往往就是监控点。

比如：建立衡量线上检索效果的autorank监控，pm首先要清楚，结果好坏会在哪些方面体现——比如结果相关度权重、资源质量、用户搜索/停留/点击行为等等。

接下来，结果的相关度权重、资源质量判断，准确性依赖现有策略，策略效果会直接影响监控的有效性，所以效果监控不适合将以上两点作为监控指标或主要监控指标。而用户行为这个指标相对独立，受扰动因素较小，所以合适作为监控指标，这也是前面强调独立的原因。

3. 平时产品使用中发现的badcase

——即我们平时说的报case。

这个方法发现的问题，来源于平时的个人使用中遇到的体验较差或不合预期的查询。在过去很长一段时间内，case驱动成为网页搜索改进的重要途径。

这种方法发现问题，有个明显的缺陷——即随机，发现问题难以全面，且难以量化，难以得出问题在线上的整体影响面。但是，对每一个问题的深入分析，可能帮我们发现用户体验上的明显问题，或找到系统中的严重症结。

涉及分析的内容，会在下文展开。

以上，是发现问题的三个主要方法，作为PM产品工作的第一步，掌握发现问题的方法，保证不偏不漏，这是非常重要的。

二、提出、描述问题

把问题描述清楚，需要做好两方面：一个是对问题的衡量，一个是问题的解决预期。

1. 问题的衡量

首先，问题的衡量需包括：

问题的广度：指问题产生了多大范围的影响，在网页搜索，这个范围影响，通常用收到影响的查询占比来反映。

问题的深度：即该问题对用户体验造成伤害的程度。

这个点上，不太容易有量化的衡量，但对严重问题的判断，仍有一些原则可以遵循。如：很多用户每天通过aladdin结果来获取股票信息，而突然某一天，股票aladdin结果消失，这个就破坏了用户稳定的预期。

再如：搜“新浪”，出“搜狐”结果，也难以让人接受，这是因为超出了用户的理解范围；而在某些spam问题上，破窗效应导致对用户体验威胁加重趋势明显，也应算在严重问题范畴内。

2. 明确解决预期

其次，明确解决预期，也需要基于两点：

1）理想情况的描绘

提出问题只是第一步，这个问题上要做到什么效果——即目标是什么，也需要pm有清楚的判断。只知道问题而不知道效果目标，工作无法有效开展。

2）理想情况是一回事，能否达到是另外一回事。

因为理想情况的实现会受到很多因素的限制。有不低比例的查询，因为话题过于冷僻，互联网几乎不存在与之匹配的资源。

在资源到位之前，一味的要求相关性提升是不合适的，这样很容易造成rd（特别是没经验的rd）辛苦开发了很久，却对效果没有帮助。而目标调整为，保证有资源的查询效果提升或至少要召回google能召回的好资源，这样就合理很多。

在实际工作中，我们往往对问题衡量做的较好，而对解决预期重视不够，这就是为什么有些pm觉得做完评估或调研工作就结束了，或者觉得自己难以给出优先级判断。缺乏对问题解决的合理预期，会导致PM难以进行后面的工作，无法形成完整产品循环，还会导致RD对需求/目标的理解有偏，资源投入和实际产出不匹配。

三、判断决策

1. 两个问题

方向或策略定位问题和目标清楚之后，PM还应主导回答两个问题：该策略/方向定位是什么，解决什么问题？ 该策略/方向不解决哪些问题（或什么情况下不必发挥作用）？

第一个问题想必很多PM都是可以回答的，而主动思考第二个问题的人却并不多。缺乏对第二个问题的思考，会导致pm对策略/方向的认识不完整，以及在后续执行过程中，偏离目标、工作开展失控。

举两个例子：

第一，地域扩展策略。

要解决的问题是：同一查搜索词下，不同地区用户的目标结果不一致的问题，如“招商银行网点”。根据该问题表象，可以提炼出对搜索结果有本地域需求的查询。

其解决思路是：在这类查询下，基于用户地理位置信息，插入与用户地域匹配的结果。在这个定位下，“北京招商银行”，也是地域扩展策略的目标查询了。

如果再补充一个问题，地域扩展策略不影响什么样的查询，在一定量的query标注后就会发现：“北京招商银行”这样的查询，意图非常清楚，和用户所在地域没有关系，没有必要进行地域结果扩展。这个时候，我们可以及时对地域扩展策略的定位进行“修订”——即对有潜在本地需求的查询，提供地域差异性结果。

第二个例子：检索扩展提示。

改功能其中一个定位，是当用户输入存在非常用写法或错别字的时候，给予提示，使得用户避免query改写操作，找到更理想的资源。

如果没有“不做什么”约束，检索扩展就很有可能出现这样的问题：

例如：

query“谍中谍4” ，检索扩展提示：“您要找的是不是：碟中谍4 ，搜索结果页地址。”

该query命中非常用写法的条件，但是结果非常好，不影响用户找到所需资源，此刻提示的价值就非常小了， 且这种提示的价值，相比对用户注意力的干扰不值一提。

基于这类case，检索扩展的这个定位可以完善成“是当用户输入存在非常用写法或错别字导致结果不佳的时候，给以提示，以使用户避免query改写操作，找到更理想的资源。”

补充一句：“不做什么”这个问题的答案，有可能依赖PM产品经验或良好的用户感觉判断，对于一些新人，也可以通过一定量的数据分析找到。

综上，弄清两个问题，明确策略/方向定位，背后是这样的产品决策原则：任何问题的改进，都应明确在一定的范围内，不应对问题范围外的点所有不必要影响。而这两个问题的答案，需要在项目启动前明确，并向RD进行清晰传达。

2. 优先级

优先级的判断，一般项目来说，比较性价比是比较有效的办法。在问题或需求描述的环节，PM应该就改进空间给出说明，同时RD会给出解决方案需要的代价。

这里的收益空间不仅仅是影响广度，很多问题的影响面非常小，但是对用户或对生态产生持续（或深刻）消极影响，且这种消极影响会以难以控制的速度扩散，spam就是典型的例子。

还有一些情况，需要做短长期的权衡，比如：一些符合趋势的改变，即便现在的面很小，也应该酌情提升优先级，以避免将来应对不够及时。

3. 方案的风险判断

策略型PM最容易看到的是效果上的的风险，除此之外，用户习惯和感知、系统复杂性、随着时间推移的可扩展性，也应在考虑范围内。

举一个感知风险的例子：我们系统中有很多需求改写策略，这些策略的原理，是通过挖掘用户行为或语料，得到一些query之间的信息。在用户搜索时，在结果中插入相关query的结果（如同义词结果），来召回更多相关结果。

在query与资源的相关性判断中，可能不会有什么问题，但是在结果摘要展现时，若同义词和用户输入query在字面上相差较多，会有不飘红的情况，第一眼看上去非常突兀，这会导致用户在看到结果时，付出较多的反应成本。

而系统复杂性和未来的扩展性，虽然PM无法直接回答这些问题，但是需要通过提醒和追问的方式，让RD去进行相应的思考。

4. 阶段性效果衡量

在提需求的时候，我们已经描述理想状态了，但是在实际开发过程中，由于技术上或数据上的种种原因，很难一次性做到完美，针对阶段性工作，PM需要给出衡量方式。而衡量的途径，就是制定标准，给出不同程度的效果的定义，在这个基础上量化工作效果。

四、推进落实

策略型PM在这个环节事情相对简单，主要是保证关键时间点确认，及时和RD了解困难，从用户角度提出一些思路建议，必要时，积极争取资源解决困难。当项目进行中发现目标需要调整时，PM需要及时组织沟通，重新制定目标和衡量方法，让参与同事达成一致，并形成正式通告。

对于项目中增加新成员或负责人转手的情况，PM也需要推动或落实背景和目标的传达，确保项目执行中没有偏差。

五、效果确认

这个环节主要是确认效果和风险，评估标准应与前面按目标制定的评估标准一致，此环节的工作会决定策略上线或进一步迭代。同时，对于影响面大的策略，最好再次review风险

六、开始下一次循环

每一次改进的上线，形式上会让人觉得事情做完了。但是，除了问题修复类型的工作外，对于一些持续改进的方向，还需要事后的监控机制。

这个不仅是对项目上线后线上效果的再摸底，也能使得pm对该类问题能够做到长期心中有数，且持续的监控，也是保证问题及时发现不遗漏的方法，参见第一环节。

七、其他

负责一个产品的PM，要清楚把握一个产品不同的发展阶段——即产品周期。

同样地，策略型PM，也应该清楚每个策略的发展周期，包括：策略目前在线上发挥什么样的作用？是否要做进一步的深化或扩展？外界变化或内部其他替代性策略/功能的上线会对策略的贡献有什么样的影响？这个策略接下来应做如何调整，改进升级，或是收敛投入，甚至下线？