1.1.2　项目是一个业务过程，而非技术过程

有意思的是，工程师普遍特别实诚，他们盯着细节不放，还会更进一步：原来的那匹马时速多少公里？50公里的话，我给你找个80公里的。原来的那匹马身高多高？1米的话，我给你找2米的。原来的那匹马体重多重？100公斤的话，我给你找个200公斤的……于是他们开始在技术指标上较劲！

如果不盯着技术指标，问题也许还能解决，但若只盯着技术指标，往往就容易沉浸在细节里面出不来了。这不仅使得问题得不到解决，还会把自己搞得狼狈不堪。

那正确的方法应该是什么呢？建议你要求客户说明他们为什么会提出这些要求。通过不断地提问，你最终会知道问题的根源。实际上，针对业务的解决方案才是客户的真实需求。具体而言，面对客户所说的“想要一匹跑得更快的马”这个问题，我们从开始就不要盯着马本身提问，而是应该去问客户业务问题。这些问题可以是：你要马干什么呀？想解决什么问题呀？你要的这匹马要在什么情况下使用呢？使用时会遇到什么困难呀？总之，围绕使用的背景、环境、目的等业务问题进行提问，而不是围绕“对马详细描述”的技术问题进行提问。在这里，我要提醒你，遇到问题以后不要试图仅仅解决问题本身，还要去解决问题所在环境的问题。

事实上，系统工程的一个基本原理就是超越系统本身解决问题，即N维系统产生的问题只有在N+1维系统中才能解决。用我们老祖宗的话来说，叫“不识庐山真面目，只缘身在此山中”。在替别人分析问题时，我们能抽丝剥茧，分析得头头是道。当自己遇到同样的问题时，却总是很困惑和痛苦。

关于本主题的更多探讨，请参考本书8.3.3节。

请务必记住：项目是一个业务过程，而不是技术过程。这是重要的项目思维！项目管理者也应该是一个业务层面的管理者。项目的业务思维方式，能帮助你快速理解客户的痛点，明白客户“真正的需求”，在此基础上你再给出专业的反馈，并提供解决方案。这时候，你还应该具备业务建模能力。

说到建模，房地产行业给我们提供了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到你敢买房子吗？答案一定是否定的。除非，你不是自己住！

可见，要能把需求确认落地，实施者必须有很好的业务建模能力，并以咨询方式展开，也就是要推出自己的方案，快速地给客户展示合理的样例。一方面，这样可以较好地引导客户提出合理的需求，把他们的思路控制在可执行的范围内。另一方面，通过逆向反馈，推动客户确认需求，可以较大程度地避免理解上的偏差。

多年的经验告诉我，对于项目，一定要给客户看到“样板房”，如样品、模型、照片、软件的基本界面等，否则很可能会出问题！

回到福特汽车这个例子。如果问清楚客户要这匹马的目的是更快的话，问题就简单了——在脚下装两个滑轮行不行？不行的话再装两个翅膀，还不行就装发动机……反正比找跑得更快的马强多了。