# 32 终极管理罪恶得主是…… 终极的管理罪恶是浪费大家的时间。听起来这像是一种可以轻易避免的罪恶，但事实却并非如此。作为管理者，你有一些你自己的诉求，这些诉求会让你做出的事情与合理利用你手下员工的时间相悖。 ### 举例说明 你组织了一个员工会议，自己却姗姗来迟（可能你不得不接老板打来的一个紧急电话），于是其他人就只能干等着。或者，你自己中途出去接一个重要的客户电话，然后会议就失去了关注点。或者是，你召集了一个会议，但显然会议明显是在耽误大家的时间（可能除了你自己之外，这是很多仪式型会议的典型特征）。 当你召集一个多人会议时，正常的假设是所有与会人员都聚在同一间屋子里，因为他们需要通过互动来达成某些结论。但当所有的参会人员轮流与一位关键角色互动时，这种召集一帮人开会的合理假设就不存在了；还不如单个找下属交流，而无须强制其他人参与。 我们在上面提及的可能是老板的需求得到了满足，或许要花费下属们的一些时间。但这是不对的吗？难道这不是老板为了保持控制而不得不做的吗？对于管理和协调复杂的工作来说，难道这不是合理的吗？答案模棱两可。传达状态并不需要开这样的会议；有很多更节省的办法可以做到。老板的需求并非获得信息，而是再确认。仪式就满足了这种再确认的要求。让每个人清楚老板就是老板，他来组织会议，员工参会是按预期进行，层级关系是要被尊重的。 ### 项目状态会议只关于状态 召开一次真正的工作会议，原因是需要所有被邀请的人一起来处理某种问题。会议的目的是达成一致。这样的会议在定义上就一定具有临时性。随之带来的就是这种会议不太可能遵循常规计划。如此推理，任何常规规划的聚会更多的可能是出于仪式目的，而要多过专注于达成一致性的目标。周例会就是一个典型的例子：看起来例会的目的是报告状态，但实际上真正的目的是状态的确认，并且不是针对工作状态，而是老板的状态。 当老板特别关注时，这些如仪式般造成负担的状态更新会议可能发展到无法控制的地步。比如，我们就知道一个组织每天都要召开两个小时的状态更新会议。如果参会者在会议期间木在办公室，就要求他们电话接入全程参加。缺席会议被认为是违纪，会受到严重的惩罚。 ### 早期超编 会议并非是唯一浪费大家时间的地方。当过多的人在项目初期就加入时，基本上总是会浪费大家的时间：同样的道理，你可能会认为这很容易避免：简单计算一下这项工作能够多快接纳新人；然后加入的速度按照计划不就成了二理论上这没有问题，可因为各种原因通常不具备可操作性。 项目开始于计划与设计，这些活动最好由小团队来完成。当设计很重要时（除了那种简单的公式型项目，设计都很重要），可能需要占到整个项目周期的一半。图 32-1 的人力规划可能是合理的。 图 32-1 看起来奇怪，但可能很合理 一个两年的项目，大部分成员半年到一年后才能上项目：但这又怎样呢？这样的人力规划有点不同寻常，但如果这是合乎现实的，为什么不能这样计划呢？ 当项目迫于紧张的时间压力下时，这一问题就凸显出来了——哪个项目不是如此呢？如果客户和高层管理下达了命令，例如只给了这项工作一年时间，这个限制就会缩短项目预期的结束时间（见图 32-2）。 图 32-2 进度紧张的项目（终止的人员安排） 很自然的，一种倾向就是把因为缩短时间而压缩的人力投入放到前期去。好了，这个项目就变成咱们熟悉的早期超编的典型了（见图 32-3）。 图 32-3 早期超编以满足最终期限 当然，如果你知道早期投入人力完全就是浪费，你不会那样做，对吗？好吧，或许你还是会这么做。你可能推断出了无论项目上怎么投入，要完成这样一个冒进的计划都是不可能的。要是你知道项目无论如何都会延期，那么在高层倾向于在项目早期多投入的情况下，你最好考虑一下如果不再添加额外人手是显得更好，还是更糟。就算早期投入最后被浪费掉，比起你想着要在前六个月按需精益投入，让大家早点上项目可能更安全。如果早期人员配备不足——失望的高层管理肯定会这么看——会让你看起来像个业余选手。 因为这种因素而造成项目早期超编，这种情况普遍吗？嗯，不太普遍，也就只有不超过 90%的项目存在这种情况吧。 评价这种在研发组织常见的文化现象确实让人失望，尽管谈论了许多“至精至简”的思想，对于一个项目管理者而言，在项目关键分析和设计活动中按需以精益的方式加人，在策略上仍然是不安全的。 ### 再说碎片化 当大家的时间都浪费在不必要的会议和早期的超编时，他们都心知肚明。他们会变得沮丧，却又清楚其原因。如果这种浪费至无可收拾，他们可能也会让你知道。所以，这个问题虽然严峻，但至少还是看得见的。然而，还有一种对时间的浪费却很可能是无法察觉的，因而没法改进。这跟我们在第 23 章中提到的碎片化有关。这里的重点在于脑力劳动者的时间被多个同时进行的任务碎片化，这种碎片化必然导致此人会工作在不同小组里，而这样的工作组是不可能凝聚成真正团队的。 时间碎片化几乎都会带来团队自毁，除此之外，还会带来另外一个潜在的副作用：必然会浪费个人的时间。一个同时兼具多项任务的员工——一部分新的开发工作、一些遗留系统的维护工作、售前支持或者用户见面会安排——每天必然会花费一部分时间用在工作准备上。这些时间根本就看不到。这位员工可能把正在进行的设计工作放下，花费 20 分钟通过电话引导一个来电者重新配置公司早期产品的数据库，然后又回到设计工作上。如果你拿着一个计时器站在他身后，你可能不会发现任何时间浪费。浪费悄悄地隐藏在此人第二次设计工作的缓慢起步上，这是打断工作流的直接后果。 当两项任务需要的工作习惯本质上不相同时，碎片化尤为有害。所以将设计工作（需要一个较长的导人时间、相对安静的环境以及与小组高质量的互动）和电话支持工作（需要不停的打断、可持续的服务和快速的注意力转移）混杂在一起，会让思考密集型的任务基本无法开展。特续重启造成的时间浪费只会让员工感到沮丧。你可能从没听谁提起，因为受这样问题困扰的员工可能更多是在自责。 ### 尊重你自己的投资 出于某种原因，在过去几十年里，我的咨询工作需要越来越多地到欧洲出差。我开始乘坐白天从波士顿到伦敦的航班，对我这样时差适应能力很差的人来说影响可以小一点。不幸的是，从波士顿出发到大多数欧洲国家的首都都只有夜晚航班。我不停抱怨这个问题，直到有一位航空公司的工作人员给我指出：航空公司并不是太愿意投入 747 这样的大型客机在这样的航线上，因为飞机在地面等待的时间，完全可以完成从东海岸到西海岸，再从西海岸返回东海岸的日航了。毕竟，747 可是要烧很多钱啊。 -TDM 你投入到工作中的人力资本也代表了不少钱。如果你所在的公司雇用了几千名脑力劳动者，那么在这方面的投资几乎可以看做是一架现代的宽体机。在如此巨大的投资上浪费时间，等于直接把钱冲到下水道里。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-wu-bu-fen-wo-tu/32-zhong-ji-guan-li-zuiede-zhu-shi.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.