在日常工作中，产品经理可能需要多做抽象集成和分析，进而尽量减少功能的个例使用频率。这篇文章里，作者就做了举例说明，不妨来看一下。

一、概述

产品功能抽象能力是指将某个例用户提出的需求，通过分析核心诉求形成通用的模板，之后其他用户的需求可以在此基础上进行复用或者拓展，不做一次性功夫。

二、举例说明

在做OMS系统的过程中，因为对接的上游电商平台和ERP繁多，上游透传的字段也不胜枚举，商家的各种需求下来都需要在我们系统进行存储+搜索+展示，这种情况下如何能够将这些庞杂的字段做一个统一的处理呢。

以某电商平台举例，不同系统在页面透出的单据类型不同，如物流部门在处理客诉工单时，携带的是A正向履约单号；在商家界面处理售后透出的是B单号；而在给服务商下发正向销售单时给的是C发货单号，A和B都放在C的扩展字段中作为关联。

当上游电商平台通知服务商处理某具体单号的客诉或者商家需求时，需要服务商能够根据存储在扩展属性中的A单号和B单号，找到对应的C单发货单及服务商系统内的关联单据（运单、清单、交易单等）。

在这个例子中，我们可以抽象出来，对于我们OMS系统来说，影响C单业务主流程的关键字段是C发货单号，那这个单号就作为一个主字段单独存储，以【外部单号】或者【全局单号】进行命名，方便识别；数据安全方面，在做搜索的时候也需要支持精确搜索。

而A单号和B单号，他们的主要应用场景是作为沟通使用，在OMS系统中的关键能力是支持搜索展示，那么这两个字段就可以放在同一个字段中，如【外部关联单号】中，以“，”分隔展示，支持模糊搜索；而不必要在我们OMS系统中单独命名两个字段A和B作为承载。

这样做的好处是，我们脱离了某特例电商平台的字段进行设计，而是提供了一种普适的方法。之后对接其他的平台时，业务主单字段都可以置于【外部单号】／【全局单号】中；而其他上游推送过来，对实际业务没有影响，但是有搜索查询能力需求的字段，都可以打包塞到【外部关联单号】中统一存储。

三、总结

由此引发的思考是，产品做细节的时候要多做抽象集成和分析，尽量减少功能的个例使用频率。