.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
怎么做项目管理2
本文是这个文档的姊妹篇：
:doc:`怎样做项目管理`
上面这个文档讨论了风险管理在项目管理所有工作中贯彻始终的作用。本文讨论另一个主 题：项目经理的自我修养问题。
项目经理干得不好很容易变成“当官”（这里只是比喻一般世俗意义的作威作福的官，其实 官也不是这样当的），而不是对项目的贡献者。我们用一个常见的例子来说明：
很多新手项目经理是这样工作的：先把领导的要求和时间点倒排，分成几个阶段，然后回 去找技术人员“讨价还价”，最后得到一个计划，然后在每个阶段点上强烈要求必须达成， 如果达不成就要求加班，然后……如果还不行……那也没有办法——我们已经尽力了，不是我们 的错（其实不完全是这样，我们后面会补充）……
这其实是项目经理视角，时间点是领导和实施的工程师的，和你鸟关系没有，你除了拿着 这张单当“领导”的工头或者“拿鞭子的人”，你对这个项目根本没有贡献。
如果我们开上帝视角，或者我们这群人就是要一起做出一个产品来，没有领导要求，或者 想象我们就是自己一群人要一起穿过一片沙漠，项目目标就是这群人的共同意志。这些情 况下，项目经理的价值是什么？
你的伎俩除了到时间点的时候让大家加班，也没有别的什么了，更重要的是，你连一个最 基本的问题都没有搞明白：加班不是你带来的贡献。当项目无法达到那个时间点的时候， 无论是修改项目方向，方法，目标，技术方案，还是加班——这和你项目经理有关系吗？你 只不过个把结果收集起来，去给领导汇报的“小黄门”的角色而已，“皇上”和“大臣”们在乎 一个“小黄门”吗？
更不要说，项目经理要求的加班常常起反作用——它是被动的，不是主动的，把团队拉疲惫 ，团队就失去活性了，失去解决问题的能力了（注1）。大部分时候加班的结果是逼迫团队 去“解释”，因为大家都很疲惫了，那就不行说到它行呗。所以，到了时间点逼近的时候考 虑加班，其实就是让大家在明面上不说，暗地里减特性，减测试步骤，做假，如此而已。 加班为主的开发过程，其实并没有加快效率。既然如此，你还能搞定时间点，除了作假， 还有什么？还能是什么？只是作假这件事不是出自某个人的组织而已。
正因为这个问题，不少组织是把项目经理和系统工程师或者架构师合并的。其实这些组织 就不认可项目经理有存在价值。系统工程师或者架构师才是必要的，至于“项目管理”，顺 手做做就可以了。
但其实不是这样的。每个有一定规模的项目，必然有资源钱粮问题，这个问题，埋头在技 术问题中的人是看不到的，就算你是系统工程师/架构师，或者特定领域的技术专家，对项 目的技术细节非常清楚，你一样不会注意到，比如：
2月份有一个展会，如果到时不发布一波，我们的社区热度就不够了
3月份，专家A就要被转到另一个项目中了，他这部分设计如果没有相关模块支持他尽快 搞定，这个事情后面就被动了
如果技术K，一直不突破，时间点X就守不住了
你们考虑用外包来完成手册的英文版重写，我们谈了几家翻译公司，这个费用项目预算 撑不住，不要想了，我们看看能否靠开发工程师自己搞定？……
这种问题，有没有领导都要面对的。就好比我们前面比喻的，你一群人穿过沙漠，到达下 一个水源点之前，我们只有这些水，每天能喝多少是要调度的。走哪条路有向导，拉骆驼 有骆驼手，防强盗野兽有保镖，这些是技术专家，但抛开这些人，你还是需要有人做“调度 ”的工作。这个工作就不是“小黄门”了，这是一个专门的工作：这个工作独立于目标本身的 技术要求，但它在统筹所有这些技术工作，让他们可以配合起来。
我们说本文谈的是“项目经理的自我修养”，是因为项目经理很容易走入一个陷阱，觉得自 己这些“统筹”其实并不重要（不是技术），所以非要卷入技术决策中，这就失去了项目经 理的本来存在基础了。这有三种情况：
项目经理本来就是技术专家。这没有问题，项目经理个人作为技术专家提供贡献对项目 是好事。问题是，你必须很清楚，你这不是作为项目经理的贡献。
项目经理不懂这个技术，但需要刷存在感，所以他介入技术讨论的要求中，这个是主要 问题，我们后面单独讨论。
团队其他人对项目经理有不切实际的要求。这是很常见的，不少工程师眼高于顶，觉得 除了技术其他都是浪费时间，市场、财务、法务都是给他打下手的，领导的钱都是他赚 的，项目经理，干脆就是多余的。如果你在这样文化的团队中，就别当什么项目经理了 。老老实实去当技术专家去，这个问题我们也不需要讨论。
我们说自我修养，重点说第二个问题。项目经理不是技术贡献者，他是调度者。所以，他 应该站在调度这个角度来解决问题。比如，技术人员给出这个结论：这个阶段点我们肯定 守不住了，至少延期1个月。如果这个确实是所有技术人员的共识，项目经理应该首先从调 度的角度上作如下推演：
这个阶段点延迟1个月，是否表示我们其他工作量估计也乐观了？是否都需要延期？
先把另一个做前导分析的工作停下来，补人进去能不能追上去？
我们怎么给投资人交代？策略性减特性，降质量，还是请求增加投资
这个阶段点延迟，我们可以从什么地方补救吗？
……
你看，这是理智的做法，甚至因为各种组织政治问题，你不肯说出口，但你的思维角度是 这样的，才是理智的。而不是：
你们骗我！不允许延期，如果延期了，以后所有成员晚上12点开例会，开完才能回家。
讨价还价：不要延迟一个月吧，要不半个月？
这个阶段延期一个月，下个交付点必须补回来
……
这些就是不理智的，你其实并不信任你的技术团队，用你自己的意欲参与到理智的决策中 。当然，理智也可以是技术团队真的在骗你，这可以是一个博弈。但，这其实考验项目经 理的另一个能力：如何取得团队的信任。无论如何吧，如果项目经理的不能取得团队的信 任，你以为你能真的把项目做好？
还有一种情形，困难的项目常常有很多阶段是不清晰的。比如我在这里介绍的情形：in nek：后软件时代和技术沙盘陷阱。里面最后提到的LLVM的开发过程的例子，这种开发过程 中，技术团队并不能一次给出整个项目从头到尾怎么做的计划，他们能判断这个工作是能 做下来的，但他们只知道第一步肯定是先改后端，也知道他们在性能不足的时候有可能会 修改中端优化和前端语法分析，但具体修改什么，他们不知道。
面对这种情况，理智的项目经理还是会意识到这是一种“技术现实”，而不是：“你们不能给 我一个计划，我怎么管理这个项目？”理智想一想，如果我们都认同这是一种“现实”，那么 你能不能管理这个项目重要吗？角色为现实存在，还是现实要为角色改变啊？
实际上，这种不能一次确定全部计划的项目项目经理的角色才尤其重要。因为这个过程中 你的团队成员的工作压力的目标可能全程都在变，每个阶段Review我们的目标，发现我们 工作上的破绽（比如团队重点在突破某个技术的难题，忘了这个技术后面公开的时候需要 法务提前分析清楚授权规则必须怎么写。这种问题只有项目经理才会持续关心，因为这个 在他的调度范围内），保证下一波冲锋的人力可以提前准备到位。这个工作量才真的大—— 让技术团队直接写一个所谓的全局计划，然后每天不用动脑拿着这个计划“跟踪”。这就把 自己退化为一个“小黄门”了，这能有什么贡献？
当然，现实中，每个人的角色都是有交叉的，所以问题并不会像这里分析得这么简单，我 们只是把问题的核心脉络给出来，让我们更能清晰面对这个问题而已。具体怎么做，我们 还要根据问题来进行详细讨论，但我们需要理清情况，首先得对问题有清楚的认识。
缺乏长期设计和加班经验的人不一定能理解什么叫失去“活性”，我刚工作的时候有一段时 间基本上是12点以后下班的。在这种“攻关生活”之前，我分析问题都是建逻辑链，建状态 机，分析问题在什么地方的，但进去这种工作状态后，我的脑子实在撑不住了，所以大部 分时候，我的工作方法就会变成：“要不试试初始化一下这个变量看看吧”，然后修改一行 代码，编译半个小时，然后花1个小时，加载6个机柜，看看，哦，问题还是会出现。那就 再修改另一个变量看看吧……这种工作状态，就叫失去活性。
这不是我才会这样，我工作这么多年，看过的各种团队，基本上都是这样的。你看着他们 在电梯间里互相调侃：“XX，你们今晚几点下班”，“唉，我们要10点”，“我们？哪有你们幸 福，我们10点才开攻关例会”。你以为这些人在抱怨？哪里，他们是在“比”谁更能抗。他们 只是在磨时间看谁更能熬而已。
如果你的目的是把项目做好，绝对不会希望团队陷入到这种状态的。当大家都变得疲惫的 时候，没有人会想怎么去解决问题，只是希望把进展“解释”出来，能过去就过去了。