怎样做项目管理

最近在网上看到一篇关于项目管理的文章，觉得说的很有道理，特意转载，以便学习。

最近面试了几个应聘项目经理的，有个感觉，不少人，无论是野路子出身还是正儿八经学PMP的，都抓不住项目管理的重点。

本文谈这个问题。一方面是有感而发，另一方面，项目管理其实也是架构师名称空间的一部分。

项目，学过PMP的都知道这个定义：项目是既定的资源和要求的约束下,为实现某种目的而相互联系的一次性工作任务。这个定义特别符合程序员的思路，所以我第一次上PMP的课，老师问这个问题，我在没有看过书的情况下，就能直接给出一个几乎一模一样的答案。因为对程序员来说，所有的问题，都是“给一个特定的条件，找出一个算法，得到相应的答案”。项目管理同样如此：我想在要做一个软件了，无论你如何设计，反正人就是这些人（当然，这是个动态的东西），找一个办法，让项目按质按量顺利完成，这就是项目经理的道。

项目管理千头百绪，事前的预估，过程的定义，甘特图的管理，关系网的建立，当知心大姐，当鼓劲领袖，当拿鞭子的监工，等等等等，不一而足。所以这才让很多人抓不住重点。很多人即使正规学习了PMP，其实是学的时候一回事，学完该野路子还是野路子，他们在PMP中除了学会一些名词用来唬住别人，或者唬住自己（证明自己不是打杂的），搞不清楚一个项目是怎么被控制住的。

这个问题还是要回到“守弱”这个主题上：相信可以解决问题的东西，不要相信概念本身。所以那个“项目”的定义才这么重要：你管控一个项目，不是为了满足PMP的那些方法论的，是为了实现项目目标的。那么你项目筹码就那么多，怎么能用这些筹码换你的那个结果？（放心，我不是给你讲无为，无为是架构师的事情，项目经理是负责虚心实腹打硬仗的）

所以，项目经理的核心工作是两个问题：WBS（甘特图）和风险管理。其他都是这两个工作上针对特定问题的插花。

WBS（Work Breakdown Struct）可以是任何形态，你写在笔记本上，用MS Project画图，还是用Excel一类的工具写成一个列表，都无所谓，工具对很多问题有帮助，但不是问题的核心。问题的核心是，你做任何长跑，都不会拿终点作为目标，所以你肯定是要分阶段的，如果你的工作依赖特别复杂（比如做一个数据中心的建设，这涉及采购，招标，申领牌照，开发，部署等工作），用一般的任务列表很难管理好，这种情况能画甘特图的软件能帮上很大的忙。其他的如小型的软件开发项目，常常是几个大迭代组织一组小故事的，基本上用任务列表就已经能管理得很好了。

WBS每个项目经理都会做，因为你再野路子，把任务分出阶段指配给人这种基本作用还是要发挥出来的。但项目管理真正体现能力是风险管理。很多人望文生义，把风险管理看作是加花的一部分，认为只是项目管理逻辑中其中一个（和很多其他方面并列的）方面了。却没有搞清楚，风险管理其实是整个项目管理工作的中心。我们需要一个项目经理，很大程度上是因为我们需要有人去管理所有的风险。因为项目最后没有按质按量完成，都是因为当初对WBS的假设有误，我们要守护WBS，就是提前发现WBS的破绽，然后把这个破绽消除掉。

我看过很多项目经理都没有正儿八经这样看待风险管理，他们在风险列表中列出的风险往往是些什么：“团队成员技术水平低，可能不能按时完成设计”，“人力到位有风险，需要领导给HR加大压力”，诸如此类的。这些其实不叫风险管理，这叫“打预防针”，是告诉“领导”或者“投资人”，“这个事情做不成，不怨我”。如果项目经理就这种水平，那真的怨不得别人会把项目经理看作是打杂的了。不少小组织，项目经理和技术专家（带头人）通常是一体的，原因就在这里，因为项目经理就是打杂的，如果单独养，根本养不起（战功不能和投资匹配），但项目管理是个专职的工作，基本上，如果你管理一个10人以上的团队，而且已经有了特定的交付目标，把核心技术人员（比如架构师）和项目经理合体，这个人将同时做不好项目管理和架构师两个工作（即使这个团队自组织能力极强）。人一多，时间一长，一起做一件事情，会有无数的风险：张三母亲病了，突然请假；李四找到了更好的工作，新人没法理解接手他的工作；关键的一个开发板从香港入关的时候不符合规定被海关扣下了；合作伙伴突然被人收购了，走了不少人；国家突然出台新规定，软件需要找广电认证；某个技术难度太大，根本搞不下来；项目拉得太长，投资人失去信心，取消项目；……回忆一下你失败过，延期过的项目，它到底是怎么失败，怎么延期的？把这个问题想清楚，你才会正经地对待风险管理。

就算没有这些“意想不到”的风险，其实有一类风险是永远存在的：就是你对设计目标和工期的预判很可能是错的。有人以为技术专家会比对技术理解不深的人（比如以管理为主的项目经理）能更好预判一个技术工作的工期。这完全是自欺欺人，开发过程序的，你们发自内心预判一下你自己对一个模块的开发工期的判断准确度有多高？ 基于技术来预判工期，远远不如基于项目管理经验来预判工期。而解决技术问题和预判工期根本就是两个维度，放在一起考量，基本上就是错误的开始了。项目经理不是那个做好计划就开始指手画脚的人，你看见他在拿鞭子抽这个敲那个，但实际上他脑子里每天都盘算着，“这个任务如果再延期下去，我就要停掉那个任务，补人进来充实这个任务了”。这是整个软件工程成功过程中，一个独立，必须，工作量巨大的工作，想靠管技术的工程师“顺便干”这个工作，和让写Java Script的工程师顺便去做个PCB板没有什么两样，根本就定不下心来。

我干架构的，我每天都对我分解出来的模块跃跃欲试，想自己把它实现了呢，实现一个模块，立即能感受到运行和成功的快乐，架构？那得等产品成功以后才能体会到快乐的事。项目经理一样，谁不想立即看到一个程序或者一个模块啊？但项目经理的快乐是要等项目成功以后才能评判的。

本质上，你把项目成败挑上身，你才是个项目经理，否则，你只是个打杂的。这句话听起来好像很情怀，很鸡汤，实际很现实：你不为投资负责，投资为何要在乎你？为什么宠辱若惊，贵大患若身？组织给一个人投钱，是分组织的压力，你轻轻松松一点压力没有，想进入就进入，想退出就退出，想就贡献点劳动力就拿大头？这个世界哪里来这样的好事？——能和组织共存亡的才能分这个组织中较多的利益，这样的组织才有前途。切掉你组织要痛的，你才有存在价值。

说远了，回到风险管理，要把项目挑上身，风险管理有三个要领，是每个项目经理需要掌握的：

1. 风险识别不来自项目经理，风险识别主要来自WBS任务的执行者，要用软件工程师收集需求的心态去识别风险。要要挟他们如果“搞不定我就杀你全家”这样的情怀把可能的风险逼出来。

2.为每个风险设定规避计划和应急计划。特别是应急计划。很多项目经理技术即使管理风险列表，也不好好准备应急计划。或者干脆搞不清楚规避和应急计划有必要区分。我是强行要求我的项目经理给应急计划的，因为只有你有应急计划，你才真心认为这个事情是个风险（而不是个延期的推脱理由），很多风险都是有一半几率会真的发生的，发生后会不会对你的项目造成致命的影响？你还罩得住不？这个才是问题的核心。看一个项目计划中有没有风险应急计划，很多时候就能判断这个项目经理到底是不是足够专业了。（我不怕告诉你这个，就算你拿这个骗我，背不上身的人做出来的应急计划一样是一眼能看出来的）

3. 在执行的过程中，要始终基于风险管理来管理WBS，不断响应变化。有了项目经理，技术或者业务为中心的成员（我不管这些人在组织中的地位是比项目经理高，还是比项目经理低），才有可能有效输出

能做好这三点，就是一个好的专业的项目经理了。