【引子】

项目经理需要懂得专业技术，否则将无法与相关方（例如工程师、客户）交流和沟通。关于沟通需要用对方能听的懂的语言和对方沟通，才有可能达成有效的沟通。项目经理不能苛求相关方都能用项目经理能听得懂的语言进行沟通。虽然很多项目经常是技术出身，但是不可能什么都懂，项目经理能不能做到“看起来”样样精通，答案是肯定的，但是必须掌握正确的学习方法。

【正文】

可能是因为自己是技术出身的项目经理的原因，以往比较关注技术出身的项目经理需要注意的思想行为的转变。大概是因为技术背景的项目经理往往风格偏硬，也就是比较喜欢撸起袖子亲自干。其实，我身边也有不少非技术背景的项目经理，虽然不乏理科毕业的，但是毕业后基本没有从事过具体的技术研发工作。因为缺乏技术一线的背景，他们往往天生硬不起来，只能靠软技能来管理项目。我通过观察发现，无论哪种背景的项目经理在工作中都会遇到相同的问题：当遇到技术人员用所谓的技术权威来耍赖的时候，项目经理往往无计可施，只能是哑巴吃黄连。

首先声明一点，本文并不是要求项目经理从事具体的技术研发工作或者成为什么大家，而是指项目经理需要通过学习增强逻辑分析能力，也就是能用相关零售的术语和概念，根据原理进行逻辑思维和推理的能力。

       实际上，今天我要谈的既是一种能力也是一种学习方法。我虽然是技术背景，但是在项目管理实践中，我也不可能懂得项目中所有的技术。如果说讨论软件相关的技术，作者基本上没有怕过谁，但是机械结构、电子相关的工作的确没有从事过。但是我经常处理一些棘手的“专业”之外的技术问题，很多问题还是多了几个月解决不掉的。有几位非技术背景的项目经理就特别佩服我，对我说：“懂技术就是好，一通百通，什么结构、电子的问题到你这都不是什么问题。” 我事后总结发现，其实我并没有解决任何具体的技术问题，这些问题都是工程师解决的，我所做的就是，按照我的逻辑，让工程师完成工作，试验、反馈、修正，最终达成目标。

因为所解决的这些技术问题并非我专业特长，所以相对解决的问题而言，我就是非技术背景的项目经理。我的方法对我有用，那么对其他项目经理也一定有所帮助。那么该如何提升自己的技术素养，顺利与各专业的工程师沟通，并解决问题呢？

首先，不能以不是自己的专业，就否定自己。

不懂技术的最大问题是，你无法和工程师交流和沟通。关于沟通我们都知道，你需要用对方能听的懂的语言和对方沟通，才有可能达成有效的沟通。你不能苛求工程师能用你能听得懂的语言和你沟通，如果是那样的话，你除了赢得工程师的鄙视，什么也得不到。每个工程师的内心，其实都很傲娇的。

技术也好，管理也好，本质上都是知识，能够首尾相连，前后贯通的就是知识体系。知识体系都有一些共同的特点，掌握这些特点对于我们来讲还是非常重要的。因为只有如此，你才会了解该学习哪些知识才是有意义的。

任何知识体系都是有层次的，这种体系不是上下关系，而是内外关系，大致可以分为三层。

最里面的是核心概念，往往有一两个核心的定义来支撑整个体系。掌握了这一层，你基本上可以用一两句话把一种知识体系讲清楚，但是你不一定能做出什么东西出来，甚至连数学公式未必能看得懂，但是别人会觉得你很高深，那么复杂的体系，两句话搞定，不是一般人物。

第二层是由核心概念派生的逻辑原理层，有核心概念派生出一些术语，然后用逻辑把这些术语串联起来就变成了原理。掌握了这一层，你基本上可以把这门知识的方法面都考虑到了，而且据此可以安排工作了，工作之间的相互关系和影响基本上了然于胸。在这个层次上，你基本上可以通过画几个方框（模块）再加上几根连线（逻辑）把该知识体系讲清楚了。但是你不一定会计算，不一定能把东西做出来。但是掌握了这一层，你可以进行逻辑推理和思考，而且还能够创新，很多创新是先要把原理逻辑想清楚，才能工程实践做出来。先有概念，通过思维派生逻辑，逻辑清楚了再动手，方向就对了，最后才能做出来，即工程应用。

最外面一层是工程应用层，工程应用往往就会涉及到数学、工艺和流程步骤，也就是说你不一定懂原理，但是你照着做一定能做出来。现代社会知识爆炸，其实很多人只是掌握了工程应用的知识，对于原理未必清楚。

为了说明上述三层关系，我们举个例子，牛顿力学定理。

核心层：是什么推动世界运动，是力，因此力是核心概念；

原理层：力有什么特性，牛顿三大定律；

工程应用层：加速度公式、万有引力公式、冲量公式。

形而上谓之道，形而下谓之器。道是无形的，器是有形的。上面讲的这三层，核心层是道、原理层是术、工程应用层是器。作为项目经理，我们要掌握的是道和术的层次。这两层次纯粹是逻辑思维，而且一旦把这两个层次掌握了，你就可以高屋建瓴的指导别人工作了，大部分工程师其实对原理层也不是很清楚，所以在进行逻辑PK的时候是占不到你什么便宜的。

其次，要注意学习方法，勤思考，多做思想实验。

很多人特别喜欢读书，读完之后除了记住几句听起来很时髦、NB的话之外别的就没有什么了，有时候书读的越多越困惑。例如同样一种情况有三十六种应对方法你该如何处理？你不可能把这三十六种方法记得滚瓜烂熟，即使你记住了，真碰到事情你还是不知道该如何应对，总不能把三十六种方法都试一遍吧。这种情况就是没有掌握学习方法的缘故。我在读书学习的过程中根据前人的经验和自己的摸索，总结出了一个模型，发现很好用，在这里分享给大家。

 我称这个模型为WWH模型，即What-Why-How模型。

第一先谈What，这是读书的过程种要做的事情，就是搞清楚这本书在讲什么，这个“What”包括基本概念和基本逻辑。读书的时候先不要怀疑作者的言论，先假设对方说的是合理的，此时的状态是没有不接受，也就是既不相信，也没有不相信，且看作者做说什么，如何论证的。这个时候我会用作者的逻辑来试图证明作者的观点，如果发现作者逻辑能够很好的证明其观点，那么这本书是值得读的。记住任何科学体系都必须满足两个特征，即自洽性（自己不能证明不了自己）和相容性（不能用自己的逻辑证明相互矛盾的结论）。

除了自洽性和相容性，好的知识体系应该一个核心的观点，所有的派生的概念和逻辑最终都是为了证明这个核心的观点。也就是我们以前上学的时候，老师让我们总结的中心思想。如果一本书尽是一些观点的罗列，作者自己没有中心思想，这种书往往属于毒鸡汤，还是趁早扔掉的为好。

第二谈Why，这是在读过之后要做的事情。经过What的过程之后，就书中一些关键的概念和逻辑提出“为什么”的问题。通过问自己为什么，可以把新学到的知识和自己既有的知识融会贯通。这其实就是在做归一化的思想实验。因为“为什么”之后还有更多的“为什么”，凡事都架不住多问几个问什么。科学类的知识（无论自然科学还是社会科学）都是一家之言，也就是有其适用的特定条件，所有这些一家之言都是在说明世界的某一种真理的某一个方面，通过问问什么，可以把这些知识背后的知识挖掘出来，到最后往往就是一个适用性更广泛的道理。那么也就实现了知识的归一化，同时你对世界的认识也更加透彻，也就不需要记住三十六种处理方法了。

第三谈How，所谓How，也就是知识如何应用的问题。作为以技术为职业的人来说就是把知识进行工程应用。而对于我们项目经理来说，是不需要这么做的。我们这个时候要做的仍然是进行思想实验，也就是结合工作和实践来思考刚刚学到的知识应该如何应用。

记住，最关键的是要思考技术对于人的作用和影响，也就是该技术可以解决人的什么问题。知识是人创造和发现的，知识最终都是为人服务的。以人为中心来思考知识的应用，那么你看问题的层次就提高了，那么在论证技术方案的合理性的时候你就不会慌了。最重要的是，当工程师给出很多方案的时候，选择合理方案就不会那么困难了。因为你已经懂得了技术的价值是什么。

最后，不要试图展现你比工程师更专业，而应展现你比他更有逻辑。

我认识的很多资深的项目经理，自身的技术知识其实是很丰富的，逻辑思维能力也很强。但是往往还是无法和工程师处理好关系，其中非常重要的原因是：他们往往喜欢用工程师的专业知识来挑战工程师的工作。并不是说发现工程师的问题不要指出，也不是说工程师耍技术权威的时候一味的放纵，而是要注意方式方法。要尽可能的用引导方式和问问题的方法，让工程师自己的逻辑出现混乱，当他陷入困境的时候，你再出手，此时仍然以问问题的方式说“你看往这个方向是不是可行的？”，这个时候工程师对你是感激，而非怨恨。如果太直接的指出对方技术上的问题，工程师往往面子上挂不住，反而不利于工作的开展。要知道，技术是工程师赖以获得成就感的源泉，被你那么轻易戳破了，瞬间尊严会受到严重的挑战。作为可以拯救银河系的项目经理，就不要跟工程师争这个了。

还有当面临错综复杂的跨专业技术问题时，清晰的技术逻辑和项目逻辑结合，会让你更加淡定，能够起到稳定军心的作用。这种表面时技术问题的项目问题，如果直接交给工程师来处理，往往处理不好，因为工程师往往只会看到他眼前的技术问题，跨专业的问题往往会被忽视，更不用提项目整体的问题了。这个时候，“懂技术“的项目经理，运筹帷幄的能力才能真正解除项目的危机。

结束语

项目经理不应该放弃对技术的学习，某种程度上你尤其需要把自己行业的知识体系掌握下来，这样做的最大好处是让你容易和技术人员沟通，而且让你拥有了技术判断能力。你需要掌握的是核心概念和原理，而非技术细节。知识的学习需要总结自己的方法，掌握方法才能快速有效的学习所需要的专业知识，通过思维实验逐步实现知识体系的归一化。