第一章 项目管理失当

    我的大儿子会开车了。但也为我的生活平添两份担忧：一是我已渐感年老，二是颇为我的儿子担心。为了减轻这第二种担忧，我和我的妻子设了一个强制性的禁令：我的儿子如果回家晚了，他必须先给家里打个电话。有一天，他回家晚了20分钟又没事先通知，我们生气了，我的妻子愤怒是因为他晚了20分钟，而我愤怒是因为他没事先打电话通知。

    为什么我的儿子没有打电话说要晚点回家？因为，跟我妻子一样，他只把注意力放在计划上。在回家之前，（不打电话）他可以避免纷争。他说：“我已经尽我所能早点赶回家了”——为此都好几次违反交通规则。但我的儿子没有明白要点，规矩的目的是想减少风险，而他对此做出的反应是增加了风险。

    软件工程师也经常这么干。从一个开发计划开始，非人所愿的问题就随之发生，然后他们就延期交工。为了避免纷争，他们往往并不向项目经理提及延迟的事，而是匆忙赶工，牺牲质量，草率应付计划，所有这些都使工程陷于不可控也不透明。其结果跟项目经理所料恰恰相反，而那些项目经理是严格按部就班执行计划的。为什么？因为多数项目经理及工程师不能区别这两种计划——兑现承诺及风险控制。

    作者注：我很喜欢这个专栏，它囊括了关键性及基础性的问题，虽然这些问题通常被误解。我希望我的家庭、我的朋友、我的同事及我的团队都读一读。

    谁懂事物具有两面性，谁又不懂？

    的确，有两种类型的时间表及项目管理技术。

    兑现承诺。你向客户或者合作伙伴做了承诺，你必须遵守承诺按时保质完成任务。要按时。

    风险管理。工作有关键性及期望性之分。人们或许会做出错误的选择从而产生问题，你必须善于进行风险管理以保证关键性工作的完成。

    这两种项目时间表及项目管理技术往往会被搞混，为什么？

    它们通常同时发生。承诺贯穿于整个工程项目。但它是由许多个小任务组成并需要风险管理。

    两者都有时间表。不同的是向客户承诺的计划时间表不可精确确定，但所有人及事情又为其所驱使。而风险管理的时间表可以有很多监测点以保证其踪迹可寻。

    它们都可称为计划。很多人不知道二者的区别。

    人们所被告诫的往往只是承诺。当适龄儿童入学后，他们就因为有时间表及规矩显得中规中矩。当他们日后学习了项目管理，就只知道甘特表及里程碑，而把风险管理抛在脑后。

    风险管理往往是自我学习的过程，是非正式的。只有一小部分人真正学习过风险管理，大多数人只是在大学里为应付大工作量的任务才向同僚们效仿了一下。我们不是将所有事情及时完成，而是成立工作组，只关注关键性工作，以及极力减少有损我们评分的可能。

    不能很好理解这些道理的惨痛结果是导致可怕的决策、可悲的工程实施以及计划失败。你必须知道二者的区别以及将正确的计划应用到相应的问题上。让我们从兑现承诺开始。

    这是你唯一承诺的事

    “兑现承诺”是跟他人合作的基本准则，也是多数商业行为的准则。在需要内部相互依赖、外部相互信任的情况下，如果产品没有按工程日期安排及时到位，你们的工作就无法协调进行。因为承诺是前后关联的，你必须及时完成承诺之事，不然你就会面临惨重失败。

    假如你女儿的生日快到了，你承诺说将给她买一款她喜欢的新游戏，如果别人承诺了游戏出品时间而又没完成，你会是什么感觉呢？在开发者、厂商、销售商以及你之间是手手相传的链条，所有这些都及时到位才能确保在你女儿生日的时候让她开心。

    当然，这对基于Web的产品来说是相对容易的，但是在团队及部门间相互关联的过程中还是会产生同样的问题。承诺并交付产品才使信任得以建立，及伙伴关系得以维系，失信则相反。虽然很多软件项目只需要很少或根本就没有团队协作，而运作大型成熟的项目通常就需要守信以及其他项目管理技术。

    作者注：为了有助于做出承诺，一个公司通常使用库存、保留余地以及其他风险管理的形式为实现承诺的每一步骤提供保障。这就是风险管理的精髓。你使用正统的项目管理方法确保整体目标的承诺得以履行，而使用风险管理确保履行承诺过程中的每一个步骤无恙。

    你不认为那是一种风险吗

    风险管理是关于如何确保关键性工作得以完成的论题，即便是在一个极易变动的环境里。Scrum及Feature Crews就是两个在软件开发中比较突出的例子，它们关注于风险管理，确切地讲，风险意味着你不能高效地将有价值含量、高质量的产品提供给客户。

    就像我在第1篇专栏“开发时间表、飞猪和其他幻想”中提到的那样，开发计划及测试计划都在风险管理之列。所有的标志性日期都是降低风险的检测点，但只是仅有的几个跨团队的同步检测点（标志性里程碑）才是向客户承诺的要点。

    什么才是风险管理的重点、先后次序以及其表现状态，这还没有确切的说法。只要注意什么是重要的，先把重要的做好并在条件改变的时候跟踪其状态就可以了。注意，紧盯着细节工作日程安排并不重要，你在规定的时间以规定的质量完成最关键的任务才是重要的，其他的可以不用太在意。

    这就是为什么你要告诉你的工程师，就像我告诉我的儿子一样：“是否按时回家并不重要，告诉我们你不能按时回家了才是重要的。”如果你知道风险的存在，你只要管好这些风险就可以了，工作时间表只不过用来提醒你计划需要更改了。

    当然，你不能过了向客户承诺的时间（一个标志性里程碑）而将关键性任务一直向后拖延，就像我的儿子不能在外超过凌晨1点钟，不然我们将没收他的驾照。禁令应事先设置，它防止了可能发生的这种灾难，这就是禁令应具有的功效。

    作者注：有很多众所周知的风险管理技术。这里顺便列出几个在软件开发中用得到的（好几个在前面的专栏提到过）：

    开几次常务会议，15分钟左右，谈谈进展情况、未来的期望及目前遇到的一些难题（称为Scrum迷的Scrum会议）。

    为所分配的任务做个备案（在缺乏经验的人与富有经验的人合作的情况下）。

    留点余地——安排些额外的时间以备不测（就我个人而言，我向来不喜欢这种方法；我宁愿为任务列一个优先次序表也不愿有面面俱到的想法）。

    轻在承诺而重在成果——也可以说是量力而行。

    留有退路——始终谨记为有风险的任务设个预案，比如削减功能模块或重新使用老版本。

    平衡风险——当事务发生变化时，通过增加或移除风险始终使你的项目保持在一种常态：有点担心但并不恐怖。比如，如果一个团队成员的父母过世了，你的风险就增加了，所以你必须削减具有风险性的功能模块或重新将那项艰巨的任务分配给一个高级工程师。

    选择一个正确的工具

    所以，当你开始对一个计划付诸实施之前，先等一下，思考一下计划都有什么。其中是否有一连串的约定时间及产品需要交付？或者有哪些不同优先级的重要任务你需要跟踪监视并防止其错过的？

    就比方说我儿子回家的禁令，不夸张地说，那就是我不容许他破坏的任务。因此，我们需要风险管理以及需要及时关注其状态的重点，而不是说关注什么时候回家这样的事。这样的模式很适用于大多数软件开发项目。你只是想你的工程师及时告知你情况，这样如果他们延时了，你可以进行调整。太精细是不必要的，而且会适得其反。

    然而，如果你跟多个团队及合作伙伴实施一个大型项目，那么在一定级别的层次上，你们相互间的承诺及同步是很重要的。在这个层次的时间表上都是一个个里程碑以及经典的项目管理工具。

    不要将高层次的工作计划与低层次的任务相混淆，如果你对待低层的相互间约定像对待高层的一样，你的工程师就会抄近路并快速赶工，你可能就会导致他们破坏整个关键性任务，从而破坏了你高层的客户合约，风险管理也就无从谈起。你在合适的层次使用合适的方法，你一晚上都会睡得很好的。

    作者注：更多关于传统项目管理技术与敏捷项目管理技术组合的话题，参见下一专栏“敏捷的团队合作”。