一、为什么需要思考的脚手架

做项目这些年，我发现自己最焦虑的时刻，往往不是事情太多，而是事情太乱。客户抛过来一句话："我们要做数字化转型"。这句话背后是什么？是换系统？是上小程序？是搭官网？还是老板想要一个能看数据的驾驶舱？

问题越模糊，人越容易在原地打转。后来我意识到：面对复杂问题，真正让人卡住的不是智商，而是缺少一套可以重复使用的思考结构。就像盖房子要先搭脚手架，思考也需要先把结构立起来，再往里面填内容。

二、我常用的三个框架

1. 问题定义框架（5W1H）

先别急着给方案，先把问题本身问清楚：谁（Who）在什么场景（When/Where）遇到了什么问题（What），为什么要解决（Why），怎么算解决（How）。很多需求聊到最后会发现，客户真正要的和最初说的根本不是一回事。

2. 拆解框架（MECE）

把一个总目标拆成互不重叠、合在一起又不遗漏的子项。比如做一个小程序商城，拆成：商品、订单、支付、会员、分销、售后。每个模块再往下拆。拆到每一块都能独立评估工作量，排期和报价自然就出来了。

3. 决策框架（优先级矩阵）

把所有想做的事放进"影响大不大 × 成本高不高"的矩阵里。影响大成本低的先做，影响小成本高的坚决砍掉。这一条在给客户做方案时尤其好用——既能让客户看到我们替他省了钱，又能保证核心价值先行落地。

三、一次真实项目的应用

去年我们给一家本地企业做数字化方案。第一次沟通，对方列了十几个想做的功能，从会员系统到智慧大屏，恨不得一步到位。

我们没有直接报价，而是先做了一轮问题定义：他们的核心痛点其实是"客户复购率低、促销靠人工"。顺着这个定义拆解，十几个功能里真正相关的只有三个：会员标签、精准推送、消费分析。再套优先级矩阵，先做会员标签和消费分析，两周上线，数据一出来，老板自己就把第二步的方案定了。

事后复盘，这次项目能快速推进，靠的不是比客户聪明，而是脚手架搭得稳——每一步都知道自己在解决哪个问题，就不会被牵着走。

四、写在最后

思考框架不是束缚，恰恰相反，它是给混乱留出秩序。有了脚手架，新问题进来时你不会慌，而是条件反射般地走一遍：定义、拆解、排序、验证。

这套方法我在《一个传统企业的数字化转型手记》里也用过，感兴趣可以对照着看。