写给汽车行业软件项目经理的纸上谈兵之法

当年一位老领导曾谆谆教诲我，大概是说一定要学会汇报，特别是要抓住在领导面前露脸汇报的为数不多的机会，升职加薪主要靠它……嗯，这也算是掏心掏肺了，话糙，理至少不完全糙。

面对开会、写PPT、汇报这类工作，我们总是习惯于贬低它的价值，尤其是处于执行层的年轻人。但是，就形式而言，“纸上谈兵”是各级管理层的日常，倒从来不见领导们上车上做测试，天天都在开会、汇报、写邮件。乃至我们今天所有的重要决定都是“纸上谈兵”的形式下制定的（当然，我们只是借用纸上谈兵这个词，大家不必过于纠结它的准确含义）。

所以，“纸上谈兵”极其重要。那么，比实际做事更重要吗？

可能没有，但有时候缺少纸上谈兵的能力会让你做的实际的事情被别人摘了果子。

我们都知道，汽车行业里的一般项目经理是个有名无实的岗位，会被叫什么什么经理，实际上是背锅侠，项目以及分解后的任何事务的推进需要挂在具体一个人头上才有效果，这算是项目经理的核心需求之一吧。

对于Value Adding本身，PM确实并不贡献什么，还记得当年的一个年轻客户面对报价单上有项目经理的费用时，十分讶异地说你怎么还要钱……嗯，我也是个人……当然，这是没经验的人的主观误解，但倒是反映了 PM价值的某种“虚无”。

只有通过“说”出来和“写”出来，才能证明你的价值。实际上，PM于组织和自身的价值很大部分本就在于这两点。

但是纸上谈兵有1.0和2.0，1.0是只能基于历史数据和理论数据完成谈兵，而2.0是可以基于当下数据和实践数据完成谈兵及用兵的，前者可以举一，后者可以反三。

我比较喜欢看《三国演义》，在马谡失街亭那集里，诸葛亮说马谡“屡献战策，累有功劳”，而刘备先前则认为其“言过其实，不可大用”。对应一下，马谡算是纸上谈兵1.0，饱读兵书，有理论水平，也有些才气，但终无随机应变之能，难堪战场用兵之职。那么，诸葛亮就是纸上谈兵2.0了，不但能谈，还能用。

扯远了，项目经理就是不但要“说得漂亮”、“写得精彩”，还要“说得有效”、“写得有力”。

2

纸上谈兵1.0：能上能下

我们再扩展一点1.0，怎么算漂亮和精彩呢？

能上能下，就是指上要贴合业务、融通管理，下要走入代码、关注技术。

打比方说，你要讲得明白你负责这个项目隶属于什么车型，这车型的立项背景、市场定位是怎么样的，预计有多少销量，在公司或客户端处属于什么营销思路，技术亮点在哪里，与竞争对手的差异在哪里，供应链如何铺开，采购策略什么样子·····这个叫“上”，所谓高屋建瓴。但是，如果只是说完这个就没了，那你会显得大而无当。

然后，你得说得清楚产品的Roadmap是怎么规划的，准确的项目计划是什么，软件如何分支，团队怎么搭建，需求用什么渠道传递，验证的进展到哪一步了，Defect的解决计划是否清晰·····这个叫“下”，所谓脚踏实地。

至于“说”和“写”的术与器，这就见仁见智了，有需要文字描述的，有需要表格汇总的，也有需要图片示例的，因时因地而用，暂不多言。

做到能上能下后，这个项目经理看起来是还不错的，思路挺清晰，信息传达得也挺到位，但如在此停步的话，还是难以持久，小打小闹可以，真要上台面处理些事情来，还是不行。

3

纸上谈兵2.0：细节

2.0要多哪些东西呢？我们没有多智近妖的诸葛亮的大才，但也是可以做些事情的。

抛开背后什么实践了、经验了、技术了等等，与1.0纸面上的差异就在于细节。

靠看书、查资料、读报告、背数据，我们基本能够达到纸上谈兵1.0的水平。当纸面信息足够全面、理论框架足够完整、PPT设计足够精美、逻辑脉络足够严谨时，你在还没到解决问题时或给不太懂的人讲时，会让人竖起大拇指。

但是，细节都是一层一层卷出来的，细节都是一坑一坑填出来的，细节都是在现场一丝一毫做出来的。

优秀和普通的差距可能在框架和逻辑，而优秀和卓越的差距更在于那一点一滴积累起来的边边角角的细节。

一个毕业3年的项目经理基本可以带完一个不大不小的项目，这和一个15年的资深老炮相比，看不出明显差异，甚至3年小伙子做出来的东西更漂亮。

然而，追溯到5年前某个已经 EOP的项目上的代码Bug的来龙去脉时，或许只有这位磨练得脑门锃光瓦亮的项目管理专家才说得清楚。

当然，也有可能这个15年的老油条在某个变更的细节上并不如3年小伙子清楚。

其实，可以看得出来，纸上谈兵谈得好并非易事，既要有高屋建瓴的视角，又要有全面系统的框架，还要有有血有肉的细节。

4

一个实用的升级框架

纸上谈兵之后，再分享一个实用的升级汇报框架。

项目经理最大的权力就是有举手汇报权。

一般有三种情况需要举手，一是你遇到问题需要支持了，如果自己硬啃会崩了牙，就可以适时向领导举手；二是你有个两难或多难的选择，需要领导决策了；三是你有一些经验或教训想去信息分享下，露露脸，也是可以举手的。

当然，一次举手也可能三者皆有。具体如何操作呢？

首先，快速给领导一个背景。万事万物都背景，领导们基本不会对你的项目有多了解，上来就具体细节，难免让人不知所云。开头要有一个整体的汇总，比如，要包括项目名、汇报人、红黄绿的项目状态、带有关键里程碑的时间线（比如，大领导对软件集成的里程碑根本没啥概念，就不要往上写了）、Top 3/5的信息……这个是大的背景，要让领导快速地对项目的整体状态有个感觉。

其次，描述清楚你要说的问题或信息。这个要因事而论了，但原则是精炼、直奔主题、领导敏感，比如，马上到了交样或造车的节点了，有一个很大软件功能缺陷无法修复，会造成产线停线，领导就会很敏感地知道发生事儿了。

然后，给出团队的多个方案。包括很多职场鸡汤都讲过，你不能把问题抛给领导，让领导想方案，领导不是神，最多只是能替你兜底，而且这底可不随便兜，至少要让领导相信你们尽力了，多个方案就是让领导详细的有力证据。

同时，还要给各个方案明确出优劣势，比如，时间是不是延期、成本是不是超标、质量是不是有风险、客户是不是满意……

最后，给出团队的结论。领导真不是神，即使给出了有优劣势对比的多个方案，领导仍然未必能够平衡得很好，可能是专业跨度太大，可能信息不足。

汇报时要给出团队自己的判断，然后解释为什么，如无大的问题，领导也会支持团队的努力，你也是成功借用领导的支持将项目按照想要的方向推行下去了。

值得说一句的是，给领导汇报是个锻炼纸上谈兵能力的极为高效的手段。年轻的朋友们，有机会一定要抓住，向上管理虽多令人不齿，但却是职场发展必不可少的部分。这时，我的耳边又悠悠地飘来那位老领导的谆谆教导……

5

写在最后

“纸上得来终觉浅，绝知此事要躬行”。但是，躬行之后还是要写到纸上的。

写给项目经理，也写给其他人。