林秋的团队里有一个叫原野的人。原野是项目专员，入职两年半，做事很细，执行力很强。他擅长解决具体问题——物料卡住了，他去催；客户不满意了，他去安抚；进度落后了，他去补。他的“战斗力”很强，像一个专业的“救火队员”，哪里有火就去哪里扑。

但林秋发现了一个问题——原野只看到“点”，看不到“线”。

他解决了一个物料问题，但下次类似的问题还会出现，因为他不去追问“这个物料问题为什么会反复发生”。他安抚了一个客户，但下个客户还是会不满意，因为他不去思考“我们的服务流程在哪个环节容易出问题”。他补上了一个进度缺口，但下一个项目还是会有同样的缺口，因为他不去分析“我们的计划编制方式有什么缺陷”。

原野的思维是“点状”的——一个问题来了，解决它，然后下一个问题。他的效率很高，但效果不长。同样的坑，他会反复掉进去；同样的失误，他会反复犯。

有一次，他负责的一个项目又因为物料延期而延误了——这已经是他在这个项目上的第二次物料延误。林秋问他：“原野，上次物料延期的时候，你不是跟采购部协调过了吗？为什么这次又延了？”原野说：“上次是A物料延了，这次是B物料延了。不一样。”林秋说：“那它们有什么共同点？”原野说：“都是采购周期长、供应商不靠谱。”林秋说：“那你有没有想过，为什么你的项目总是遇到采购周期长、供应商不靠谱的问题？”原野说：“这个我控制不了啊，是采购部的问题。”

林秋说：“如果你只看到‘点’，你就会觉得‘每次都是采购部的问题’。如果你能看到‘线’，你就会发现——每次物料延期，都是因为你在项目启动时没有提前和采购部确认物料的采购周期。你没有把‘物料采购周期’作为你的计划前置条件。所以你每次都会踩到同一个坑。这不是采购部的问题，是你做计划的方式有问题。”

原野愣住了。他从来没有这样想过。他一直以为“物料延期”是一个个孤立的问题，从来没有把它们连成一条“线”。

林秋说：“我给你讲一个故事。你知道老周吗？他当年做项目的时候，发现项目总是延期。他不是去‘催’每一个延期的环节，而是画了一张‘项目流程图’。他把项目从头到尾的每一个环节都画了出来，然后在上面标注每一个环节的‘平均耗时’和‘常见问题’。他发现，有三个环节是延期的‘重灾区’。他没有一个一个去救火，而是优化了这三个环节的流程。他把‘点’的问题，变成了‘线’的优化。”

“你再想一想，如果你的思维再升一级——从‘线’到‘面’。你不仅是看到了物料延期这一条线，你还看到了物料延期和成本超支、客户不满、团队士气这几条线之间的关联。物料延期 → 项目延期 → 客户不满意 → 团队加班补救 → 士气低落 → 人员流失 → 新人上手慢 → 项目更慢。你看到了这个‘面’，你就知道了——物料延期不只是采购部的事，它会影响项目的方方面面。你会更重视它，你会在项目启动前就做更充分的预案。”

“再升一级——从‘面’到‘网’。你不仅看到了你自己的项目中物料延期的‘面’，你还看到了其他项目中类似的‘面’。你发现，物料延期是一个‘系统性’的问题，它不是某一个项目特有的，而是公司所有项目都在面对的。你把多个项目的‘面’连起来，就形成了一张‘网’。你看到了这张网，你就会知道——需要解决的不是某一个项目的物料问题，而是公司整体的采购计划流程。你推动了流程优化，所有项目都受益。这就是‘点-线-面-网’的思维方式。”

原野说：“那我怎么才能从‘点’升级到‘线’？我觉得我看不到那些‘线’。”

林秋说：“我给你一个方法，叫‘问三个为什么’。每次你遇到一个‘点’的问题，你问自己三个为什么。比如物料延期了。第一问：为什么延期？因为采购周期长。第二问：为什么采购周期长？因为我没有提前确认采购周期。第三问：为什么我没有提前确认采购周期？因为我在做计划的时候，没有把采购周期作为一个固定参数，而是临时才去问。你问完三个为什么，你就从‘点’看到了‘线’——你的计划编制方式有问题。”

“你再问三个‘然后呢’。物料延期，然后呢？项目延期。然后呢？客户不满意。然后呢？团队加班补救。然后呢？士气低落。然后呢？人员流失。你问完这些‘然后呢’，你就从‘线’看到了‘面’——物料延期不只是影响进度，还影响客户关系、团队士气、人员稳定。”

“你再问三个‘别人呢’。我的项目物料延期，别的项目呢？他们也一样。别的项目物料延期，原因和我一样吗？不一样，但都有共性。我把这些共性总结出来，能不能推动一个制度层面的改进？你问完这些‘别人呢’，你就从‘面’看到了‘网’——物料延期是一个系统性问题，需要系统性地解决。”

原野把这段话记在了心里。

他开始练习“问三个为什么”。在一个项目里，他发现客户反复提出修改意见，导致方案迟迟定不下来。他没有像以前那样去抱怨“客户太烦”，而是问自己：为什么客户反复提意见？因为需求没有在早期被充分确认。为什么需求没有被充分确认？因为我在项目启动的时候没有做需求确认会。为什么没有做需求确认会？因为我觉得“先做一个初稿，让客户看了再改”更快。他找到了“线”——他的需求确认流程有漏洞，必须前置到项目启动阶段。

他又问了“然后呢”。客户反复提意见，然后呢？方案反复修改。然后呢？项目周期延长。然后呢？团队反复做无用功。然后呢？团队士气下降。他看到了“面”——需求确认不足，影响的不只是方案本身，还有整个团队的效率和士气。

他又问了“别人呢”。我的项目需求确认不足，别的项目呢？他问了三个同事，发现大家都遇到过类似的问题。他把这个问题反馈给了林秋，推动了一次“项目需求确认流程优化”，把需求确认从一个“项目中期做的事”提前到了“项目启动必做的事”。这个优化被推广到了全部门，所有项目的需求变更率都下降了。

原野渐渐地不再是一个只会“救火”的点状思维者了。他学会了看线、看面、看网。他解决问题的方式，也从“扑灭眼前的火”变成了“找到火源，让火不再烧起来”。他的效率没有下降，但他的工作变得轻松了——因为同样的坑，他不会再掉进去第二次。

他来找林秋，说：“林姐，我现在能看到‘线’了。虽然还不一定能看到完整的‘网’，但至少我能看到问题之间的关联了。我不再觉得‘每次都是采购部的问题’，我会想‘我的计划里缺了什么前置条件’。我不再觉得‘客户太烦’，我会想‘我有没有在早期把需求搞清楚’。”

林秋说：“你能这样想，就对了。点状思维的人，永远在救火。线状思维的人，能找到火源。面状思维的人，能改变火源所在的系统。网状思维的人，能看到整个系统如何运转，然后从根本上改变系统的设计。 你现在已经进入了‘线’和‘面’的级别，你解决问题的方式已经比很多人高级了。”

她接着说：“你知道为什么很多管理者会陷入‘救火’模式吗？因为他们只会看‘点’。他们觉得每一个问题都是孤立的，所以每一个问题都需要一个单独的解决方案。他们忙得焦头烂额，但问题并没有减少。而那些能看到‘网’的管理者，他们花大量时间在‘前期设计’上——设计一个不易出错的系统。系统设计好了，问题就少了。”

原野后来在公司内部做了一次分享，题目叫《从点到网：别在点里忙，要在网里想》。他说：“我以前是一个‘点状思维者’。我特别会解决问题，但每次问题解决了，过一段时间它又回来了。我像一个消防员，不停地去扑火，火却永远扑不完。后来我才知道，我不是在灭火，我是在‘处理症状’。真正的火源，我从来没有找到过。”

“后来我学会了‘问三个为什么’、‘问三个然后呢’、‘问三个别人呢’。我从点看到了线，从线看到了面，从面看到了网。我的工作方式变了——我不再去扑每一个火，而是去找出火的源头，然后让源头不再起火。我花的‘前期时间’变多了，但我的‘救火时间’变少了。总时间反而减少了，效果反而更好了。”

他分享了自己的“点-线-面-网”升级法。

第一步，从点看到线。遇到问题，不要只解决它。问三个为什么——找到问题的根源。你找到了根源，你就找到了一条“线”——问题A → 原因B → 根源C。你下次遇到类似的问题，直接去解决根源C，而不是反复处理问题A。

第二步，从线看到面。找到根源之后，再问三个“然后呢”——这个问题会引发哪些连锁反应？你看到了这些连锁反应，你就看到了一个“面”——问题A会影响B、C、D。你解决了问题A，B、C、D也受益。你解决了一个问题，解决了一串问题。

第三步，从面看到网。看到了一个“面”之后，再问三个“别人呢”——其他项目、其他部门、其他团队，有没有类似的问题？你找到了共性，你就看到了一张“网”——这是一个系统性问题。你推动了系统性改进，所有人受益。

他的分享在公司内部引起了很大的反响。很多“救火队员”式的同事开始反思自己的思维方式。有人开始在工作日志里增加“问题分析”环节，有人开始做“问题关联图”，有人开始定期找跨部门的同事交流。

林秋后来在公司内部做了一次分享，题目叫《别在点上忙，要在网上想》。她在分享中讲了三个要点。

第一，点状思维让你忙，网状思维让你闲。你在“点”上解决问题，问题会反复出现，你永远在忙。你在“网”上解决问题，问题被根源性解决了，你反而变闲了。忙不是勤奋，是思维懒惰。你想得少，才会做得忙。你想得多，反而做得少。

第二，升级思维不等于否定细节。你看到了“网”，不代表你不用管“点”。你依然要解决具体问题，但你解决问题的方式会不同——你是在“系统设计”的框架下解决具体问题，而不是在“救火”的应激状态下解决具体问题。前者的解决方式是“修复”，后者的解决方式是“堵漏”。

第三，网状思维是一种“设计思维”。你不是在“处理问题”，你是在“设计系统”。你在设计的系统，能自动避免很多问题的发生。你的价值，不再是“解决了多少问题”，而是“创造了多少能自动运行的机制”。前者的价值是线性的，后者的价值是指数级的。

分享结束后，原野来找林秋，说：“林姐，我现在每天都会问自己——今天我看到的是‘点’还是‘网’？”

林秋说：“答案是什么？”

原野说：“今天我在做一个项目计划，我画了一条时间线，把可能的风险点都标了出来。我没有只盯着一个风险，我看到了它们之间的关系——如果物料延期，后面的测试和交付都会受影响。如果我提前两周确认物料，后面所有环节都会更顺。我看到了一条‘线’。”

林秋说：“很好。你看到的不是‘一个风险’，你看到了风险之间的‘关系’。关系，就是‘线’。你能看到关系，你就开始从‘点’走向‘线’了。继续练，你会看到更多‘面’和‘网’。”

原野把这句话记在了心里。

后来，原野被提拔为项目经理，开始独立负责项目。他的项目风格不再是“冲上去解决问题”，而是“提前设计好系统，让问题不发生”。他的项目延期的次数明显减少了，因为他会在项目启动时就画好“风险关系图”——把所有的风险点都标出来，并连接它们之间的影响关系。他会提前在关键节点上做预案，而不是等风险发生后再去扑救。

他的项目成功率，在同期项目经理中名列前茅。有一次，一个同事问他：“原野，你的项目怎么总是这么稳？”原野说：“因为我不急着去解决问题。我先画图。把所有的点标出来，把点之间的线连起来，把线之间的面画出来，把面之间的网看清楚。然后我再动手。动手的时候，我已经知道所有的坑在哪里了。”

同事说：“这不花时间吗？”

原野说：“花。但花在前面的时间，帮我省了后面的十次救火。你觉得哪个划算？”

同事想了想，没有回答。

原野知道，他需要时间才能想明白。他自己也是花了很久，才从“救火队员”变成了“系统设计者”。这个转变，让他不再焦虑，也不再疲惫。

他合上笔记本，在封面上写下：“点让你忙，网让你闲。你在网里看得越清，你在点上走得越稳。”

他笑了。

他知道，他的那张“网”，还会继续扩大，继续完善。而他的项目，也会因为这张网，越来越顺、越来越稳。