艾伟也谈项目管理,多任务让你走得更慢

  现代商务依靠多任务来完成工作。评价员工也基于的他们多任务能力。IT业人员会被例行指派到多个项目中去。我们是经常在这样做吗?多任务起作用吗?多任务的真正影响是什么?有别的选择吗?

  这里老词重提一下“单任务”,它代表了我们在多任务之前所习惯的软件工作方式。在这里的“多任务”,指的是“工作在很多项目上”。现代商务把它称作“多任务”,认为它是一种更有效提高工作输出的策略。其实,不止工作,我们在日常生活中也会小规模地多任务。这两者在做法和后果上都有相似性。

  一个不同的角度

  当我们向新人介绍敏捷(或Scrum)时,最大的绊脚石是让他们理解团队成员在全职专注于团队工作时,工作效率要高得多得多。这并不是新闻。多年来,我们通常召集“飞虎队”和“特警队”,在危机的时候解决特殊问题。然而,我们的组织更喜欢把“技能筒仓”中的人同时指派到多个项目中去。现在,这是同时处理大量事情的真实解决方法。人们认为这是最有效的“稀缺资源”使用方式。也就是人数不够,但都有专长。

  敏捷模式与之完全不同。我们组建团队,在同一时间专注在一小组事情上。我们并不是先创建工作然后转移人手到不同的工作中,而是先创建团队然后转移工作到不同的团队中。我们是拉动而不是推动。

  改变是困难的。用另一种不同的方式做事需要一个清晰的目的、对获益的远见以及勇气。所以抵抗是自然的,人们在周围事物开始改变时感到不安全。如果我们可以转换到精益思想,就可以借用“尊重他人”和“持续改善系统”来定义目的,期待收益,并走出改进的第一步。很多人听说过“精益”,也想过如何改进我们正在做的事情。其实,精益也告诉我们,如果停止做一些低价值的事情,可以消除更多浪费。

  多任务的成本

  工作在多个项目的人,在每次切换任务时都需要额外成本。主要的成本是切换上下文所需要的时间。我们知道像接电话这样的小中断也需要15分钟的时间来恢复。任务越复杂,切换所需要的时间越多。

  如果你工作在超过两个项目上时,成本会更高。可能你上次工作在某个项目已经是很久以前的事了,那就需要费更大的劲来回忆起离开的那一点。而如果你频繁切换,那转换环境的时间就会占掉你大部分的工作时间。

有研究显示人们对切换小任务很在行。在短时间范围内的切换,似乎和我们的两个大脑半球有关。在一定程度上,我们可以并行处理两个独立任务。对大的切换,我们应该考虑切换成本。Jerry Weinberg展示了逐步上升的上下文切换成本。这个模型假设每次切换会有10%的损失,事实上成本常常比这个更高。

图 1

  当一个人属于一个团队时,无论是松散连接的传统项目团队,或者是有重点的敏捷团队,都会有复杂的切换成本。当一个团队成员离开去做和团队工作无关的工作时,团队都会遭受那名成员缺席的困扰。当那名成员回归时,团队需要花时间来帮助他赶上他缺席时的开发任务。

  敏捷也多任务?

  你可能会说:“但是……等一等……”敏捷团队是跨职能的,团队成员每天都忙于各种活动中。这包括详细描述需求、分析、设计、测试、编码。那不是多任务吗?要回答这个问题,必须考虑上下文的范围。在问题和技术间的大范围跳跃需要更多的切换时间。大脑在一点一点切换活动时不会有问题。作为一个有聚焦重点的团队,所有的每日活动都以一小部分功能和技术为目标,在一个时间只工作在少数的故事上。即使活动的范围多样,上下文的变化也是有限的。另外,敏捷有一些实践来保持聚焦:协作、任务板、自动化测试、回顾。上下文的大跳步才会产生问题:比如转至其他项目、其他合作人、其他干系人。

  多任务神经学

  人类大脑对内部多任务很在行。其实它每天都在这样做。甚至晚上也一样。很多大脑部件一直在交互或单独工作。不然,我们就不能应对复杂的环境。大部分多任务是下意识的:过滤掉感觉输入、综合相关信息、把短期数据转化为长期记忆、保持心肺运转等等。

  而且我们也在对外多任务:开车时听着交通报告想着行车路线,做晚饭时讲电话,为花园除草时计划假期。 一些类似叠衣服、走路等任务是机械性的,不需要切换成本。其他任务像敲击键盘浏览文档、重命名一个方法,经过一段时间也会变成机械性的。但是软件开发工作不是那么简单的。虽然很多自动性多任务运作良好,它也会有限制。[5]

  现代的多项目任务分配造成的上下文切换,产生了潜在的重复精神劳动。人脑有两种记忆:短期(工作记忆)和长期。虽然,有机制使信息在两者之中转换,但是不能保证所有东西都被转移了,也不能保证进去的信息和以后出来的信息是一样的。我们每次重播记忆的时候,都在不断编辑它们。而新信息必须在短期记忆中存储一段时间才能被转移到长期记忆。比如说,考试前的填鸭式复习可能会给你更好的成绩,但是两周以后你几乎不会记得那些材料。于此相似,你可能不会记得上下文切换前你做的最后一件事情。而这应该会是你回到项目后最想要知道的。

  研究显示很多多任务的方式是低效的,甚至有害的。考虑以下信息:

  有证据显示多任务事实上会使短期记忆退化。这不只是因为多任务的主题,而可能是大脑区域受到影响。多任务会造成压力,压力会调用大脑中关于个人安全的原始区域,进而从高级思维区域中获取能量[6]。压力也会损坏新记忆所需要的细胞[7]。
  我们多任务的时候更倾向于犯错,所以我们的工作质量会下降[8]。这当然会增加项目的成本,因为这些错误需要被纠正。大脑的一些部件是顺序处理器,每次只能接受一个输入[9]。前额叶皮层是大脑进行复杂认知和做决定时使用最频繁的部分,也是大脑中最消耗能量的部分[10]。多任务产生的附加压力会导致认知能力的快速损耗和更频繁的修复需求。

  敏捷团队的单任务

  在敏捷环境下,如何减少个人的多任务量呢?我们之前提到了一些方法。更多肢体运动的环境可以使大脑中更多的部分参与其中,致使更快速更完整的信息综合。更专注的工作使上下文范围狭窄。人际交互,以及ScrumMaster推动的一些交互可以帮助保持这种专注。

  一些现代的技术实践能帮助增强专注力:

  测试驱动开发帮助短时内专注在小范围的技术工作中

  持续集成在构建和测试失败后立即给予关注,以此来增加专注力

  结对编程帮助两个人专注在一小部分的代码上

  组织中的单任务

  反对多任务的意见已经存在很久了,然而现代企业文化已经习惯于这种形式的“负载平衡”,以获得对人力“资源”的最有效使用。我们从一些松散的技能团体中召集一个团队,每个人在一个时间在几件事情上兼职。你能构建一个高效的兼职人员团队吗?或者,是不是我们已经认为让每个人都很忙才是更重要的?

  学习中最难的部分之一是忘却当前的行为。这一点对组织和个人都成立。跳出我们现在所做的行为,思考哪些行为可以让我们工作得更好,这一步精神飞跃,是很难做出的。这里有一个简单的论点也许可以帮助引导改变,不止使人的改变更容易,而且也有重要的经济意义。

  图2中显示了4个人工作在3个短期项目中的简单场景。更多的人或者更大的项目,也是同样的动态。在第一个场景中,人们在4个项目上多任务。

图 2: 多任务的个人

  图3中显示了第二个场景,一个团队中同样的人顺序完成所有的项目。这个场景保守地假设了成立团队没有生产率的提高,减少上下文切换的数量也没有生产率的提高。注意到所有3个项目都在同一时间完成,但是这个场景中2个项目更早地完成。想象一下由此产生的经济利益。

图 3: 成立一个团队顺序做项目

  考虑上下文切换的减少,以及由于团队协作而获得10%的生产率提高,我们可以期待所有3个项目都能提前完成,如图4所示。

图 4: 由于单任务和团队协作而缩短的时间表

  Johanna Rothman在“管理你的项目组成”中具体介绍了这个话题。

  多样性是生活的调味品

  所以,很清楚,多任务是有害的,我们永远不应该这样做,是吗?那我们如何调和“多样性是生活的调味品”这一思想?脑部研究显示,新奇性是有吸引力的。它会产生多巴胺,这是一种神经传递素,会使我们想要更多[11]。对此的解答与专注力和范围有关。如果上下文的切换很大,多任务会对个人和他们的合作者造成代价。如果切换比较小,可以顺应思路,那就会工作得比较好。在敏捷团队中,我们可以通过彼此学习来得到足够的新奇性,也会从完成项目和成功中得到其他好感觉的神经传递素。

  总结

  项目间的上下文切换需要时间,这对组织来说是成本。涉及项目越多,或者项目越复杂,那成本也会越高。如果在一个时刻专注在一件事,坚持一段时间,工作效率就会提高。通过组建团队来顺序处理项目,我们可以减少上下文切换成本,也可以从团队协作中获得更多收益。

[1] Slow Down, Brave Multitasker, and Don’t Read This in Traffic

[2] Multitasking Can Make You Lose ... Um ... Focus

[3] Motivated Multitasking: How the Brain Keeps Tabs on Two Tasks at Once (Scientific American).

[4] Weinberg, G.M. Quality Software Management: Vol. 1 System Thinking. New York. Dorset House, 1992.

[5] 查看 “Hang up and Drive”(《Brain Rules》一书中的一段视频),视频中简单描述了当你同时开车和讲电话时发生了什么

[6] The Neuroscience of Leadership

[7] Studies show multitasking makes you stupid

[8] The Madness of Multitasking (Psychology Today)

[9] Slow Down, Brave Multitasker, and Don’t Read This in Traffic

[10] "Your Brain At Work", David Rock

[11] Multitasking: The Brain Seeks Novelty

时间: 2024-09-20 15:30:04

艾伟也谈项目管理,多任务让你走得更慢的相关文章

艾伟也谈项目管理,项目的故事

这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单: 一个应用程序与数据库以及其它两个系统通信.这在技术和架构角度都是主流,而在管理角度则是标准情况: 所有工作都应该在昨天完成,但还有很多没有完成的.简而言之,"这很难!" (这是开发者经常表达的一种情绪,但是谁都不会太大声地把它喊出来.) 为此我们创建了团队.雇佣了四十位员工并指定了他们的角色.我们把团队分为小组,并在不同的小组之间设置了一种契约.每个小组负责应对特定类型的要求.这样就形成了要求的流程.指定的小组会承受

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权.下面就提出一些建议,供大家讨论.希望对大家有用. 一.要考虑每一个项目阶段普遍存在的问题 ERP项目可以根据项目进度,分为项目立项.需求调研.业务流程重组.模拟运行.并向运行.正式上线等几个阶段.其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题.有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解.此时他们就可以预先采

艾伟也谈项目管理,我也发软件开发团队的思考(侧重点是人员)

//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意.更重要的是市场的开拓因为这些项目拖住了后退而无所作为. 我们现有的情况是:项目期限和最开始的保守估计都相去甚远,最后提交给客户的产品60%都是最后一个多月开发出来的,还有20%左右是以前就固有的固定模块.这几个项目我参与了编码,我对整个系统

艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷

要成为一个好的项目经理需要学会逆水行舟.虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方. "虽然很有道理,但我认为现实不允许,很多项目都有规定的期限.中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的." "写得不错,但是有些建议过于理想化了.毕竟说得很有道理,但实际中具体做起来又不是那么一回事了." 这是两位网友对<软件项目经理新手上路>的评论.这话很有道理,也是在现实生活中碰钉子碰出来的.在项目中确实存在

艾伟也谈项目管理,代码背后的点滴

有段时间没有更新技术blog了,现在有空每天都写写围脖,记录生活和工作的点滴,但是有时候发现有些技术的想法和工作总结没有像过去那么完整的写很大一篇,但是也有零零散散的不少点滴,因此想着随意的写这么一个连续的片段分享. 为什么叫做代码背后的点滴呢,其实在现在互联网应用来说,其实用什么语言,用什么平台有些场景有影响,但已经不是绝对重要的因素的,其实代码被后的设计思想才是最重要的.而用最熟悉的方式去表现最自然的想法,那才能做到游刃有余,就好比我向华黎同学申请这次内部奖励的奖品希望是手写笔,因为不论什么

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目.中国有句古话叫"旁观者清",同一个问题站的角度不同,可能会形成不同的结论.下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正. 1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力.编码可读性.能力和项目的匹配度等因素. 2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即