后台都交给你了你该怎么办？（拆解复杂业务需求）

后台都交给你了你该怎么办？（拆解复杂业务需求）

编辑导语：产品经理在日常工作中面对一个业务管理系统项目时，首先需要自己搞清业务逻辑，画流程图，其次也需要团队的通力合作，完成开发的过程；本文作者分享了关于产品经理在面对后台时如何拆解业务需求的分析，我们一起来了解一下。

讲个故事：

故事背景：去年疫情期间，因个人原因我休了个长假（感谢公司），休假期间小伙伴们在加班加点地开发业务管理系统。休假回来发现折腾了大半年，管理系统还没有达到能够使用的程度，和业务方的预期相差甚远。各种原因有人的因素，也有客观因素。

总之，交到我手里一个做了一半看似能用，但是实际上无法使用的业务管理系统。

当时的情况：

• 业务方是传统行业出身，对系统操作不是很有sense。
• 各业务部门都在着急使用系统，但是无法使用，每个部门都觉得自己的需求很着急。

首先，得做一些沟通的事儿（产品干啥的？画图的？不是的，你是个润滑剂/需求全家桶，先挖一挖各方的态度和潜在的诉求）。

• 了解业务背景，过了半年业务进行了转型，需要找到各个需求方，了解目前的业务背景。
• 和产品沟通，为啥项目进度如此曲折，产品团队遇到的问题和目前有没有可行的解决方案。
• 和开发沟通，目前研发团队手头的任务，大致摸一摸研发同事的脾气，顺便也让开发了解下我的脾气（不好惹的PM）。

接下来，开始着手规划，核心的步骤是：

一、画流程图

先画出来业务流程图，这一点必须做，前置后置流程必须弄清楚，你才能更好地见招拆招；比如如果业务方说，我想知道学生的耗课。那么前置流程是学生得有排课，有了排课才能自动算出来/人工扣减耗课。

借此机会，全盘了解整体系统的功能边界。

我是教育行业的，业务流大致如下：

二、在业务图上标志出来关键节点

哪些功能是影响效率/赚钱/核心功能的，哪些功能是暂时可以使用临时方案/手动/表格代替的。目前的情况下，业务方是怎么操作的。（这里会听到业务方很多的建议和天马行空的方案）

比如订单签约功能，如果没有课程包，怎么签约？签不了，不知道卖了什么。没有课程，能排课吗？排不了，因为不知道每个课程包里面有多少节课，每个班级上多少课时都不知道。没有老师帐号，能排课吗？必须要有，因为第三方平台排课接口里面这个是必填项（有老师帐号，不代表老师的信息要面面俱到）。

三、事无巨细列出来每个模块的功能点（做加法）

这里需要PM思考各种分支流程和异常情况的处理。曾经我合作的一个架构师说：正向流程谁都会，关键看逆向流程和异常处理，这就看出来老手和新手的区别了。

画个详细流程和原型图好了，流程图起码也得长这样（泳道图）：

四、再做减法

考验PM的功力，很多时候是靠经验积累的。哪些是急需解决的，哪个业务方的需求可以先被满足（BD、运营、教学、销售、教务、外教……），哪些是现在有的，哪些是没有的。这里可以借助四象限法则。

举个例子，我们课程一共有5大系列，每个系列6个等级，每个等级有一百多节课，问题来了，这里我可以做个模块，叫做课程设置，让教学研发的同事自己增删改查。

但是在短期内系统就要上线，核心的是让销售、运营能够跑起来，那么有必须要做配置项嘛？没有。这些可以写到数据库表中，能够查询就行了，因为可能也就一年用个几次吧，性价比太低了。如果需要修改，短期内可以让DBA数据订正一下。后期等核心功能做好了，再做这种重要但是不紧急的任务。

再举个例子，老师帐号，排课的时候，教务需要查询老师的资料，光有个老师的帐号，是不能满足他们的需求的，我想知道老师上课好不好？老师有没有点评？有没有评价？这些看起来都是合理需求，但是放在第一阶段，就没必要了，后期再满足；但是老师的时间管理，一定要有，不然排课就会有冲突，已经排课的老师，无法在同时段再排课。

五、小步快跑，迭代上线

在经历了很多次的加减法之后，确定迭代需求范围。

作为一个辣手摧猿的PM（当然也借鉴了之前的项目经验），我给开发【定制了】一个清晰但是艰巨的任务。2个月搞定销售外呼、约课试听、课程设置、商品管理、订单管理、组班排课、打通在线教室、课耗扣减。每周迭代更新一次。当然，根据开发的人员配置，还是做了一个月的buff（内心OS，你看我还是个仁慈的PM）。

在以前的公司，我接手了一个课程，这个课程我们最后讨论是卖会员卡；运营说，我们可能放在XX平台来卖，也可以放在我们自己的平台卖，还可以让用户直接充值，也可以在活动里面赠送，blablabla……还有半个月的时间就要开始双11的预热活动了。

第一个版本，我没有接入任何平台和系统，我做了个手动发放的功能；不管前置的活动条件是什么，达到了条件，运营可以手动发放，等于直接躺下了；后期根据每个渠道的量，再进行了系统对接和自动发放，发放异常了也会触发报警机制。这些还是有必要的。

我喜欢把每个环节看作独立的小环节，把各个流程打散，再组合拼装起来。这种方式，能够让PM从业务逻辑中跳出来，使用程序化的方式进行思考，和程序员配合的时候，也更顺利一些，有利于推动项目快速上线和迭代。

MVP的理念，值得学习。有时候不需要面面俱到，把握优先级和核心诉求。

六、兄弟部门，及时沟通

以上的计划，全部通知各个业务部门。

每半周同步进度，邀约参与业务沟通、需求评审、测试、汇报上线进展，更新操作手册，让需求方全方位了解当前我们的情况；如果有延期风险，必须汇报，让业务方提前有心理准备，并且做好相应的预案。

很多PM不善于和业务方沟通，业务方感觉产品研发部怎么像个黑盒一样；最后做成什么样，要给业务方有预期，需要他们确认的点一定要确认。不要最后花费了很多力气做出来，变成了扯皮背锅。

总结，今天说了很多，PM要理解需求，更要理解背后的商业逻辑和需求背后的人。

PS：给新手产品经理提个醒儿。

• 会画流程图，流程图不仅仅包括流程，还应该有角色，状态变更的触点；
• 多和开发、需求方聊天，摆事实讲道理，为什么我这么做，如果我这么设计了，你们后续遇到问题需要怎么解决，方案是blablabla，大多的需求方还是讲道理的，提前告知项目风险和进度；
• 一定要懂一点技术术语，才好和技术进行更多的沟通；学会阅读第三方的技术文档，根据技术文档可以初步判断功能是否可以实现，建议阅读接口文档，可以找微信的openapi文档读一读。

作者：克里斯多陶；微信公众号：克里斯多陶，高级产品经理，8年互联网产品设计经验，营销产品经理，教育产品经理。

本文由 @克里斯多陶 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。