管理的误区(1):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%利用”的概念在当时被提出了没多久,并且很受重视!

译者注:Watts Humphrey1927—2010)在软件工程领域享有盛誉,被美国国防软件工程杂志《CrossTalk》评为影响软件发展的十位大师之一。他在IBM工作了27年,负责管理IBM全球产品研发。离任后,受美国国防部委托,加入卡内基·梅隆大学软件工程研究所(SEI),领导SEI过程研究计划,并提出了能力成熟模型(CMM)思想。在CMM浪潮席卷软件工业界之时,他又力推个人软件过程(PersonalSoftware ProcessPSP)和团队软件过程(TeamSoftware ProcessTSP),成为软件开发人员和开发团队的自修宝典。他的著作颇丰,《软件工程规范》、《个体软件过程》、《软件制胜之道》等都已成为经典。

当一台单进程的电脑被完全利用的时候,请记住这意味着:它一次只能做一件事;它不能服务于任何中断;它不能响应任何键盘输入;它不能更新状态;它只能一直处理下去,直到完成。

如果程序表现良好,并且不受限于I/O、内存或CPU,运行在一台单用户、单进程的机器上,比如只有加减乘除功能的个人计算器,那也许还没事。但只要你加入另外一个用户或者另一个进程,你就麻烦了。(或者,如果程序表现不正常、没能很好地完成,你也会陷入麻烦之中。)

现代的电脑就是那样。现代电脑都是多进程的机器。

对于多进程的机器,如果一台电脑被完全利用,你会看到系统抖动,可能还会僵死。想一想高峰时期的公路,没有一辆车动得了;这时候,公路是被100%利用了啊。但是,我们不想公路被100%利用。我们也不想让眼前的电脑满负荷运行。如果你的电脑被用到了50%~75%,你会感觉它变慢了。而高于85%时,电脑会有难以预期的表现。它们的生产力是不可预期的,你无法判断会发生什么状况。

遗憾的是,人类也面临同样的问题。

为什么100%利用不适用于人

现在,想一想我们自己。当我们在100%利用的状态中时,我们根本没有闲暇时间。我们在各种任务或干扰之间疲于奔命,没时间思考。这时候,至少有两方面的问题:难以避免的多任务,以及没有思考。

实际上,我们根本不是多任务并行——只不过是快速切换而已。我们不像电脑;电脑在切换时,它们把内存里的东西完美地拷贝到磁盘上,当需要换入的时候,能够再次把数据读进来。因为我们是人,我们不能完美地把我们脑子里的东西备份出来,后续也无法再完美地恢复。因此,切换是有成本的,因为我们在处理其他事的时候必须记住之前脑子里在想的东西。那也需要占用时间。

因此,这里有一个情境切换的问题,我们需要花费时间把脑子里的东西换出去、换回来。所有这些时间和不完美会累加起来。因为我们是人,我们不能为各个任务完美地分配自己的时间。假设我们手上有3个任务,我们不能做到在每个任务上花费33%的时间——只要我们乐意,我们想在一个任务上花多少时间就花多少时间,平均33%只是一个假设罢了。

接着,让我来解决100%利用中没有思考的问题。如果你想让大家考虑换一种新的工作方式,怎么办?如果你令他们满负荷地工作,他们会尝试吗?没机会!他们不会考虑,因为他们没有时间。

因此,你让大家机械地工作:用他们了解的最佳方式去服务于各种中断、做尽量小块的工作、做到足够多就算通过。他们不会想办法去提高。他们不会想办法去帮助别人。他们不会尝试创新。他们只是在想,“我怎样才能从这堆积如山的工作中解脱出来?”这对他们来说是很恐怖的,对产品也不好,对与他们打交道的任何人都不好。

当你让人们工作在100%利用的状态,与你计划让他们每天大概只干6小时的技术活比起来,你从他们那里得到的工作成效会小得多。人们需要时间去阅读邮件,去参加临时的会议,休息一下,进行一些架构方面的讨论,喝杯咖啡,或者做点别的什么事。如果你为上午计划一大块的工作,为下午再安排几个大块的工作,并把会议的数量降到最低,技术人员会很好地完成分配给他们的工作。

如果你在一个喜欢开会的组织里工作,你甚至不能计划每天6小时的技术活——你必须计划得更少一点。会议在浪费人们的时间。

但不管怎么样,如果你按照100%利用来计划,在整个组织范围内完成的工作会少得多。你营造了一个可怕的工作环境,这还是一个没有创新的环境。那不像是一条成功之道,是吧?

敏捷和精益让神话破灭

敏捷和精益不会使“100%利用”烟消云散,但它们让神话破灭了。通过把所有的工作装进Backlog(一个管理积压工作的仓库),这有助于管理层和研发团队看清楚每个人应该做的事情,以及大家面临着多大的挑战。这很不错!

一旦每个人可以把工作可视化,你就能围绕它开展工作了。也许某些工作确实与产品路线图相关,但不必在这个迭代里完成。也许有些工作是为另外一个项目做的,应该被推迟到下一个迭代周期。这很好——这就是项目组合管理。也许有些工作应该由某人来做,而不是这个团队来做。这很好——相关管理者需要出面协调。

不管你做什么,只有你看到了工作,你才能有所作为。只要你完全地把工作可视化,你就能管理。

记住,如果你被100%利用,那就没人能做事了。如果你想为你的组织贡献实足的价值,你需要让自己被“利用”到50%~60%。因为浪费思想(不管什么思想)是件可怕的事。

1 收藏 评论

关于作者:豆巴陆其明

《DirectShow开发指南》之作者;《代码之道》《高效能程序员的修炼》《程序员的修炼:从优秀到卓越》之译者。 个人主页 · 我的文章 · 8 ·  

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部