面对日常工作中层出不穷的问题，如何高效解决问题并避免无休止的返工？本文将为你提供一种系统性的思考框架和实际案例。

　　从前，有一个国王，他养了一头大象。这头大象非常庞大，力大无穷。有一天，国王突发奇想，想考验一下国内的盲人，于是命令他们来摸大象，然后描述大象的样子。

　　国王听了盲人们的描述，哈哈大笑，感叹道：“你们都只摸到了大象的一部分，却没有一个人知道大象真正的样子。”

　　它告诉我们一个简单的道理：不能片面地看待以及解决问题，而是需要看到整个系统后，通过系统性的解决方案去解决问题。

　　2021年时，我新入职一家知名教育企业做产品，我们有直播课业务、素养课业务、进校业务等多条业务线，所以采取的产品模式是【中台+业务方】模式。中台负责统一建设共性产品，而每个业务线基于自己的业务需求，基于中台产品之上进行迭代。

　　业务层：都是复用中台能力，包含用户中心、教务系统、课程中心、订单中心、供应链系统、数据平台、权限系统等；

　　应用层：基于中台能力之上，进行适度自研，包含销售转化平台、辅导老师工作台、教研系统、编程IDE平台等；

　　用户层：也是基于中台能力之上，进行适度自研，但复用主系统的品牌流量，包含公众号矩阵、学员App、学员PC和iPad端等。

　　以我所在的素养业务线为例，我主要负责辅导老师工作台，它是基于中台能力之上进行研发的模式，当我调用与梳理好需求，准备落地时，却发现这种模式的弊端。即几乎每个需求都需要中台研发同学的参与，因为数据、产品架构都是中台在存储与控制。

　　比如辅导老师工作台的学员列表显示的是全部学员（包括在读以及退课、转班等），而辅导服务只针对在读学员即可，至于退课、转班等失效学员，期望可以剔除。

　　选择一：像姥姥/姥爷一样，每次都弯下腰帮他系好，这是症状解（即从问题的症状入手解决问题，治标不治本）。

　　选择二：像妈妈一样，每次都耐心教他系，有时学不会，无奈可能会自己动手，直到他自己学会为止，这是原因解（即从问题产生的原因入手解决问题）；

　　选择三：像爸爸一样，买鞋时，直接买那些不需要系鞋带的鞋，这是根本解（即从问题产生的根本原因解决问题，也叫系统性解决方案）。

　　我们日常有句话叫“求之于势，不责于人”，而对于系统性问题，咱们可以叫它“求之于系统，不责于人”。

　　系统 = 目标 x 要素 x 连接关系。所以系统性解决方案的本质，就是从目标和连接关系入手解决问题，而不是指望其中的要素（如人）的改变。

　　我方目标与中台目标是有差异的，是单一业务线与多业务线需求重心不同所带来的优先级判断的差异。

　　双方都在“争夺”中台产研资源的话，你的解决方案，无论是期望业务方产研人员的努力（如找领导或产品求人），还是中台产研人员的善良（如把你的业务需求当做自己的事情），都无法有效解决问题。

　　：要素/变量之间的因果传递关系。比如你解决辅导老师的问题越多，他们越满意；反之，则不满意；

　　：又叫正反馈回路。比如你提升了辅导老师人效，用更少辅导老师服务更多学员，降低了企业的服务成本，增加了企业营收，而增加营收后，就可以投入更多产研资源，让你可以更快速解决辅导老师的人效问题；

　　：又称负向反馈回路。比如你可以提升辅导老师人效，但不是投入越多产研，就可以降低更多成本，而是会有一个瓶颈存在，最终导致你投入大，而收益变小。

　　：所有事情都会有一个时间周期，就像种树一样，十年才能成材。比如你投入产研建设辅导老师工作台，而其产生收益是需要一个周期，而且周期越长，规模越大，产生的收益则会越大。反之，则可能辅导工作台就不值一文。

　　从因果链看，如果我方需求与中台需求匹配度越高，则需求被解决的概率越大，而动用的产研资源最少。所以我们双方就需要共同共建与维护一套统一的需求池；

　　从增强回路看，如果我方与中台方的研发资源，可以最大化共享，有效避免双方的推诿或掣肘，则可以有效构建一个从需求到落地的增强回路，有效解决全公司辅导老师的人效问题；

　　从调节回路看，辅导老师工作台的建设是一个节点，当产研投入小于收益时，则会减少对应投入，相关人员要么转到其他方向，要么进行人员裁撤；

　　从滞后效应看，辅导老师工作台的收益是有一个巨大周期性滞后，所以你是无法寻求到有效证据（或数据），可以证明你的需求优先级，一定高于其他业务线 从系统层面设计问题根本解

　　机制：双方（甚至多方）共建一套需求共识机制，每双周双方一起评估、沟通需求优先级与排期；

　　产品方案：双方一起确认需求解决方案，是属于多条业务线的共性需求，则统一至中台解决；否则业务线自行解决；

　　组织架构：不再保持两个产研团队的独立性，而是统一为同一个团队，只是内部分工有所侧重。

　　如果你每天都面临非常多的需求，甚至销售、客服等提需求无成本，导致需求“泛滥”，怎么办？

　　通过班车制或项目管理软件，细化和透明每个时间节点与排期，并进行自动化提醒，而不是期望他们的自觉性；

　　如果有，请设计为完全依赖系统或机制，而不是期望用户可以如你所预期那样去使用系统。

　　），以及对应面对问题的三种解决方案（症状解、原因解、根本解）；因式拆解：提出【

　　】公式和四种连接关系（因果链、增强回路、调节回路、滞后效应）；结论：建议