前言
上天关上了一扇窗户，同时也会给你开个门缝，这不叫眷顾，这叫空气流通哈哈，不然室内太闷了
开玩笑的，当你拥有某种特别的技能的时候，同时也会附带一些负面的效果。谈起谋士，我们可能会想起三国里面的周瑜，他足智多谋，立下很多战功，但是心胸比较小，最后事业搞不起来郁郁而终。
我们可以发现谋者一般会想得很多，很多场景都会考虑到，对方的招数、团队情况等等，十分耗脑力的活。
没错了，最近王宝强出演的《棋士》，就是这么一个类型，你在下棋的时候，除了常规的下棋招式，你还得懂对方的性格，下棋的风格，你才能对棋局有整体大局观。因为毕竟人不是ai，阅历是有限的，无法cpu里面全装棋谱，各种应对的方案对吧。
自然在做事上也会比较严谨，另一个词叫靠谱。
但是同时这种思虑过度，也会导致心比较弱，就像一个人坐在会议中间，周围好几个人在跟你说我有这个意见我有那个意见，当你情绪稳定的时候都好说，当不稳定的时候，它就像个漩涡将你卷了进去。
谋者强于谋，弱于心
纵观世界能人处理方式
- 金刚经
首先在几年前，看过一会《金刚经》，里面就有这么一段话，因无所住而生其心。
就是人是因为心被困在各种各样的东西里面，出不来感到困惑。比如说情，心里一直想着想着，很是苦恼，那么就叫心住在情关里面，这是你的心是没有自由的。
理论很好，但是真实实践起来发现，我去这很难不去计较啊，所以王德峰老师讲，他读过这段话，但是真正让他领悟的时候是人生经历一些变故。
- 马斯克
专注你要得到什么，用什么交换
他也教授了一些对抗内耗的方式，我相信他本身也遇到类似的麻烦，所以他学习借鉴了其他人的处理方法。他的处理方式，专注你要获得什么，用什么去交换，而不是对方在想什么。
有点交易的模式，我要什么东西，通过什么跟你交换，其中情绪也就是一种筹码也好，另类信息传递也好，最终目的是为了交易我想要的东西。
这种很大程度上，确实可以减少我们思绪的扩散，专注取得成果。但是毕竟人不是二极管，输入一个公式去执行就可以了这么简单。
人是复杂的，可能有些台面上的利益，背后还有面子，还有背后各种利益交织对吧，所以在实践中是将所有的台前台后的东西哐放筹码去交易，你最想要得到什么，你应该舍弃什么，舍弃的有可能恰恰是跟对方交易的东西。
如果你专注对方的情绪，或者怎么想的点上，那么你的思绪会被卷入无限的想象里面，而无法自拔。
就像最近巴菲特投资大会讲的案例，人总会遇到苦难，怎么让自己生活得更好呢？
专注于美好事物。因为苦难无法避免，每个人或多或少都会遇到麻烦，在这个过程中专注于那些美好的事物，会让你更加幸福。
- 曾国藩
我们看到很多《曾国藩家书》，等等网上的事迹，其实他的早年比较残酷的，因为要做成事情，没有雷霆手段怎么做好呢，自然脾气也不太好，对于这类的问题他又是怎么处理的呢？写日记。
这个有点像佛家的法门，观照，也不一定是佛家的，心理学上技巧。就像你把自己抽离出来，去观察你在做什么，这个人有什么情绪，中间究竟发生什么冬瓜豆腐，每个人的角色不同利益不同，站的角度不同产生的想法不一样，所以有了矛盾有了对抗。
那么我们在对抗里面获得了什么，学习了什么，如果仅仅只是情绪，其实对我们成长无所帮助的。
我认为正是个人能力问题，无法自我释怀，沉浸在情绪毒汤里面，越陷越深，所以我们需要借助日记来载体，写下我们自己的想法、感觉，为什么会有这样的反应，那么我们才能从情绪里面剥离开来。
曾经我刚刚毕业的时候在一家电商公司做程序员，期间跟一个同学有矛盾，他是前端出身转行当产品，然后他觉得我写的应用bug很多，这时我就不爽了，因为测试同学上班在那玩手机，快上线的时候点一下功能能跑通就行，那项目质量还要测试做什么，我那会也有情绪。
我们掐得不可开交，然后我就找了cto，还是跟他比较熟，然后团队内部的问题他帮忙解决也合理。
他是这样做的，让我们将事情的起因，想法、情绪写出来，情绪单独放一列，当我们两个人写之后，我们就可以理解为什么对方会这么想，为什么会有情绪，是不是有不合理的地方，在这个过程中将事实和情绪剥离开来，更好的理性处理问题。
| 人物 | 事情 | 情绪 |
|---|---|---|
| 大鸡腿同学 | 我觉得bug多，测试同学也有份，因为这个角色是系统里面的一部分，也是质量保证的一环；另外干活累死累活，时间又赶，结果测试不好好的测，出问题算我的，肯定不服 | 累活我干了，至少测试也得认真搞，你觉得bug都是研发的问题我肯定不爽 |
| 产品同学 | 代码是研发写出来的，代码质量需要有所保证；只要源头控制得好，项目质量问题也会比较少 |
经过这样一番书写之后，我们会发现各方站的角度不同，想的不同，自然一碰撞也会有火花，然后产生了情绪。如果没有将情绪剥离开，就会变成一下需要先照顾一下对方的情绪，一下又得解决真正的问题，导致最终陷入情绪的漩涡里面无法自拔。
其实这件事并没有很好的解答项目质量的问题，但是在我心里埋下一颗对质量的思考，怎么做才能将项目质量提升上去，以至于我在当前的公司出现项目质量问题的时候有了出手的机会，我推出了checklist机制。
题外话：checklist机制
飞行员起飞的时候，怎么确保没有问题呢，就是有个checklist，确认清单，指示灯亮没亮，油箱怎样，操作杠ok吗，全部确认完才能进行起飞。
对于一个项目来讲，从需求的阶段，产品同学对于需求的理解，还有对于我们系统的规划，还有交互细节的思考，决定了项目的走向，你说需求阶段没有质量问题吗？在研发阶段，设计不够严谨，对系统调整的影响点梳理不够，对代码判断不够严谨，这里面也有质量问题。对于测试阶段，你根本不知道开发改了啥，你怎么测全呢，或者对于系统功能相关依赖影响不清晰，那也无法测好对吧，或者没有一些边界值测试，对于线上极端情况出现也有bug。最后产品验收环节，你是否认真的验收过，是不是你当初想要的效果，符不符合业务的需求，还是说草草了事，上线之后再掰扯我不是这么说的。
从这个点来看，当时这位产品同学的眼界比较的狭窄，解决问题的角度停留到了研发角色。一个好的项目，其实都是各方的努力，而不是研发噼里啪啦敲得好就行，比如说产品的路给你指错了，研发写得越多越杂，以后更长的路需要去填补这段错路。
人生就是自我迭代的过程
