《代码之殇》（原书第2版）——第1章 项目管理失当 2005年10月1日

2005年10月1日：“揭露真相”

我不可能说谎——多诱人的话啊，但也只能骗骗小孩。每个人都会时不时地说谎。有时是要故意掩盖一些细节，有时你没有说出你的真实感受，有时就是彻头彻尾的编造。不管是什么原因或者处在什么环境，说谎就是欺骗，含糊不了。

有些人可能想为这种行为辩解，称这是“善意的谎言”，但它仍然没有改变其本质：不诚实。如果有人发现我说谎，不管这个谎言有多么微不足道，我会立即充满懊悔并老老实实地坦白。不过在我小时候，采取的回应却是抵赖。但后来我了解到，抵赖比当初说谎引起的冒犯更具破坏性。大部分人，包括我在内，说谎的目的不是冒犯别人。我们的动机纯粹是为了私利。

不得不指出的是：欺骗其实是逃避问题的一种最容易而下流的方法。那么它跟软件开发又有什么关系呢？因为通过关注你或者你的团队“在什么时候”说谎，以及“为什么”说谎，你能查明从产品质量到人才保持的所有问题，最终提高生产力。

遭受错觉之苦

说谎是少数几个有价值的可以提醒你有麻烦的“过程噪声”之一。为什么这么说呢？因为说谎、时间周期、进展中的工作和不能替代的员工都会掩盖问题。漫长的时间周期和大量进展中的工作掩盖了工作流程中的问题。不能替代的员工掩盖了工具、培训和可重复性的问题。而说谎能够掩盖任何问题。仔细观察这些过程噪声能够发现问题，并且为过程改进创造机会。

作者注：上述每一种过程噪音我都会在后面的栏目中再次介绍，比如第2章的“精益：比五香熏牛肉还好”和第9章的“随波逐流”。至于下文的“5个为什么”，像“精益”一样，这些概念都来自于丰田汽车公司。
关键是要找出说谎的根本原因。有很多好方法，不过我这里要推荐的是应用“5个为什么”，即连问下面的5个问题：
 为什么你要说谎？你在隐瞒什么苦衷？
 为什么要隐瞒那个苦衷？有什么危险？
 为什么危险会发生？有没有办法避免？
 为什么你没能从一开始就避免危险？你需要采取什么样的措施？
 为什么你还坐在那里？赶快行动！

接下来，我们拿工作中经常碰到的、人们会说谎的几个例子来练习上述方法。我们将应用“5个为什么”，揭露说谎的根本原因，并讨论其解决方法。以下是谎言家族的邪恶四人组：
 滥用“做完了”这个词
 含糊地表达尴尬的考核评语
 粉饰给客户和上司的进度报告
 否认机构重组的传言

好好找一下自身问题

假设你的开发团队应该在星期一完成所有的功能开发。到了星期一，你在团队里巡视了一遍，每个人都说，“我做完了。”后来，你发现半数以上的功能都Bug成堆，四分之一的代码没有处理错误情况，没有辅助功能，也没有经过压力测试。你可能会问：“为什么我的团队水平越来越差了？”但更好的问题是：“为什么我的团队要说谎？”让我们来问5个为什么：

 为什么我的团队谎称已经做完了？他们想隐瞒什么？他们要赶一个最后期限，如果不能达标，就会降低他们在团队中的地位。所以要达标只要说：“我们做完了。”很简单。

 为什么只说做完了，但没有具体解释？有什么危险？没有人想让自己难堪。遗憾的是，说“我做完了”对个人来说没有任何危险。因此他们为什么不说谎呢？危险留给了整个团队。这才是真正的问题。

 为什么会发生这种事情？你能避免吗？问题在于，你没有给团队定义一个可验证的“做完了”的标准。这给欺骗留了一扇后门。为了避免它，你需要对“做完了”做一个清晰的定义，并且得到团队的认可，使用客观的手段去验证是否真的做完了。

 为什么你不对“做完了”做一个清晰的定义？你需要再做些什么？当你和你的团队对“做完了”的定义和验证手段达成一致时，你就要把工具准备到位。假设这个定义是：单元测试的覆盖率达到60%，并且95%的测试用例能够通过，另外还做了一个三方的代码审查，并找出其中80%的Bug。现在你还需要做的是，提高代码覆盖率，并在创建好的系统中为单元测试配置自动化测试套件，同时在一个合适的时间为审查员安排一次审查过程，然后就是做代码审检。

 为什么你还坐在那里？你需要的大部分东西都可以在工具箱中找到——除了首先你必须要有揭开“我做完了”的勇气。关键是要找准欺骗的原因，从源头上解决问题。

作者注：工具箱是微软内部共享工具和代码的仓库。这些工具可以用来评测代码覆盖率，进行单元测试，甚至为代码审查计算Bug抓取率。它们中的很多都已经集成到了Visual Studio、Office在线模板等产品中。

译者注：Bug抓取率=已经找到的Bug数÷估计的Bug总数。关于“代码审查”，可参阅本书第5章的“复审一下这个——审查”栏目。

给我个坦率的回答

你的一位员工工作一向很出色，考核分数你准备给她打40，你也这样告诉了她。但你的部门开了一次协调会议，那位原本能得40的员工只能得35了，因为相对于同部门的其他同事来说，她的绩效还不够好。你可以很轻易地对你的那位员工说：“我觉得你应该得40，但是你也知道，考核系统是相对的，我不能总是给你该得的分数。”

你在说谎，不是因为你说的话不对，而是因为你没有在这个过程中扮演好你的角色。让我们再来问5个为什么：
 为什么不尽到你的责任？你在隐瞒什么？你喜欢这位员工，不想责备她。
 为什么不责备她？有什么危险？你的员工可能就不喜欢你了，甚至离开你的团队。
 为什么会发生这种事情？你能避免吗？你是传话者，你的员工感到无助，你也帮不上忙。为了减轻负面影响，你需要告诉她如何去争取她想要的考核分数。
 为什么你不早告诉她？你需要再做些什么？你需要知道为什么她得了35，而那个人却能得40。

作者注：基于绩效的差异化薪水支付，这种做法在高科技行业中饱受争议。就拿这个数字考评系统来说吧，微软已经把它的过程改了很多次，即使这样，它仍然是基于把你的工作跟其他做相同工作的、具有相同职责水平的人去比较的原理。管理者要做的事，就是要理解这些规则，并且清楚地解释给你的员工听，告诉他们如何通过善意的比较去提高自己。

 为什么你还坐在那里？找出分别得40和35的员工之间的差异，然后告诉你的员工。她会对如何提高自己有个清晰的方向，并且控制那个提高过程。当然，她仍然可能不开心，但至少你帮助了她，她也知道了自己该做些什么。

给猪抹口红

对照时间表，你的团队的进度已经落后了。你有一大堆的Bug要去修复，根本来不及。你的客户和上司要求知道项目的状态。但你没有如实反映情况，而是给他们描绘了一张美丽的蓝图，好像你的团队有足够的时间去赶上进度一样。你变成了一个懦弱而无耻的人，你除了对此感觉不佳外，你还应该做些什么呢？下面是5个为什么：
 为什么要孤注一掷？你在隐瞒什么？你不想难堪或者让别人来干涉。
 为什么害怕被责备？有什么危险？你担心你的项目会因为你的无能而被搁置，或者转交给其他人去负责。
 为什么会有这种事情发生？你能避免吗？如果你的客户和上司在全无征兆的情况下发现你们要延期了，他们将不再信任你能继续胜任现在的职责。为了避免这个问题，你应该让你的项目状态透明从而避免给他们带来一个冷不丁的错愕，并且给出一个可靠的计划，使项目回到正常的轨道上来，这样才能赢回你的客户和上司对你的信心。
 为什么你不一开始就让项目状态透明？你需要再做些什么？经常收集你的团队的状态，然后公布或者通过Email发送出去，这给你的工作增加了大量的额外负担。替代方案是，你可以毫无掩饰地在你的SharePoint站点上公布你的项目时间表和Bug数据，并要求你的团队直接在上面更新，以便所有人都能看到。使用图表来清楚地表示进展情况（或者没有进展）。当数据更新之后，通知一下你的团队。所有人对项目状态都有了统一的认识，你就能按照计划把项目带回到正常轨道。
 为什么你还坐在那里？没什么难的。项目状态透明使工作有条不紊，同时你也赢得信任，而信任是事关你能否成功的关键要素。

看看所有这些传言

机构重组的传言漫天飞舞。你的产品单元经理曾经交待过你不要声张，但期间你的团队开始胡乱猜测。不可避免，这个话题在你的团队会议上被提了出来，但你对是否知情矢口否认；你告诫大家流言的祸害性，并提醒大家需要把精力集中在他们当前的工作上面。然而，你心存内疚，终日担心有一天整个团队都知道你当着他们的面说了谎。

作者注：产品单元经理（Product Unit Manager，PUM）是微软内部的第一级多领域管理层。产品单元经理通常负责一个大的产品线（比如Office）上的某个产品（比如Excel）。他们也可能负责一个大产品中的一个重要组件，比如Windows的DirectX。机构重组（Reorganization）通常从最高级的管理层开始，然后在随后的9~18个月内慢慢地向下扩展开来。关于机构重组，我在第10章的“我是怎么学会停止焦虑并爱上重组的”栏目做了更多的论述。当微软公司向一个高效的组织结构演化的时候，产品单元经理是一个很稀有的角色，我同样将在第10章的“我们是否是功能型？”中论述。

 为什么否认这些传言？你在隐瞒什么？主要是因为你的上司交待过了要你保密。你不想你的团队比你的上司更能胡乱猜测。
 为什么担心对传言的胡乱猜测？有什么危险？你担心你的团队被流言卷入太深，从而影响到正常的工作。另外，有些团队成员甚至可能因为害怕不称心的改变而选择离开你的部门。
 为什么会有这种事情发生？你能避免吗？大部分团队成员，尤其是那些高级成员，知道有时候重组会变得很糟糕。然而，没有人（包括你）知道重组是否真的会发生，也不知道最后会重组成什么样子。因此，你团队的顾虑根本就没有事实依据。
 为什么你的团队仍然在为传言焦虑？你需要再做些什么？出现这种情况的话，问题恰恰就在你身上。你对传言太焦虑了，刻意不把你所知道的告诉你的团队。你应该知道，迄今为止，在曾经计划的重组中，真正发生的其实大概只有三分之一。
 为什么你还坐在那里？这里的解决方法很简单，也很明显：说真话。“对，我也听到了很多传言。我们在员工会议上讨论过了。不过，在重组真正发生的那一刻之前，最起码，没有任何人知道是否真的会有一次重组。大部分计划中的重组不会发生，而因为我们的胡乱猜测延误了正常的工作，那我们就太愚蠢了。”

我想知道真相

我对人们是否应该永远说真话并没有定论。否则，别人会觉得我很虚伪，就像在我的丈母娘问我对她的装饰的看法时，会给我惹来一身麻烦。

然而，我们为同一家公司工作。你不应该在业务问题上对你的同事说谎。谎言掩盖问题，但问题其实应该暴露出来。如果你觉得你必须说谎，问问自己为什么。然后再次问为什么，直到你找出真正的问题所在。人们一直想知道如何去实现“可信计算”的第四根柱子——“商业诚信”。现在你应该知道了吧！