不要相信所谓的管理神话
⇨⇦
管理神话之一：得不偿失的100%利用
在最近的一次活动中，有一位经理把我拉到一边，对我说：＂Johanna，对于敏捷这东西，我总有些不太明白。显而易见，并不是所有人都被100%利用了。＂
＂他们没有被100%利用又怎么样呢？你觉得这有问题？＂
＂见鬼，是的。我付他们工资！因此，我想知道我会从他们身上获得满满的价值！＂
＂如果我告诉你，你获得的价值可能比你支付的要多，也许有1.5～2倍，你觉得怎么样？那样你就开心了吧？＂
那位经理平静下来，然后转向我，继续问：＂你怎么知道的？＂
我微笑着说：＂以后再告诉你。＂
有太多太多的经理相信＂100%利用＂的神话。那是一种信仰——每个技术人员在每一天里的分分秒秒都必须被充分利用。这个神话的问题在于，人们没有时间去创新，没有灵感，也没时间去探索。
更糟糕的是，还会出现僵局。在一个人被100%利用的情况下，你在A项目上需要他的时候，他可能正在做着B项目。你们无法聚集起来开一个会。你不能打一通电话。你甚至没有合理的时间去回复邮件。为什么呢？因为你对各种其他打扰已经应接不暇了。
我们为什么会这样？
回到早期的计算，机器比程序员要昂贵几个数量级。在20世纪70年代，在我开始以程序员身份打工那会儿，那时的公司可能会给经验极其丰富的程序员支付5万美元的年薪。而对于那些刚刚从学校走出来的新手，公司支付的年薪可能不到1.5万美元。
我们当时觉得已经赚得非常多了！相比之下，公司可能每年花很多万美元的钱去租赁机器，或者花数百万美元买下机器。你可以看到，薪资水平与机器成本之间相去甚远！
在电脑有那么贵的时候，我们利用了机器时间的每一秒钟。为了上机，我们需要登记。我们在桌上检验自己的工作。我们进行设计评审和代码评审。我们珍惜上机时间的每一分钟---没错，我们的工作常常受限于CPU的一分钟时间。如果你想用更多的时间，那就预约下班时间吧，比如半夜2点～4点。
需要注意的是，那时候珍稀的不只是上机时间，还有内存。在那古老的岁月里，我们的内存只有256字节，代码是用汇编语言写的。我们的代码要分页。如果你有一段程序超过一页，你得在一页的末尾转移到另一页有空的地方，以便于换入。（这常常需要手工完成。噢……我一点也不怀念那个旧年代！）
到20世纪70年代后期以及80年代，微型电脑的出现拉近了程序员薪水与电脑价格之间的差距。不过，也只有当微型电脑的价格真正下来了、并且个人电脑开始主导市场的时候，程序员的身价才变得比电脑贵多了去了。到那时候，很多人都觉得，让程序员独占电脑的工作方式成本更低，这比设计评审、代码评审或与其他人讨论架构更有效。
到了20世纪90年代，尽管电脑、硬盘和内存的价格持续下跌，程序员和测试人员的身价也变得越来越贵，我们中的一些人清楚地认识到，软件开发更多是一种合作，而不只是程序员单独面对电脑那么简单。这也便是为什么Watts Humphrey（请见文末译者注）和软件工程研究所在90年代备受瞩目的原因。
不是因为人们喜欢繁琐的流程，而是因为（特别是在一个串行周期里）你必须采取一些措施，以使得系统开发收获更大的成功。很多管理者陷入了＂100%利用＂的思维泥潭。需要注意的是，＂100%利用＂的概念在当时被提出了没多久，并且很受重视！
当一台单进程的电脑被完全利用的时候，请记住——这意味着：它一次只能做一件事；它不能服务于任何中断；它不能响应任何键盘输入；它不能更新状态；它只能一直处理下去，直到完成。
如果程序表现良好，并且不受限于I/O、内存或CPU，运行在一台单用户、单进程的机器上，比如只有加减乘除功能的个人计算器，那也许还没事。但只要你加入另外一个用户或者另一个进程，你就麻烦了（或者，如果程序表现不正常、没能很好地完成，你也会陷入麻烦之中）。
现代的电脑就是那样。现代电脑都是多进程的机器。
对于多进程的机器，如果一台电脑被完全利用，你会看到系统抖动，可能还会僵死。想一想高峰时期的公路，没有一辆车动得了；这时候，公路是被100%利用了啊。但是，我们不想公路被100%利用。我们也不想让眼前的电脑满负荷运行。如果你的电脑被用到了50%～75%，你会感觉它变慢了。而高于85%时，电脑会有难以预期的表现。它们的生产力是不可预期的，你无法判断会发生什么状况。
遗憾的是，人类也面临同样的问题。
为什么100%利用不适用于人
现在，想一想我们自己。当我们在100%利用的状态中时，我们根本没有闲暇时间。我们在各种任务或干扰之间疲于奔命，没时间思考。这时候，至少有两方面的问题：难以避免的多任务，以及没有思考。
实际上，我们根本不是多任务并行——只不过是快速切换而已。我们不像电脑；电脑在切换时，它们把内存里的东西完美地拷贝到磁盘上，当需要换入的时候，能够再次把数据读进来。
因为我们是人，我们不能完美地把我们脑子里的东西备份出来，后续也无法再完美地恢复。因此，切换是有成本的，因为我们在处理其他事的时候必须记住之前脑子里在想的东西。那也需要占用时间。
因此，这里有一个情境切换的问题，我们需要花费时间把脑子里的东西换出去、换回来。所有这些时间和不完美会累加起来。因为我们是人，我们不能为各个任务完美地分配自己的时间。假设我们手上有3个任务，我们不能做到在每个任务上花费33%的时间——只要我们乐意，我们想在一个任务上花多少时间就花多少时间，平均33%只是一个假设罢了。
接着，让我来解决100%利用中没有思考的问题。如果你想让大家考虑换一种新的工作方式，怎么办？如果你令他们满负荷地工作，他们会尝试吗？没机会！他们不会考虑，因为他们没有时间。
因此，你让大家机械地工作：用他们了解的最佳方式去服务于各种中断、做尽量小块的工作、做到足够多就算通过。他们不会想办法去提高，他们不会想办法去帮助别人，他们不会尝试创新。他们只是在想，＂我怎样才能从这堆积如山的工作中解脱出来？＂这对他们来说是很恐怖的，对产品也不好，对与他们打交道的任何人都不好。
当你让人们工作在100%利用的状态，与你计划让他们每天大概只干6小时的技术活比起来，你从他们那里得到的工作成效会小得多。人们需要时间去阅读邮件，去参加临时的会议，休息一下，进行一些架构方面的讨论，喝杯咖啡，或者做点别的什么事。如果你为上午计划一大块的工作，为下午再安排几个大块的工作，并把会议的数量降到最低，技术人员会很好地完成分配给他们的工作。
如果你在一个喜欢开会的组织里工作，你甚至不能计划每天6小时的技术活——你必须计划得更少一点，会议在浪费人们的时间。
但不管怎么样，如果你按照100%利用来计划，在整个组织范围内完成的工作会少得多。你营造了一个可怕的工作环境，这还是一个没有创新的环境。那不像是一条成功之道，是吧？
敏捷和精益让神话破灭
敏捷和精益不会使＂100%利用＂烟消云散，但它们让神话破灭了。通过把所有的工作装进Backlog（一个管理积压工作的仓库），这有助于管理层和研发团队看清楚每个人应该做的事情，以及大家面临着多大的挑战。这很不错！
一旦每个人可以把工作可视化，你就能围绕它开展工作了。也许某些工作确实与产品路线图相关，但不必在这个迭代里完成。也许有些工作是为另外一个项目做的，应该被推迟到下一个迭代周期。这很好——这就是项目组合管理。也许有些工作应该由某人来做，而不是这个团队来做。这很好——相关管理者需要出面协调。
不管你做什么，只有你看到了工作，你才能有所作为。只要你完全地把工作可视化，你就能管理。
记住，如果你被100%利用，那就没人能做事了。如果你想为你的组织贡献实足的价值，你需要让自己被＂利用＂到50%～60%。因为浪费思想（不管什么思想）是件可怕的事。
管理神话之二：只有专家才能做这事——怎么破？
你需要做一件特定的事情，比如设计一个新的数据库或者一个特别的用户界面，或者你需要一位发布工程师，或者需要一位UI设计师，或者你想测试系统的某个部分，但是，平常做那个工作的人偏偏不在——在你的项目里，你碰到过多少次这种情况？你的项目受到什么影响？是不是只能等着那位专家回来？
在项目等待专家的情况出现时，很多管理者感觉还是可以抡上三板斧的。他们可以让项目等一等，也可以请专家多任务并行，或者他们拽来另一位专家顶上。
毕竟，在任何项目里，你并不是时时刻刻都需要专家。三板斧还是挺管用的，不是吗？任何数据库管理员、高级测试人员或发布工程师难道不都一样嘛（随到随用），即使他们对你的项目的过去和未来一无所知？
不对，完全不是那么回事！在项目需要的人没有着落之前启动项目是不妥的。让一个人多任务并行也是不妥的。而且，不了解你的项目的人在你的项目里其实也不能算专家。
你还可以有别的做法。那就是，通过多种方式来降低对专家的需要。你可以让专家与其他人配对工作；你也可以在你的项目里完全不用专家；或者进行项目组合管理，使得真正需要专门技能的项目错开；你还可以雇用更多的专家。
别让专家独自工作
有时候，项目需要的专门技能是可以让团队里的其他人学会的。举个例子，也许只有一个人精通构建系统，但一个项目里的所有人都需要知道怎么使用那个构建系统。在那种情况下，我会让精通构建系统的那个人与团队里的每个人逐一配对工作，直到每个团队成员都像那个专家一样熟悉构建系统。
千万别让专家独自工作！通过这种方式，你可以让专业技能在团队里传播。根据技能的具体情况，你可能首先需要召集一个研讨会，以使所有人对那个工具或技术都有一个基本一致的了解。
有时候，确实有必要让发布工程师开一个讲习班，花几个小时讲解一下构建系统的内部工作原理，然后让他与每个人一一配对，确保所有人都明白怎么使用那个系统。在数据库管理方面，很多时候你也可以采用相同的模式。
如果专业技能主要是工具使用方面的，或者是与其他团队成员现有技能类似的一种技能，上述这种方法是很有效的。但如果你处在一个需要关键领域的专业知识才能解决问题的场合下（这时候人们必须深入代码库的＂心脏＂），你就要采取其他方法了，比如内部抛弃。
抛弃不可替代的专家
有些人看起来是不可替代的。如果他们正在做其他项目，而你想要动一下＂他们的代码＂，你的项目必须等他们有空。
那是很荒谬的，千万别落到那种境地！抛弃他们吧！或者，如果他们正在参与你的项目，让他们做别的项目去吧。不管你采取什么方法，你得马上把他们从你的项目里请走。如果那个专家在做其他项目，但只要他还留在公司，你仍然有机会求助于他。
将来有一天，那个专家会退休，然后在加勒比海扬帆起航，在下午4点就喝起了美味的朗姆酒，你将再也找不到他。你想让你的团队成员什么时候锻炼他们的专业技能呢？我想让团队在专家还在的时候就开始。
团队对专家有一种不健康的心理依赖，而专家对团队是一种互惠关系。我不是心理医生，我也不想扮演电视里的那种心理医生，但在项目管理领域，这是很糟糕的！为了专家的自尊，整个团队都在抚慰他。这还阻碍了团队里的其他成员了解自己的产品。
如果你在一个大公司里工作，作为管理者，你可以安排把专家转入另一个项目。如果是在一个小公司，你可以让专家去做一个特殊项目。确保那个特殊项目有足够多的成果要交付，这样的话，专家就会很忙，让他无暇顾及之前的老项目。
团队将学会如何一起进步。一旦你将专家排除在外，团队有机会成为一支真正的团队，因为现在团队成员有了一个共同的目标。
一旦专家被排除在外，团队成员就要团结起来，快速发现他们所不知道的东西。他们会把各自知道的东西拿出来分享。然而，你必须允许专家每周花一点时间来支持团队。起初可以是一个小时，然后，只有当团队走投无路的时候才能去找专家。为了搞明白产品的工作原理，你要鼓励团队动手去试验，而不总是问问题。
把需要专家的项目错开
也许你的专家没有自尊问题。也许你确实有几个安全方面的专家，你需要他们完全专注在一个项目上。也许你期望A项目现在能完成，然后你就可以启动B项目。但是，A项目还没做完呢。好吧，这个问题容易解决。如果A项目比B项目更有价值，别启动B项目。如果B项目比A项目更有价值，把A停了去做B。是的，就这么简单！
不过，你会说，我们还没把A项目发布出去呢。好吧，如果你在A项目上使用了敏捷开发方法，也许你已经攒够了有价值的东西去发布。但也未必。那就太糟糕了！本质上来说，项目组合管理是一种零和游戏。因此，你需要为整个组织选择最佳方案。你确实想让组织取得成功，对吧？
项目组合管理其实就是在组织级别上进行艰难的讨论，避免同时做两个项目，要不然会把两个项目都拖累了。
A项目和B项目，哪个更有价值呢？哪个项目会推动组织前进？你怎样能以最小的代价做一次有价值的发布？这就是你需要问的一些问题。
如果你还没有在A项目上采用敏捷方法，现在开始也不算太迟。把快要做完的功能赶紧做完，然后评定剩下的各个功能的重要程度。我们希望，你开始以功能的重要程度依次开展工作。
雇用更多的专家
如果你真的想要同步推进A项目和B项目，你就必须雇用更多的专家了。即使是这样，招到人并促使他们产生效能还是要费些时间的。不过，雇用更多的人确实有效。
了解根本原因
我们的组织里之所以有这么多并行任务，其中一个原因就是我们的很多专家的知识面都很窄。他们的专业技能越局限，项目就越少能用到他们。但当你需要那种人的时候，你真的是非他不可。
关于专家以及只有专家才能做特定的工作的传说有很多。确实有些工作只有专家才能做。真正的问题是：这类工作有多少？我不指望开发者变成测试人员，反之亦然。我也不期望UI设计师变成安全专家。
但作为一个管理者，我希望项目里的每个人都能对项目充分了解，乃至对整个项目都很精通。最重要的是，我期望专家与其他人一起工作，以促成知识共享。
在产品开发中能够使用比较通用的方法的人越多，你的项目就越具有灵活性。于是，当我说，＂工作在团队中流淌而过，＂你赞许着对我说，＂当然。要不然怎么行？＂
你不必排除专家。你要做的是，降低对他们的需要，并且提高组织里的每个人的技术能力。
管理神话之三：人人都须被同等对待
最离谱的管理神话里有这么一条，＂我必须同等对待所有人。＂在组织内部，我们有职业阶梯，它试图把我们都装进一个个简陋的盒子里，让我们逐级晋升。这里假设了每个人的思维方式都一样，他们都喜欢相同类型的项目。但真相胜于一切！每个人都有不同的职业目标，而且那些目标还会在职业发展的过程中有所改变。
Susan是一位管理者。让我们来看看她是怎样在与下属的一对一会谈中讨论职业发展的吧。
两周前，Susan问Karen（一位资深开发者），问她下一步的职业发展计划是什么。
＂Karen，你好！考虑过你的职业发展计划了吗？＂
＂嗯，考虑了。我想继续得到购书补贴。我还想做一些改变。以前只是我一个人享有购书补贴，现在我想请你把这个补贴开放给整个团队。我从书上了解到一种新形式的阅读组。我觉得这次行得通。很遗憾，上一次我没能带动任何人跟我一起读书。＂
＂关于如何鼓励人们适时阅读，我有一个想法。与其只是每周读一个章节，不如我为每一章都准备练习和游戏。我想要这么做，而不只是讨论。我觉得效果会很好。况且，我也想提高自己的组织协调能力，这样的活动正好能帮助我发展这方面的技能。＂
＂这个想法太棒了！＂Susan表示赞同，＂你觉得第一个月需要多少钱？在团队读完第一本书以及你完成了第一套练习之后，我们可以再评估一下效果。＂
＂我还想参加当地的一个交流会，＂Karen继续说，＂我非常想参加11月份的那次全国交流会。＂
＂好了，这就是我的完整计划。我可以把各种开销都加起来，看看还需要做什么调整。给我几天时间，然后我再告诉你吧。＂Karen最后说道。
在那一天的晚些时候，Susan还与David（另一位资深开发者）碰面了。他漫步走进Susan的房间，然后坐下。他故作懒散状，咧着嘴，笑道：
＂Susan，最近怎么样啊？＂
＂Dave，那是我该问你的问题！告诉我，你考虑过你的职业发展计划了吗？＂
＂我考虑过了。我还有一个小问题。我不想被派出去培训。我就想待在这里工作，这样可以开车带孩子们出去玩玩足球之类的。我非常喜欢每周都有几天能早点离开公司，然后教小Dave打棒球、带Jenny和Barbara去跳体操和舞蹈。我从没想让自己变成奶爸，但我确实乐在其中。在我开车带着孩子们的时候，他们总是滔滔不绝地跟我说话。几年以后，Jenny就可以自己开车了；但在那之前，我真不想出差。＂
Susan笑道：＂我觉得那不是问题。我确信，你不必去任何地方。你怎么会觉得那是个问题呢？＂
＂好吧，我需要提高自己的人际交往能力。我在团队里还行----我可以和任何人合作，与任何技术人员面谈也没有障碍——但当我想从销售人员那里搞清楚需求并建立验收标准的时候，我把问题抛给他们，而他们却看着我无言以对，似乎我是从外太空来的，比如火星、金星之类的。＂
＂只是你有这个问题呢，还是其他人也有同样的问题？我应该尝试引入一些培训吗？＂
＂我不知道，＂Dave说，＂我需要找别人也了解一下。＂他在自己的笔记本上做了一些记录。
＂我也会收集一些信息，＂Susan说，＂你还想做其他什么事吗？＂
＂嗯，不过这听起来会有些奇怪。我想启动一个较为正式的‘边午餐边学习’的系列活动，主题围绕我们系统的内部原理。我们的系统正在越变越大。我们也已经招募了更多的人才，现在都有3个团队啦！我们在管理着技术债务，我想确保它是持续受控的。
因此，我想确保所有人都理解正在发生的事。我不想让测试人员与开发人员失去同步，也不想让资深开发者与资历较浅的开发者步调不一致。我不知道这对我来说（或者对任何人来讲）是否算职业发展，但我看到了这个需要，我也确实想让这事发生。＂
＂Dave，这不奇怪！这个主意太棒了！这个活动你想多久搞一次？你会负责筹备‘边午餐边学习’这个系列活动，对吧？你会把大家召集起来，并且帮他们拟定讨论主题？你想让我为午餐买单吗，还是大家各自带饭？＂Susan提了很多问题。
Dave咧着嘴笑了笑，说：＂我想每两周举办一次。你提供饮料，如何？或许还可以来点三明治。如果我每两周吃一次比萨，我会变胖的，然后我老婆就会不开心。她不开心的时候，就没人有好日子过了。＂他停下来想了一想，继续道，＂第一次活动的时候我当主讲，这样大家就能明白这活动该怎么搞。随后我会让大家知道，我需要更多的演讲主题，需要安排更多的主讲人。你想去当一回讲师吗？＂
＂当然可以，不过，你想让我讲什么呢？＂
Dave变得严肃起来。＂敏捷方法是怎么让我们对客户兑现承诺的，而用其他方法却不行。产品路线图和Backlog（积压待办的事务）是怎么让我们看到商业价值的，并且让我们不再做无意义的工作。有一些年轻人不了解我们曾经不同寻常的工作，才换来了如今我们在业务上取得的长足优势，这方面你也可以介绍一下。＂
Susan同意了。Dave离开了她的房间。
几分钟以后，Brian来了。Brian是一位测试人员，20出头。他是新加入公司的，还从来没有哪位管理者让他定义过职业发展计划呢。他扑通一声坐上Susan房间的接待椅。然后，他的右腿开始上下抖动，每分钟抖100次。
＂Susan，你好！我觉得我是按照你的意思做的。我有点搞不懂了！＂
＂好吧，我们就来谈一谈这个问题。你想要学点什么？＂
＂嗯，我想更多地了解我们的系统。这是肯定的。我觉得自己知之甚少。我已经跟Dale和Liza合作测试过了。我想进一步了解数据库，因此我想跟我们的DBA（数据库管理员）Michelle配对测试，或者请她培训我数据库管理相关的东西。＂
＂你问过她吗？＂
＂我可以那么做吗？＂Brian看起来很吃惊。
＂你不必经过我的同意，＂Susan说，＂你和她在同一个团队。如果她挑选了一个任务，你可以这么说，‘我想和你一起做那个任务。’如果她拒绝了，并且团队里也没人帮助你，你那时可以来找我，我会帮你去说服她。但她很可能一开始就会答应你。＂
＂啊，我真没有想到可以这样。好，我吃午饭的时候会找Michelle交流，告诉她我想跟她一起工作。＂
Brian的腿还在抖（一分钟可以走出一英里开外）。Susan等了几秒钟，问道：＂Brian，你还有什么其他事要问我吗？＂
＂嗯，是的。其实跟职业发展无关，但我不知道该在什么时候问。＂
＂好吧，你问吧！＂
＂我想在今年夏天骑着自行车出去旅行，历时4周。这不是职业发展，算是个人发展吧。我不介意休假两周不拿薪水，或者某种类似的处理方式。但我不知道该在什么时候请假。我可以这么做吗？＂Brian的腿抖得快要离地而起，那腿似乎已经不是他的了。
＂当然可以。我很高兴你现在就告诉了我，然后我们可以为你的长假提前做好准备。＂Susan微笑着说。Brian的腿也不再抖了。
Susan与她的每一位下属员工都进行了类似的谈话，问的问题也差不多，因为她对人很公平（fairly），而不是简单的同等对待（equally）。那是因为每个人都是独特的。但从某种意义上讲，她确实以完全一样的方式对待每一个人——重点是，她满怀尊重。
同样一件事，可能让一个人高兴，也可能让另一个人痛苦。大部分人想要一份具有挑战性的工作，一份能让他们自己做决定的工作。在每个人的职业发展方面，Susan的团队成员各自做自己的决定。
Susan促进了他们做决定的过程，并且帮他们获得资金支持——她并没有代替谁做决定。她能帮他们做决定吗？她不知道每个人想要什么或需要什么。Susan又不会读心术啊！
人们想要一个公平的工作环境。他们想要定期地得到工作方面的反馈，不管他们表现得好或者不怎么好。他们不想一年只得到一次反馈——那太晚了！当人们准备好承担更多的职责时，他们期望能够不再做那些没有挑战的任务，而去做一些有挑战性的事情，不管挑战是在哪方面。有时候，挑战在于理解需求的验收标准。有时候，挑战在于组织协调。有时候，挑战在于与DBA配对工作。
人们想要得到公平的报酬。作为回报，他们会以一种可持续的节奏工作，为组织的成功做出他们最大的努力。
那就是人们对工作的期望。
你不能假设你只需做到同等对待所有人。因为人与人是不一样的。我们都是独特的个体。如果我们同等地对待每一个人，我们最终会落入一个不平等的处境。但如果我们公平地对待每一个人，我们将营造一个公平的工作环境。那样的工作环境非常美妙！
因此，忘掉＂以完全一样的方式对待每一个人＂这个神话吧！做事要公开透明，并且告诉大家：你会公平地对待每一个人。
管理神话之八：我还能做大量的技术工作
＂你要知道，如果你想做好一件事，你就必须自己动手。＂Clive一边咕哝着，一边走回自己的房间。
Susan原本在埋头工作。她抬起头来，叹了口气。然后起身，跟着Clive穿过走廊，来到他的房间门口。她敲了敲门。
＂什么事？我现在有点忙！＂Clive一边应着，一边坐回他的电脑边上，然后对着Susan说，＂给我解释一下框架的这个部分。＂
＂不行。＂
他望着她，抬了抬眉毛，说：＂不行？我可是你的老板。＂
＂没错！你是经理，但你在质问我的时候不像个经理。你像是闯进来捣乱的，而不是来帮忙的。我是技术主管。如果你对当前的状况有技术方面的问题，你应该跟我说。你应该跟团队说。你为什么不跟我说呢？你为什么不跟团队说呢？你为什么要乱动代码？＂
＂你看到Todd做的好事了吗？＂
＂看到了。＂
＂那你还能像没事一样站在那里？你没觉得不安吗？＂
＂我没觉得不安，因为我和团队今天早上已经把问题解决了。我们比你做得更多。这是谁的问题呢？＂
＂嗯，你和团队的问题。＂
＂谢谢！我们是怎么解决那个问题的呢？你问过我或团队了吗？＂
＂呃，没问。＂
＂好吧，其实你不知道，Todd和Ciddy正在一起解决这个问题。我们已经为线上的服务器打了一个补丁。Dick正与Samara合作开发性能测试，以期将来能避免发生同样的问题。所有这些你都不知道，是吧？噢，对了，我们还会复查代码和测试用例。你不知道吧？＂
＂呃，是的。＂
＂你想穿上超人的披肩，然后亲自去解决吗？＂
＂呃，是的。＂
＂嘿，Clive，你以前是程序员中的佼佼者，但那已经是5年前的事了。即使一年前你还是超人，到现在你也已经不知道我们把代码改成啥样了。你不可能跟上我们的开发节奏。因为我们有30个人一起写代码哪，他们在持续更新着框架，不断编写着自动化测试。你对我们的现状已经不再了解。你不再掌握第一手资料。你不再能从事重要的技术工作了，除非你真的想搞破坏。别高估自己了！＂
＂但是，当我看到问题的时候，我能帮忙做些什么呢？＂
＂来问我需要什么支持。来问团队。确保我们有充足的食物和水作为补给，＂Susan笑开了，继续说，＂基本上，你只需问就行了。我们会告诉你的。你给我们提供精神上的支持，但别去乱改代码！＂
Susan站起身想要离开，最后说道，＂噢，我已经撤销了你提交代码的权限。你只能看，不能改。我还修改了管理员密码。对于技术上的事，你不能再插手了。你是经理。当好你的经理吧！＂
做好授权，别扎进问题里
作为管理者，当我们看到技术问题时，我们会经受想要介入帮忙的诱惑——要么直接出手解决问题，要么告诉别人怎么去解决。但是，那样做会破坏我们与团队建立起来的信任。一旦我们授权团队去解决问题，我们必须把问题留给他们。
如果你尽力把技术问题收回来，你其实并没有帮到团队。他们心想着你不会授权，最终不再去尝试解决问题了。反正你会在情况变糟的时候把问题揽回去，他们为什么还要去解决呢？
你还理解细节吗？
现在，扪心自问一下：你还理解团队所做的技术工作的所有细节吗？
我们一旦变成管理者，我们的技术问题解决能力就开始退化。最起码，如果我们在力争成为卓越的管理者，这些能力应该退化。为什么呢？因为我们花了更多的时间去与团队成员和其他管理者相处，而花在代码、测试、需求（或者以前伴随你成长的任何其他东西）上的时间越来越少了。
那并不意味着我们不要知道碰到问题要问谁，但我们不必知道所有那些技术细节。
我曾经做过开发总监。有一次，一位技术人员冲进我的办公室，抛给我一个非常技术性的问题，他以为我能解决。我听着听着，明白了问题之所在，也意识到谁能帮他。我不能直接到代码里去指出问题，但我知道问题藏在执行区域的某个地方——我们上周刚在那里改了点东西。我可以引导他去找合适的人，但我本人不能解决那个问题。
如果你不再理解细节，你还有职责要转进那些细节吗？不，那不是你该干的事！你可以推进问题的解决，但你本人不能解决问题。
知道你能做什么
作为管理者，我们最好去创造一个能让人们在其中施展才能、做好工作的环境。有时候，那意味着主持一次解决问题的会议。有时候，意味着确保他们有足够的服务器、调试器或白板。有时候，意味着排除外人（比如你的上司）的干扰。
那甚至可能意味着你要帮着读一读代码，或者，也许在一种极端的情况下，你需要编写或者测试一些代码。但是，一旦你成为管理者，提供技术层面的协助未必会起到帮助作用。
为什么呢？让我们来看一看管理者的职责吧。管理者之所以存在，就是要有目的地组织。他们把人员组织成项目团队，或者帮助他们自我组织。他们组织旨在解决问题或做好项目的团队。他们组织大家的想法。有时候，他们组织提供咖啡、百吉饼或甜甜圈。但是，一旦你成为管理者，并且过了几个星期之后，如果你还在组织代码或者测试，那么你管理和技术工作两样都做不好。你没有把你以前的工作授权出去，然后明白地告诉团队或者做出暗示，＂我相信你们能够做好技术工作。＂
但是，我的上司希望我两者兼顾
好吧，实实在在的问题来了。有一些二线经理认为，让一线经理管1～2个人的同时全身心投入技术工作是合理的。那些二线经理可能是对的，但那种一线经理也算不上是管理者。
存在那么一个转折点。一旦那位一线经理管理起第三个人，管理者的平衡必须从技术工作摆向管理。如果管理者不做那样的改变也一切正常，那么那位一线经理将经历一场危机之后才会认识到，他的管理职责必须优先履行。
向你的上司解释：你身上还肩负着管理职责，那要比技术工作更重要。你对你的团队有信心。你可以推动他们解决问题。你甚至可能在他们解决问题的过程中做出贡献。但是，你去动他们的代码、测试、需求或者干涉项目管理只会伤害团队。
你可能不适合做管理
如果你不能脱离技术工作，你可能意识到：管理不是你想要的。在那种情况下，与你的上司聊一聊吧，让他知道你想要什么。你有权做出改变！
但是，只要你还做着管理，那就抛开技术工作吧。你不再是技术团队的一分子。不要有那样的错觉，也不要再继续以往的行为方式。
译者注：Watts Humphrey（1927—2010）在软件工程领域享有盛誉，被美国国防软件工程杂志《CrossTalk》评为影响软件发展的十位大师之一。他在IBM工作了27年，负责管理IBM全球产品研发。离任后，受美国国防部委托，加入卡内基•梅隆大学软件工程研究所（SEI），领导SEI过程研究计划，并提出了能力成熟模型（CMM）思想。在CMM浪潮席卷软件工业界之时，他又力推个人软件过程（Personal Software Process，PSP）和团队软件过程（Team Software Process，TSP），成为软件开发人员和开发团队的自修宝典。他的著作颇丰，《软件工程规范》、《个体软件过程》、《软件制胜之道》等都已成为经典。
译者介绍：陆其明，北京爱奇艺科技有限公司PPS上海公司研发总监。已经出版的著作有《DirectShow开发指南》、《DirectShow实务精选》、《Windows Media编程导向》、《脚本驱动的应用软件开发方法与实践》，译作有《代码之道》、《高效能程序员的修炼》、《程序员的修炼——从优秀到卓越》。