场景化思考：如何提升产品规划和业务模块化能力？

2017-08-17 09:44 来源:人人都是产品经理 设计 /操作系统

原标题：场景化思考：如何提升产品规划和业务模块化能力？

文章从客服系统业务的查询功能问题延伸，主要探讨产品规划和功能模块化设计的相关问题，希望对你有益。

本文源于一个产品问答问题，然后延展到产品规划和功能模块化设计。原问题如下：

客服系统中的业务查询模块该谁做？

大家都知道客服系统中很重要的一个模块就是业务查询，帮助客服查询用户的各种信息，来辅助客服帮助用户解决问题。

现在遇到的一个问题是，公司的业务模块多元，而且变动也十分频繁，目前是客服部门来做各种业务查询模块，导致客服部门的产研日常疲于应付各种业务查询模块的开发。

这个问题表面是客服系统业务查询功能问题，背后深层次的问题涉及产品规划、分工，以及业务功能模块化设计。

本文上半部分先来回答”客服系统业务查询模块该谁做”的问题，然后下半部分聊一下产品经理如何做产品规划和功能模块化设计。

问题包含2个要素，一个是客服系统，另一个是业务查询模块。

首先，客服系统怎么来？一般有点规模的互联网公司，都是自己开发并维护客服系统，有对应的客服系统产研团队。一些小公司，或者传统行业的公司，客服系统是买来的，没有客服系统开发资源，顶多设立个IT支持部门，做一些客服系统日常维护运营工作。

下面回答仅针对第一种情况，这个公司有产研实力开发客服系统，上线新功能。第二种情况，传统公司买来的客服系统，一般设计都会比较完善，业务查询功能基本是标配（否则系统卖给谁？），如果有了新需求而原有系统无法满足，直接找供应商解决问题即可。

其次，业务查询模块，这个不仅在客服系统有，j2直播，业务部门自己的运营后台也需要有业务查询功能，业务比客服更关心业务情况。所以，业务部门自己的业务运营后台肯定已经开发了业务查询功能。

无论是大公司，还是小公司，业务部门都会开发业务查询功能，这个模块首先会放到运营后台。如果客服部门需要，不用重新开发，业务部门提供业务查询API接口即可，客服部门调用业务查询接口在客服系统实现业务查询功能。

最后，具体分工就是，业务查询功能逻辑、接口由业务部门开发并提供，客服系统只需要做个界面，调用一下接口即可。

产品规划和业务模块化设计

刚毕业做产品经理的时候，我们部门的产品老大窦亮亮说过一句话，我特别认同，”产品经理的核心能力，除了要考虑用户体验、产品设计以及按钮位置的摆放，更重要的是把整个业务链条搭建起来的能力”。

1.功能拆分

那么，一个完整的业务系统，一定涉及到很多模块，包括不限于：用户系统、运营后台、财务系统、法务系统、客服系统、数据统计等。作为这个业务的产品负责人，在规划产品的时候，就必须把业务运转的整个流程和关键节点考虑进去，拆分业务流程，进行模块化设计。

今天聊的是按照【用户角色】进行的功能拆分方法：

用户信息相关的放到用户系统，再细分可以把用户信息拆分成账号系统、会员系统等模块。运营人员用的运营后台，虽然运营后台不直接面对用户，前端界面不用过多雕琢，但是如果运营后台做得不好，不仅运营会整体骂产品经理，而且也会因为工具不好用，而影响整个团队的工作效率。

所以，一般不受部门重视的运营后台，产品经理一定要用心去做，多花点时间在别人看不到的地方，最终带来的成果大家是能感觉到的。

还有按照财务、法务、客服和分析师各种角色设计拆分的业务模块：财务系统（很多公司财务系统是买的）、法务系统、客服系统和数据分析系统。

在产品规划的时候，就要有业务模块化的意识，不要把一堆功能需求揉在一起做，那样会思路不清逻辑混乱。

2.落地实现

大体的产品框架设计好了之后，就需要按照优先级进行排期，制定合理高效的开发计划和迭代周期。

这里简单说一下开发步骤：

idea产生—需求分析—项目评估—PRD撰写—需求评审—开发测试—发布上线—运营监控—项目效果后评估。

产品经理的墨菲定律：实际上线的功能和时间点，往往小于当初的产品规划。