如何有效解决问题？（附方法论与案例）

产品经理的日常工作之一，就是解决问题，而输出解决方案就属于关键工作。

不知道你是否有这样的困惑？
‒ 每天面临的问题很多，感觉分身乏术；
‒ 或每天找你提需求的人很多，感觉无暇应对；
‒ 或你觉得足够了解用户需求，输出解决方案并上线后，发现无法解决用户的问题，只能二次返工；
‒ 等等。

一个小故事

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

第一个盲人摸到了大象的鼻子，他说：“大象就像一根大萝卜。”

第二个盲人摸到了大象的耳朵，他说：“大象就像一把大蒲扇。”

第三个盲人摸到了大象的腿，他说：“大象就像一根大柱子。”

第四个盲人摸到了大象的肚子，他说：“大象就像一个大鼓。”

第五个盲人摸到了大象的尾巴，他说：“大象就像一根绳子。”

第六个盲人摸到了大象的牙齿，他说：“大象就像一把长矛。”

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

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

案例：如何在资源受限的情况下，有效解决问题？

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

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

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

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

  
  【对外版】产品架构（教育-中台）-2024_11_08.png

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

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

所以摆在我这个新人的面前的是三个选择：

• 选择一：告辞，我不干了。此处不留爷，自有留爷处；
• 选择二：将此问题上升至领导，让其协助解决问题；
• 选择三：改变自己的需求方式，提前构建需求缓冲池，保证整体需求可提前规划与排期，与中台对齐节奏。

如果你是我，你会怎么选？

我哪个都没选，而是寻求第四个选择（即根本解）。

原因是：

• 选择一属于不解决，遇到问题就逃避。
• 选择二属于症状解。即从症状去解决问题，俗称治标不治本；
• 选择三属于原因解。即从原因去解决问题。我改变不了别人，但我可以改变自己的工作模式；

怎么理解？

举个例子。

如果你5岁的儿子的鞋带总是容易散，而他自己又不会系鞋带，你会怎么办？

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

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

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

方法论：从系统的根本解去解决问题，而不是依赖人

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

什么叫系统性解决方案？

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

以上述案例为例，我们一起来拆解一下。

首先是目标。

• 我方（即业务线）的目标：用最低成本、最高效率完成辅导工作台的构建，以此实现服务品质的规模化复制；
• 中台（即依赖方）的目标：尽可能通用化所有能力，用最小投入实现最大化赋能业务线。

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

所以，如果要解决问题，你就需要双方达成目标的一致。

第二是要素。

• 我方：即素养业务辅导老师、素养业务产研人员等都属于要素；
• 中台：即直播课业务辅导老师、中台产研人员、其他业务线辅导老师等，也属于要素。

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

第三是连接关系。一般连接关系有：因果链、增强回路、调节回路、滞后效应。

• 因果链：要素/变量之间的因果传递关系。比如你解决辅导老师的问题越多，他们越满意；反之，则不满意；
• 增强回路：又叫正反馈回路。比如你提升了辅导老师人效，用更少辅导老师服务更多学员，降低了企业的服务成本，增加了企业营收，而增加营收后，就可以投入更多产研资源，让你可以更快速解决辅导老师的人效问题；
• 调节回路：又称负向反馈回路。比如你可以提升辅导老师人效，但不是投入越多产研，就可以降低更多成本，而是会有一个瓶颈存在，最终导致你投入大，而收益变小。
• 滞后效应：所有事情都会有一个时间周期，就像种树一样，十年才能成材。比如你投入产研建设辅导老师工作台，而其产生收益是需要一个周期，而且周期越长，规模越大，产生的收益则会越大。反之，则可能辅导工作台就不值一文。

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

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

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

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

从系统层面设计问题根本解

最终，基于以上分析与梳理可知，解决方案不应该依赖产品经理的努力或付出，也不能依赖中台产研人员的善良，也不依赖素养方向辅导老师的诉求等，而是需要一个符合我发跟中台产研方，在目标、要素、连接关系上，保持一致性的系统性解决方案。

1、目标：以中台业务目标为核心，用最小化成本解决全业务线的所有需求；

2、需求池：双方不再单独维护各自需求池，而是共同维护一套全业务线需求池；

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

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

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

延伸：这个方法论，还能怎么用？

如果你每天都面临非常多的需求，甚至销售、客服等提需求无成本，导致需求“泛滥”，怎么办？通过机制跟需求池解决，而不是期望他们依靠他们可以理解你而少提需求；

如果你负责的项目，研发同学排期比较长，或习惯性延期，怎么办？通过班车制或项目管理软件，细化和透明每个时间节点与排期，并进行自动化提醒，而不是期望他们的自觉性；

如果你给用户设计解决方案，是否有依赖人的部分？如果有，请设计为完全依赖系统或机制，而不是期望用户可以如你所预期那样去使用系统。

总结一下

1、方法论：今天主要分享了一个方法论（即从系统的根本解去解决问题，而不依赖人），以及对应面对问题的三种解决方案（症状解、原因解、根本解）；

2、因式拆解：提出【系统 = 目标 x 要素 x 连接关系】公式和四种连接关系（因果链、增强回路、调节回路、滞后效应）；

3、结论：建议从目标、连接关系入手去寻求根本解解决问题，而不是依赖人或症状。