一个人思维的广度、宽度、深度、高度，决定了他/她对事物把握的合理程度。
这要说起我最近看的一些思维小书，<<拆掉思维里的墙>>、<<思考力>>，其中思维和思维体系的认知让我大受启发。也正赶上最近接二连三和客户谈了三个小项目，在搞定客户的同时也将自己逼上了“绝地”。
坦白说，我不是Geek，但我是技术Focus的，我以玩转技术为乐趣（尽管大多还只能想想 :-P），也以用技术解决问题，做出高质量的项目为追求，从兜里拿出锤子将钉子砸下去的感觉很爽。然而当我，一名技术Focus的开发人员站在客户面前Faciliate项目的时候，发现我的语言和客户的语言是打架的，我说的是前台后台页面调用，他说的登陆任务报表KPI。搞定客户，这么难？我的工具箱提示，换位思考，你应该带上客户的帽子，说客户的话。难道就是这么简单么？这是我真的问题么？
我回头反思了一个这个问题，如果客户是我朋友，如果客户是我们的HR，是否还有同样的痛？恩，似乎会容易点。那么当我们做事情的时候，如何能去掉迷茫，尽快融入到当下呢？
这里面有两个方法：第一，常说的找套路；第二，我认为需要完善当下对于问题域的思维体系，从而能够系统思考；
先说第二点。
这其实无关我们的Focus。
我在与客户讨论时发现纠结的地方似乎在于着眼点不一样，我的思考习惯会倾向于What/How。当一个问题来临的时候，我会考虑问题本身，然后就是如何解决，技术blala，甚至一些实现细节，对现有系统的影响。也就是我的思维体系其实是着眼于问题的，客户呢？在墙外面，这个墙是我预设的，是我在了解上下文，考虑问题之前构建的。
然而现实情况呢？在做项目这个上下文里，如果说我们做项目用技术解决问题是一场戏，那么客户就是这场戏的主角，“谁的问题、为什么” 是思考的第一顺序。即使是技术Focus的，那么当下所应用的一定是面向客户问题的技术方案，面向业务的技术架构，是要给客户带来价值的。这场戏如果连主角都没有了，试问还如何能唱下去？ 再比如，经常在写代码的时候发现如此tricky的实现，如此tricky的需求，那么这是不是背后隐藏着对于业务理解的缺失？为什么会如此tricky，客户想解决的问题到底是什么？ 在这个上下文里，这道墙显得那么的脆弱。
当墙到了，客户进来了，很多事情就自然而然的发生了：
1）带上客户的帽子，将客户的问题变成自己的问题，站在客户的立场思考问题。比如如果我是客户老板，我想做什么达到什么目标；如果我是客户技术主管，我是技术粉，我要上位，我想知道什么。
2）和客户建立关系，了解更多业务的上下文，帮助客户，甚至更多，想客户没有想到的。
这样，我们的影响力也建立起来，就有可能改变我们与客户合作的模式，真正做到为客户解决问题，否则我们会只是vendor。当然我们的能力技术还是必须的，但是心有多大，你的舞台就有多大，这句广告词显得依然那么有冲击力。
所以，在项目交付的上下文下，无论那个角色，无论那个问题，面向客户是必须的，而且越早越好，偷着乐不如众乐乐。第二，打破与客户的界限，不管是实际上的还是思维力的那座墙。他也是人，客户来了多聊聊，换位思考也容易些。
说白了，吃饭喝酒聊天睡觉冥想写代码，其实没多大改变，只是自此以后我的开发世界里多了个“你”。:-)
所以，我，想要拆掉我思维里的那座墙。