平台型产品功能设计的需求抽象与升维适配|宜信郭建伟

Posted 2020-11-27 yixinjishu

摘要：平台型产品经理需要具备“对业务的结构化理解”，“先抽象提炼”再“反向适配具体业务需求”。

---

 

前言：宜信技术人物专访是宜信技术学院推出的系列性专题，我们邀请软件研发行业的优秀技术人，分享自己在软件研发领域的实践经验和前瞻性观点。

第五期专访我们邀请到宜信科技中心普惠金融需求管理部负责人郭建伟，以“平台型产品的功能与体验设计”为主题，围绕宜信的产品开发实践，分享平台型产品经理的工作经验和能力要求。

嘉宾 | 宜信郭建伟

记者 | 宜信成芳

本文为采访实录。原创内容，转载请留言获取授权。

记者：郭建伟老师您好，今天我们的采访将围绕“平台型产品的功能与体验设计”展开。业务模式的变化会对产品产生升级改造的需求。请您结合宜信的具体实践，介绍在业务模式发生颠覆性创新的情况下，平台型产品团队该如何处理跨多平台融合、多团队沟通的复杂问题，从而顺利推进和实现平台产品升级？

郭建伟：正好在宜信的这段工作经历中，参与过一次公司战略级的业务模式创新项目——火凤凰项目，将网贷业务中间人模式升级为直接借贷模式。有一些经验体会可以分享给大家：

首先，要明确自身在项目中的定位，目标清晰。通常业务模式升级类项目都是公司级项目，参与部门比较多，产品团队和技术部门虽然是落地过程中最重要的一环，但一般还会涉及公司内一系列系统外的工作推动，甚至外部合作方、监管机构的协调，往往不会由产品团队或技术部门来主导，所以要明确自身在项目中的角色，充分理解项目的业务目标，转化成具体的系统建设目标，并以此在项目前期和需求方达成一致，这是明确项目范围、管理预期的关键，也是系统建设的基础；

其次，是对旧业务模式、历史数据的兼容问题。在重大业务模式升级的项目中，对于平台型系统而言这是关键问题之一。这个方面我有两个体会：

• 要进一步细分兼容问题的类别，缩小范围、制定差异化解决方案，来降低兼容问题的复杂度、工作量。参与过类似项目的同事应该都会有这样的体会，对旧模式兼容、历史数据处理的工作量，完全不亚于投入在新模式建设上的工作量，所以作为负责人，优先考虑的不是“硬刚正面”，而是“战略性回避”，适当拉长新旧过渡期，在项目既定周期内，让团队聚焦新模式建设，为后续存量处理留出工作空间即可；
• 与业务团队沟通讨论，充分挖掘业务方在存量处理上的作用。技术团队往往第一时间考虑的都是技术解决方案，但在存量处理的问题上，处在更上游的业务方的一些小变通，往往能给我们提供非常有效的支持，不要一味只在下游、自己熟悉的范围内寻找解决方案，最优方案往往需要上下游协同。

最后，是试点支持的重要性。不论业务方是否要求试点，不论对自身研发、测试团队的能力多有信心，我的建议是面对大型业务模式升级，对试点功能的支持都是必不可少的。在IT层面，是对系统功能升级的验证，控制影响范围、监控性能问题等；在运营层面，新模式一方面平滑推广，一方面在逐步推广过程中，会持续调整，推广的过程也是一个收集反馈再升级的过程。

记者：有一种分类方式是将产品经理分为平台型产品经理和业务型产品经理：平台型产品经理主要对接开发、测试、设计团队，满足to B的需求；业务型产品经理主要对接市场、销售、运营团队，满足to C的需求。您认为在具体的产品工作上，这2类产品经理的区别是什么？

郭建伟：我认为面向C端的业务产品经理最重要的是“对客群理解”，核心工作内容是通过产品的调整，增加“客群”与“产品”的匹配度。客群的特点与痛点是C端产品经理工作围绕的中心，并以此调整自己的产品；相反固守自己产品，而去不断教育用户、创造需求，成功的例子并不多。另外往往我们的产品经理并不是自己产品的目标客群，跳出自己的认知习惯，去精准把握另一个群体，是C端产品经理的重要能力。

B端平台型产品经理最重要的是“对业务的结构化理解”。这是我个人的一个说法，从这里能看到两个层面的含义。一个是要对某“业务”领域知识足够熟悉，这是平台型产品经理的工作前提；另一个是“结构化理解”，也就是抽象能力，需要我们具备基于对业务流程的认识，抽象为对业务模式的结构化理解，这是平台适配性、扩展性的关键所在，是平台型产品经理的关键能力。

记者：宜信科技中心坚持以“科技赋能业务”为核心理念，作为平台型产品经理，该如何将业务需求转变为产品功能需求？

郭建伟：我认为“科技赋能”要根据不同业务所处的不同阶段，采取不同的“赋能”方式，大家常看到由于技术落后业务发展进程而产生的问题，而容易忽略技术过于超前同样会引发问题。

一般情况下，我把“赋能”分为多个阶段：

• 支持阶段，这个阶段一般在业务的起步期，业务流程不稳定，需求变更较多，系统的按时交付、保障业务开展是这个阶段的关键。
• 提炼阶段，这个阶段一般业务进入发展期，业务流程逐渐稳定，平台建设的技术团队对业务形成一定理解，进入对业务抽象提炼的阶段，这个阶段的目标还是通过对业务的理解、抽象，更好地建设系统，以适应业务的发展，着眼点还在系统提升本身。
• 赋能阶段，这个阶段业务已经持续发展，业务量稳定，业务本身促进增长方面出现瓶颈，需要技术不仅仅是在效率、自动化方面支持业务，而是基于对业务的理解，直接着眼业务，结合技术手段做出改进提升；
• 引领阶段，我认为并不是每一项业务都适合、或都能够进入到技术引领的阶段，处在这个阶段时，将打破“业务”与“技术”的边界，技术变革做出的引领，本身就是业务的一部分。

记者：您在之前的分享中提到：产品经理不仅要能满足当前业务需求，还要能够基于当前需求进行抽象提炼，要超前业务做面向未来需求的产品。要做到这一点，产品经理必须具备什么样的能力要求？如何做到抽象和洞察未来需求反向适配业务？

郭建伟：我一直反复地和团队的平台产品经理强调一句话：系统建设不是照搬业务流程实现自动化的过程，而是先对业务流程做抽象提炼，再去反向适配具体业务需求的过程。这个认识也一直指导我在宜信的每一个系统建设工作。

抽象能力无疑是平台产品经理最关键的一项通用能力，谈抽象能力时，我常提的一个通俗例子就是“客户要一匹更快的马，我们应该给他一辆车”。这个例子中，一方面体现产品经理对客户真实需求“更快到达”的挖掘；

另一方面也体现了抽象作用，之所以从“要马”到“给车”，中间其实是有一个抽象升维的过程，就是抽象成“交通工具”，再从“交通工具”降维到“车”，这恰恰就是上面的“先抽象提炼”再“反向适配具体业务需求”；

另外这里我还强调我们能顺利完成抽象、适配，其实还得益于我们对“交通工具”领域常识的了解，如果这个例子换到医疗领域“客户要某药品A，我们应该给他另一药品B”，如果我们不具备病理、药理的领域知识，就无法完成抽象、适配。所以“业务领域知识”+“抽象能力”都是平台产品经理的重要能力体现。

记者：关于to B与to C的产品功能设计，一直有一种说法是：to B重功能，to C重体验，您是否认同这种说法？平台型产品的用户体验设计主要体现在哪些方面？

郭建伟：前面提及了C端产品经理和B端产品经理的区别，这里我简单谈一下我对用户体验的理解。

对于平台型产品而言，谈“用户体验”时，我们谈的并不是界面美观与交互流畅与否，而应该是“用户是否能更便捷达成他的期望”，所以“用户的期望”才是用户体验的核心。

举个简单的例子：一个界面美观、交互流畅、动效酷炫的纯手工功能，和一个界面粗糙的自动化功能，对于B端用户来说，会毫不犹豫选择后者，因为那更贴近他的“期望”。在这个理解的基础上，再去考虑提升界面美观、交互流畅等，这是B端产品经理应该注意的。

记者：随着“中台”概念的兴起，“产品中台”也随之被提出，该如何理解“产品中台”这个概念？您认为产品经理的工作是否适合于中台化模式？

郭建伟：中台建设我并不专业，宜信科技中心有团队专注这个领域，我简单说说我自己的一些认识。

首先，中台概念的兴起是和业务量级密不可分的，并不是所有业务都需要中台，为了建设中台而建设中台是没有意义的；

其次，中台是和组织结构有关联的，中台建设本身也在促进“组织分层”，以便进一步在各层配置不同的能力模型和资源，各层或分散、或集中，达到提升组织整体运营效率的目的；

最后才是系统建设方面，避免重复造车轮，增加系统共用，降低成本，加快业务需求交付速度等等。

记者：对于想要转型或刚刚从事平台型产品经理的同学，您有什么职业成长方面的建议想跟大家分享？

郭建伟：B端产品经理的工作相比C端产品经理工作，有些枯燥，所以

首先，大家要有耐心，不断学习积累。

其次，要加强业务领域知识的学习，行业领域知识对B端产品经理的重要性，要高于C端产品经理，择业时尽量注意在某一大领域内选择；

最后，不论是哪种产品经理、哪个行业，产品经理都应该是善于发现问题、解决问题的那类人，所以保持好奇心，勤于思考，提升商业敏感度是非常重要的。

希望大家除了在自己工作中是个合格的产品经理之外，动用产品经理赋予你的种种，让自己在“职业道路”、“人生道路”这个产品上，也能成为一名合格的产品经理，谢谢大家。