地毯的下面(摘自《人月神话》)

        当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差，他可以想出应对方法或者重新安排进度以解决问题，为什么要去麻烦老板呢？从这个角度来看，好像还不错。解决这类问题的确是一线经理的职责。老板已经有很多需要处理的真正的烦心事了，他不想被更多的问题打搅。因此，所有的污垢都被隐藏在地毯之下。

        但是每个老板都需要两种信息：需要采取行动的计划方面的问题，用来进行分析的状态数据3。出于这个目的，他需要了解所有开发队伍的情况，但得到状态的真相是很困难的。

        一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用，降低自己的威信，搞乱了其他计划。所以，只要项目经理认为自己可以独立解决问题，他就不会告诉老板。

        有两种掀开毯子把污垢展现在老板面前的方法，它们必须都被采用。一种是减少角色冲突和鼓励状态共享，另一种是猛地拉开地毯。

        减少角色的冲突。首先老板必须区别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。我曾经认识一个老板，他总是在状态报告的第一个段落结束之前，拿起电话发号施令。这样的反应肯定压制信息的完全公开。

        不过，当项目经理了解到老板收到项目报告之后不会惊慌，或者不会越俎代庖时，他就逐渐会提交真实的评估结果。

        如果老板把会见、评审、会议明显标记为状态检查（status-meeting）和问题－行动（problem-action）会议，并且相应控制自己的行为，这对整个过程会很有帮助。当然，事态发展到无法控制时，状态检查会议会演变成问题－行动会议。不过，至少每个人知道“当时游戏的分数是多少”，老板在接过“皮球”之前也会三思。

        猛地拉开地毯。不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审。

        有报告显示关键的文档是里程碑和实际的完成情况。图14.1是上述报告中的一段摘录。它显示了一些问题：手册（SLR）的批准时间有所冲突，其中一个的时间比独立产品测试（Alpha）的开始时间还要迟。这样一份报告将作为2月1号会议的议程，使得每个人都知道问题的所在，而产品构件经理应准备解释延迟的原因，什么时候结束，采取的步骤和需要的任何帮助——老板提供的，或者是其他小组间接提供的。