技术背景的项目形式风格偏硬，喜欢撸起袖子自己干，往往不注意软技能的修炼。而非技术背景的项目经理往往行业技术知识不足，往往容易被技术专家忽悠，因此需要多修炼一些技术硬功夫。本文就谈谈非技术背景的项目经理该如何提升自己的技术素养。
可能是因为自己是技术出身的项目经理的原因，以往比较关注技术出身的项目经理需要注意的思想行为的转变。大概是因为技术背景的项目经理往往风格偏硬，也就是比较喜欢撸起袖子亲自干。其实，我身边也有不少非技术背景的项目经理，虽然不乏理科毕业的，但是毕业后基本没有从事过具体的技术研发工作。因为缺乏技术一线的背景，他们往往天生硬不起来，只能靠软技能来管理项目。我通过观察发现，非技术背景的项目经理在工作中存在偏软的问题，当遇到技术人员用所谓的技术权威来耍赖的时候，这一类项目经理往往无计可施，只能是哑巴吃黄连。
所以，要把项目管好，从项目经理的个人能力上来讲，软硬两手都要抓。技术背景的项目经理要补软的短板，非技术背景的项目经理要补技术的短板。今天我们讨论一下，非技术背景的项目经理如何补上技术的短板。
首先要说明一点，所谓补技术的短板并不是要求项目经理从事具体的技术研发工作，而是指项目经理需要加强技术逻辑能力，也就是能用技术术语和概念，根据技术原理进行逻辑思维和推理的能力。
实际上，今天我要谈的既是一种能力也是一种学习方法。我虽然是技术背景，但是在项目管理实践中，我也不可能懂得项目中所有的技术。如果说讨论软件相关的技术，海哲基本上没有怕过谁，但是机械结构、电子相关的工作的确没有从事过。但是我经常处理一些棘手的“专业”之外的技术问题，很多问题还是多了几个月解决不掉的。有几位非技术背景的项目经理就特别佩服我，对我说：“懂技术就是好，一通百通，什么结构、电子的问题到你这都不是什么问题。” 我事后总结发现，其实我并没有解决任何具体的技术问题，这些问题都是工程师解决的，我所做的就是，按照我的逻辑，让工程师完成工作，试验、反馈、修正，最终达成目标。
因为所解决的这些技术问题并非我专业特长，所以相对解决的问题而言，我就是非技术背景的项目经理。我的方法对我有用，那么对其他非技术背景的项目经理也一定有所帮助。那么该如何提升自己的技术素养，顺利与各专业的工程师沟通，并解决问题呢？
首先，不能以自己非技术出身，就否定自己。
不懂技术的最大问题是，你无法和工程师交流和沟通。关于沟通我们都知道，你需要用对方能听的懂的语言和对方沟通，才有可能达成有效的沟通。你不能苛求工程师能用你能听得懂的语言和你沟通，如果是那样的话，你除了赢得工程师的鄙视，什么也得不到。每个工程师的内心，其实都很傲娇的。
技术也好，管理也好，本质上都是知识，能够首尾相连，前后贯通的就是知识体系。知识体系都有一些共同的特点，掌握这些特点对于我们来讲还是非常重要的。因为只有如此，你才会了解该学习哪些知识才是有意义的。
任何知识体系都是有层次的，这种体系不是上下关系，而是内外关系，大致可以分为三层。
最里面的是核心概念，往往有一两个核心的定义来支撑整个体系。掌握了这一层，你基本上可以用一两句话把一种知识体系讲清楚，但是你不一定能做出什么东西出来，甚至连数学公式未必能看得懂，但是别人会觉得你很高深，那么复杂的体系，两句话搞定，不是一般人物。
第二层是由核心概念派生的逻辑原理层，有核心概念派生出一些术语，然后用逻辑把这些术语串联起来就变成了原理。掌握了这一层，你基本上可以把这门知识的方法面都考虑到了，而且据此可以安排工作了，工作之间的相互关系和影响基本上了然于胸。在这个层次上，你基本上可以通过画几个方框（模块）再加上几根连线（逻辑）把该知识体系讲清楚了。但是你不一定会计算，不一定能把东西做出来。但是掌握了这一层，你可以进行逻辑推理和思考，而且还能够创新，很多创新是先要把原理逻辑想清楚，才能工程实践做出来。先有概念，通过思维派生逻辑，逻辑清楚了再动手，方向就对了，最后才能做出来，即工程应用。
最外面一层是工程应用层，工程应用往往就会涉及到数学、工艺和流程步骤，也就是说你不一定懂原理，但是你照着做一定能做出来。现代社会知识爆炸，其实很多人只是掌握了工程应用的知识，对于原理未必清楚。
为了说明上述三层关系，我们举个例子，牛顿力学定理。
核心层：是什么推动世界运动，是力，因此力是核心概念；
原理层：力有什么特性，牛顿三大定律；
工程应用层：加速度公式、万有引力公式、冲量公式。
形而上谓之道，形而下谓之器。道是无形的，器是有形的。上面讲的这三层，核心层是道、原理层是术、工程应用层是器。作为非技术出身的项目经理，我们要掌握的是道和术的层次。这两层次纯粹是逻辑思维，而且一旦把这两个层次掌握了，你就可以高屋建瓴的指导别人工作了，大部分工程师其实对原理层也不是很清楚，所以在进行逻辑PK的时候是占不到你什么便宜的。
其次，要注意学习方法，勤思考，多做思想实验。
很多人特别喜欢读书，读完之后除了记住几句听起来很时髦、NB的话之外别的就没有什么了，有时候书读的越多越困惑。例如同样一种情况有三十六种应对方法你该如何处理？你不可能把这三十六种方法记得滚瓜烂熟，即使你记住了，真碰到事情你还是不知道该如何应对，总不能把三十六种方法都试一遍吧。这种情况就是没有掌握学习方法的缘故。我在读书学习的过程中根据前人的经验和自己的摸索，总结出了一个模型，发现很好用，在这里分享给大家。
我称这个模型为WWH模型，即What-Why-How模型。
第一先谈What，这是读书的过程种要做的事情，就是搞清楚这本书在讲什么，这个“What”包括基本概念和基本逻辑。读书的时候先不要怀疑作者的言论，先假设对方说的是合理的，此时的状态是没有不接受，也就是既不相信，也没有不相信，且看作者做说什么，如何论证的。这个时候我会用作者的逻辑来试图证明作者的观点，如果发现作者逻辑能够很好的证明其观点，那么这本书是值得读的。记住任何科学体系都必须满足两个特征，即自洽性（自己不能证明不了自己）和相容性（不能用自己的逻辑证明相互矛盾的结论）。
除了自洽性和相容性，好的知识体系应该一个核心的观点，所有的派生的概念和逻辑最终都是为了证明这个核心的观点。也就是我们以前上学的事后，老师让我们总结的中心思想。如果一本书竟是一些观点的罗列，作者自己没有中心思想，这种书往往属于毒鸡汤，还是趁早扔掉的为好。
第二谈Why，这是在读过之后要做的事情。经过What的过程之后，就书中一些关键的概念和逻辑提出“为什么”的问题。通过问自己为什么，可以把新学到的知识和自己既有的知识融会贯通。这其实就是在做归一化的思想实验。因为“为什么”之后还有更多的“为什么”，凡事都架不住多问几个问什么。科学类的知识（无论自然科学还是社会科学）都是一家之言，也就是有其适用的特定条件，所有这些一家之言都是在说明世界的某一种真理的某一个方面，通过问问什么，可以把这些知识背后的知识挖掘出来，到最后往往就是一个适用性更广泛的道理。那么也就实现了知识的归一化，同时你对世界的认识也更加透彻，也就不需要记住三十六种处理方法了。
第三谈一下How，所谓How，也就是知识如何应用的问题。作为以技术为职业的人来说就是把知识进行工程应用。而对于我们项目经理来说，是不需要这么做的。我们这个时候要做的仍然是进行思想实验，也就是结合工作和实践来思考刚刚学到的知识应该如何应用。
记住，最关键的是要思考技术对于人的作用和影响，也就是该技术可以解决人的什么问题。知识是人创造和发现的，知识最终都是为人服务的。以人为中心来思考知识的应用，那么你看问题的层次就提高了，那么在论证技术方案的合理性的时候你就不会慌了。最重要的是，当工程师给出很多方案的时候，选择合理方案就不会那么困难了。因为你已经懂得了技术的价值是什么。
最后，不要试图展现你比工程师更专业，而应展现你比他更有逻辑。
我认识的很多资深的非技术背景的项目经理，自身的技术知识其实是很丰富的，逻辑思维能力也很强。但是往往还是无法和工程师处理好关系，其中非常重要的原因是：他们往往喜欢用工程师的专业知识来挑战工程师的工作。并不是说发现工程师的问题不要指出，也不是说工程师耍技术权威的时候一味的放纵，而是要注意方式方法。要尽可能的用引导方式和问问题的方法，让工程师自己的逻辑出现混乱，当他陷入困境的时候，你再出手，此时仍然以问问题的方式说“你看往这个方向是不是可行的？”，这个时候工程师对你是感激，而非不快。如果你太直接的指出对方技术上的问题，工程师往往面子上挂不住，反而不利于工作的开展。要知道，技术是工程师赖以获得成就感的源泉，被你那么轻易戳破了，瞬间尊严会受到严重的挑战。作为可以拯救银河系的项目经理，就不要跟工程师争这个了。
还有当面临错综复杂的跨专业技术问题时，清晰的技术逻辑和项目逻辑结合，会让你更加淡定，能够起到稳定军心的作用。这种表面时技术问题的项目问题，如果直接交给工程师来处理，往往处理不好，因为工程师往往只会看到他眼前的技术问题，跨专业的问题往往会被忽视，更不用提项目整体的问题了。这个时候，懂技术的项目经理，运筹帷幄的能力才能真正解除项目的危机。
结束语
非技术背景的项目经理不应该放弃对技术的学习，某种程度上你尤其需要把自己行业的知识体系掌握下来，这样做的最大好处是让你容易和技术人员沟通，而且让你拥有了技术判断能力。你需要掌握的是核心概念和原理，而非技术细节。知识的学习需要总结自己的方法，掌握方法才能快速有效的学习所需要的专业知识，通过思维实验逐步实现知识体系的归一化。
(本文于2017-02-02首次发布)
