非技术背景的项目经理如何做好修炼

本文由项目管理系统整理：技术背景的项目经理做事风格偏硬，喜欢撸起袖子自己干，往往不注意软技能的修炼。而非技术背景的项目经理往往行业技术知识不足，容易被技术专家忽悠，因此需要多修炼一些技术硬功夫，以及提升自己的技术素养。

绝大多数非技术背景的项目经理不乏理科背景，但基本没有从事过具体的技术研发工作。因为缺乏技术一线的背景，往往天生硬不起来，只能靠软技能来管理项目。研究发现，非技术背景的项目经理的一个困境是，当遇到技术人员用所谓的技术权威来耍赖时，他们往往无计可施，只能是哑巴吃黄连。

原则上，要管好项目，项目经理应该两手抓，两手都要硬。技术背景的项目经理要补软技能的短板，非技术背景的项目经理要补技术的短板。虽然不需要项目经理成为技术专家，但项目管理者必须要加强技术逻辑能力，也就是能用技术术语和概念，根据技术原理进行逻辑思维和推理。

实际上，这既是一种能力也是一种学习方法。我虽然是技术背景，但是在项目管理实践中，我也不懂项目中所有的技术。工作中，我经常处理一些棘手的“专业”之外的技术问题，这其中很多问题还是拖了几个月解决不掉的。

有几位非技术背景的项目经理就特别佩服我，对我说：“懂技术就是好，一通百通，什么结构、电子的问题到你这儿都不是什么问题。”事后总结发现，其实我并没有解决任何具体的技术问题，这些问题都是工程师解决的，我所做的就是按照我的逻辑，让工程师完成工作，试验、反馈、修正，最终达成目标。

因为所解决的这些技术问题并非我专业特长，所以相对解决的问题而言，我就是非技术背景的项目经理。

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

不能以自己非技术出身，就否定自己

不懂技术的最大问题是，你无法和工程师交流和沟通。关于沟通我们都知道，你需要用对方能听得懂沟通的语言和对方沟通，才有可能达成有效的。

你不能苛求工程师能用你能听得懂的语言和你沟通，如果是这样的话，你除了获得工程师的不满，什么也得不到。每个工程师的内心，其实都是很傲娇的。

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

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

图1  知识体系的层次

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

第二层是由核心概念派生的原理逻辑层，由核心概念派生出一些术语，然后用逻辑把这些术语串联起来就变成了原理。掌握了这一层，你基本上可以把这门知识的方方面面都考虑到了，而且据此可以安排工作，工作之间的相互关系和影响了然于胸。在这个层次上，你可以通过画几个方框（模块）再加上几根连线（逻辑）把该知识体系讲清楚。

但你不一定会计算，不一定能把东西做出来。如果掌握了这一层，你可以进行逻辑推理和思考，而且还能够创新，很多创新是先要把原理逻辑想清楚，才能通过工程实践做出来。先有概念，通过思维派生逻辑，逻辑清楚了再动手，方向就对了，最后才能做出来，即工程应用。

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

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

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

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

形而上谓之道，形而下谓之器。道是无形的，器是有形的。上面讲的这3层，核心概念层是道、原理逻辑层是术、工程应用层是器。非技术出身的项目经理需要掌握的是道和术的层次。

这两个层次纯粹是逻辑思维，而且一旦把这两个层次掌握了，你就可以高屋建瓴地指导别人工作了，大部分工程师其实对原理层也不是很清楚，所以在进行逻辑对决的时候占不到你什么便宜。

注意学句听习方法，勤思考、多实践

很多人特别喜欢读书，读完之后除了记住几起来很时髦的词句，并没有掌握什么，还时常越读越困惑。

例如，同一种情况有36种应对方法，这该如何处理？你不可能把这36种方法都记得滚瓜烂熟，即使全部都记住了，在遇到事情时还是不知道该选择哪种方式应对，总不能把36种方法全都尝试一遍。这就是没有掌握学习方法的缘故。

我在读书学习的过程中根据前人的经验和自己的摸索，总结出了一个模型，发现很好用，在这里分享给大家。我称这个模型为WWH模型，即What-Why-How模型，如图2所示。

图2  WWH（What-Why-How）模型

是什么（What），这是读书的过程中要做的事情，就是搞清楚这本书在讲什么，这个“为什么”包括基本概念和基本逻辑。读书的时候先不要怀疑作者的言论，先假设对方说的是合理的，此时的状态是没有不接受，也就是既不相信，也没有不相信，且看作者在说什么，是如何论证的。

此时，要用作者的逻辑来验证作者的观点，如果作者的逻辑能够很好地证明其观点，那么这本书是值得读的。记住，任何科学体系都必须满足两个特征，即自洽性（自己能证明自己）和相容性（不能用自己的逻辑证明相互矛盾的结论）。

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

为什么（Why），这是在读过之后要做的事情。经过“是什么”的过程之后，就书中一些关键的概念和逻辑提出“为什么”的问题。通过问自己为什么，可以把新学到的知识和自己既有的知识融会贯通。这其实就是在做归一化的思想实验。因为“为什么”之后还有更多的“为什么”，凡事都架不住多问几个为什么。

科学类的知识（无论自然科学还是社会科学）都是一家之言，也就是有其适用的特定条件，所有这些一家之言都是在讨论某一种真理的某一个方面，通过问为什么，可以把这些知识背后的知识挖掘出来，到最后往往就是一个适用性更广泛的道理。那么，就实现了知识的归一化，同时你对世界的认识也更加透彻，也就不需要记住36种处理方法了。

怎么样（How），是知识如何应用的问题。以技术为职业的人而言，就是把知识进行工程应用。对于项目管理者，并不需要这么做，你要做的仍然是进行思想实验，也就是结合工作和实践来思考刚刚学到的知识应该如何应用。

记住，最关键的是要思考技术对于人的作用和影响，也就是该技术可以解决人的什么问题。知识是人创造和发现的，知识最终都是为人服务的。以人为中心来思考知识的应用，看问题的层次就提高了，在论证技术方案的合理性的时候也就不会手足无措了。

更重要的是，当工程师给出很多方案时，选择合理方案也就不会那么困难了，因为你已经懂得了技术的价值是什么。

不要展现专业，而应展现逻辑

笔者认识的很多资深的非技术背景的项目经理，自身的技术知识其实是很丰富的，逻辑思维能力也很强。但往往还是无法和工程师处理好关系，其中非常重要的原因是：他们喜欢用工程师的专业知识来挑战工程师的工作。并不是说发现工程师的问题不要指出，也不是说工程师耍技术权威的时候一味地放纵，而是要注意方式方法。

要尽可能地用引导方式和问问题的方法，让工程师自己的逻辑出现混乱，当他陷入困境的时候，你再出手，此时仍然以问问题的方式，可这样说：“你看往这个方向是不是可行的？”这个时候，工程师对你是感激，而非不快。如果你太直接地指出对方技术上的问题，工程师往往面子上挂不住（中国人是讲面子的），反而不利于工作的开展。

要知道，技术是工程师赖以获得成就感的源泉，被你那么轻易戳破了，瞬间尊严会受到严重的挑战。

另一个重要的作用是，当面临错综复杂的跨专业技术问题时，清晰的技术逻辑和项目逻辑结合，会让你更加淡定，能够起到稳定军心的作用。

这种表面是技术问题的项目问题，如果直接交给工程师来处理，往往处理不好，因为工程师只会看到他眼前的技术问题，跨专业的问题往往会被忽视，更不用提项目整体的问题了。这个时候，懂技术的项目经理，运筹帷幄的能力才能真正解除项目的危机。