项目百态:软件项目管理面面观(修订版)(txt+pdf+epub+mobi电子书下载)


发布时间:2020-05-15 11:07:55

点击下载

作者:(美)德马科(Tom DeMarco)等

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

项目百态:软件项目管理面面观(修订版)

项目百态:软件项目管理面面观(修订版)试读:

本书赞誉

“非凡的洞察力。合上这本书,你会陷入沉思:‘该死,我就是那么做的……我们该有麻烦了!’随即是自我安慰:‘不只是我一个人做了。还有希望!’”——皮克斯动画工作室软件部副部长Howard Look“除了这些作者,还有谁能挖掘150年的软件团队经验,给这些时常遇见的场景安上过目难忘的名字?我猜你会开始在自己的工作中使用这些说法——我已经在用了。”——《敏捷软件开发》作者Alistair Cockburn“对于任何一位曾经在组织里面从事过项目工作的人来说,86个项目模式熟悉得令人心惊。幸运的是,其中有一些模式是良性的,应该给予鼓励。不幸的是,剩下的绝大多数模式不仅仅令人心灰意冷,而且它们对生产率、质量和项目团队士气的破坏程度令人瞠目结舌。”——《死亡之旅》作者Ed Yourdon“作者具有高度的幽默感和深刻的洞察力。本书清楚地讲述了项目因何而失败,有何补救措施,并且以非常友善和易于接受的方式提出了切实可行的建议。”——哈佛商学院教授Warren McFarland“对于每一位经营IT组织的人来说,这绝对是一本必读之书。实际上,对于开展各类项目的组织,这本了不起的书里面的教训对其经营者都是适用的。书中的隐喻十分风趣,是那种有点儿笑中含泪、‘你都遇见过’的风趣。你在各处都能遇到这些常见症状。携以一定的勇气,手头常常翻阅本书,你定能创造出一个健康的项目环境,使人们在其中能够茁壮成长,同时交付完全符合期望的产品。”——DTE能源高级副总裁和CIO Lynne Ellyn“人们总是试图去理解自己和其他人。我们的生存依赖于这些理解,生存的质量——从勉为糊口的生计到极为心满意足的生活——也同样依赖于这些理解。人们的个人行为、人际行为及其处在制度坐标下的行为,构成了独一无二的态度和行为框架。针对这些复杂因素的动态变化的思考,铸就了洞察力和影响力。试图理解这些因素的三次尝试跃入了我的脑海。中国人有《易经》,建筑师们有《模式语言》,心理医生有自己的《人类精神失常诊断和统计手册》。本书巧妙地融合了以上三者(在相当程度上吸取了最后一项)的特色,从组织的角度,将人类创建和遵循的模式——与它们的危害和优势——在它们所存在的项目里面关联起来。敏锐、风趣并且一针见血,所有人都应该阅读它。”——The Cluetrain Manifesto作者之一Christopher Locke

中文版推荐序:实话的力量

我对我的客户、一支百人团队的领导说:“你们并不是没有优先级。你们的优先级策略是最后来的事情优先。”

他苦笑不语。因为他知道,这就等于在说,他手下的百十来号人基本是在做布朗运动;更因为他知道,这是实话。只是他自己不能说,他的手下人也不能说。

事情经常是这样:尽管所有人都知道,但谁也不会把它说出口,因为说那样的话是政治不正确的。比如说吧,也许你早就知道你手上那个项目注定是条死鱼,但你敢说出口吗?更多时候,你会让自己变得乐观──乐观程度与最后期限的紧迫程度成正比,直到时间夺走你所有的手牌。

另一些时候,你知道自己碰巧做对了某些事,你不愿意新来的经理改变它:取消每周四晚上的三国杀,把团队从大会议室里搬回格子间以便“释放资源”,把几个模块外包到一千公里外的另一个城市。可你没办法说服领导。“你有度量证据吗?”当然,你没有,而削减成本总是政治正确的。

情况不会自己变好的,如果人们连真实情况都不敢说出来的话。

幸运的是,像Tom DeMarco这样名声和年纪(这很重要)都足够大的人可以不在乎政治正确性──换句话说,他们可以说实话。这本《项目百态》就是他们关于项目管理的实话集。

在这本实话集里,作者们挑选了86个项目管理中常见的模式,从“肾上腺素成瘾”直到“模板僵尸”──从英文书名不难看出,这无非是“从A到Z”的又一个变体。这些模式,诚如一位评论者所说,有良性的,更多的不仅恶性,而且丑陋可笑。读这样一本书,你会笑,更多的时候你会摇头苦笑,甚至如芒在背。“我的团队没有肾上腺素成瘾吗?”很多读者将很难面对这个问题。

那就对了。

我要感谢我的同事金明向我推荐这本书:几位作者帮我们消解了政治正确性的风险,我们就可以放心地说出实话,然后努力进步。下次当同样的模式出现时,我就可以大声地说:“这就是《项目百态》中的××模式。”或者当我再次面对前面提到的那位客户时,我可以把书递给他,对他说:“也许你该看看××模式。”

也许你也应该看看。熊节Thought Works中国公司首席咨询师《重构》译者

引言

抽象为人类独有。我们现在每天、每个清醒的时刻都会进行抽象,但曾经却并非如此。在史前时代的某个时刻,抽象可能是这样诞生的:一个早期智人凝视着一样依稀很熟悉的东西,他的脑海中闪过一个想法:“嗨!又是那个东西!”这就是最原始的抽象。从那时起,一切都不同了。人类在地球上不再受自然羁绊。

抽象完全是人类的行为。模式识别则不然,它并不为人类所独有。老鼠很清楚猫儿何时进入梦乡,人们何时不在厨房,面包屑又是何时掉落尚未被清扫。兴许你只是突发奇想,打算离家待一个周末,你家的狗也能提前察觉你的意图。(是不是因为你的手提箱?)而你的邻居浣熊也知道当潮水退去,遗留在海滩上的东西必然比你肥料堆里的东西要美味得多。然而,虽然熟稔于模式识别,老鼠、狗、浣熊却不会观察,联想不到“嗨!又是那个东西”。这其中就需要抽象了。

模式识别和抽象的区别在于它们捕获本质的方式。模式随着时间被吸取和提炼,保留在脑海的深处,很难用语言来表述,多半以直觉的方式传达给你。直觉,比如觉得持球队员选择从左边突进或者发现配偶的怒火即将爆发,都是源自过去识别出的模式。至于这周项目状况的会议上将引发争论的直觉,也不例外。不能明确表述的模式并非毫无价值——毕竟存在即合理,但如果你仔细思考,并且基于其可表述的观察结果来探究,模式的价值会显著增加。

不妨问问自己:过去的一年中,引发争论的会议之间存在哪些共同之处?呃,这些会议大部分都是这样的:老板的老板也参与了会议,而且通常是季度末期的会议。最糟糕的会议则当属——团队在会上汇报了计划的失误。据此,你会建立一个模式:“会上汇报的失误简直会让我的老板发狂,特别是在接近季度末期的会议上面,因为他的老板那时也会出席。”

尽管已识别的信号可以推导出这个观察结果,但是它们仍然隐藏在无意识之中,偶尔才能让你产生直觉。正是在右脑直觉和左脑表述能力交汇的一刹那,你抓住了本质,并且形成了清晰的语言。你可以把它写下来,使用明确的测试校验其正确性,和其他人分享,与一同工作的人合并各自的观察结果。

大部分做项目管理工作的人都非常善于识别模式和培养直觉(“我感觉这个项目会走向灾难”),但却不那么善于把模式抽象成更加有用的表现形式。我们几位作者一起研讨,从加起来长达150年的相关从业经验中吸取出特定的模式,再精确地表述出来——于是有了这本书。

书的编排会影响到内容陈述的顺序,因为书必然是一页接着一页的,但模式本身并不具有天然顺序。我们按照自己的喜好排列这些模式,从第一页到最后一页,都争取给读者带来最愉悦的阅读体验。

无论你是从头读到尾,还是随意翻阅,请始终记住这一点:我们并没有宣称自己观察到的模式具有普适性。显然,它们不可能是万能。别人给出的模式也许适合你的组织,也许不适合。如果适合,我们希望能帮助你将之前的直觉表达出来,让你和你的团队可以表述、验证、提炼。

在本书的创作过程中,我们从建筑大师、哲学家Christopher Alexander和他令人惊叹的《模式语言》那里受益匪浅。在那本影响深远的著作中,Alexander与合著者总结了建筑的几百种模式。它帮助我们更好地理解我们所涉及以及想涉及的部分,它也告诉我们,经过深思熟虑的清晰抽象足以阐明任何事物。模式1玩的就是心跳

组织相信,工作忙乱是生产率高的表现。

电话响了。“我们想这周完成需求的规格说明书。你能过来看看可以做些什么吗?”“规格说明书怎么了?”“我们很急,所以新招了许多人来写规格说明书。我们觉得他们完全不清楚自己在做什么。”“如果由我们来指导他们编写需求,效率不是更高吗?”“但是我们这周就需要规格说明书。”“好吧,我明天过来。”

两个小时之后。“你能过来看看我们的预估结果吗?”“规格说明书怎么办?”“我们没时间了。我们就照现有的需求规格说明书进行。老板要求今天就把预估结果交上去……”

你可能已经发现这一类“心跳游戏”(adrenaline junkie)型组织的特点了:优先级总是变化不休,所有事项都是“昨天”就要,总是没有足够的时间交付项目,每个项目都是加急项目,而且加急项目还在不断出现。每个人都忙得焦头烂额……永远如此。

这些组织里面的人不会思考战略层次的问题,只是按照紧迫程度来完成工作。除非“忙乱指数”非常高,否则该指数通常都会被忽略——尽管重视它很有可能会带来显著的长期优势。人们会一直对其不闻不问,直到它突然(绝对出乎意料地)变得要紧了。“玩的就是心跳”分子相信最好的工作方式不是先规划再行动,而是越快行动越好。

这种文化认为紧迫性越高的项目,收获也越大。如果身处这种文化之中,你很难不受感染:越紧迫越好。因为给项目的时间短得荒谬而通宵加班的程序员被视为英雄(根本不在乎他们交付的程序质量)。每个周末,团队的所有成员都照常上班,以保持他们的工作量:这样做的团队比不这样做的团队更受人赞许。此外,如果你不是一直都过度加班,或者没有发疯一般忙碌,就会被贴上“局外人”的标签,你不是保障组织运转流畅的大忙人之一。非英雄行为是绝对不能接受的。

绝大部分的“心跳游戏”型组织至少存在一个瓶颈,就是那位英雄。他是所有设计的决策者,是全部需求的唯一来源,也可能包办整个架构。他扮演了两个角色:一是让自己表现出常人无法想象的忙;二是引发决策僵局,他的决策一旦公布,就会导致组织的其他部分更加忙乱。

大部分的“心跳游戏”型组织满腔热情地拥抱服务客户的教条:他们混淆了对紧迫事件的响应和值得赞赏的响应。只要客户提出了请求,不管是否能带来收益(甚至不管有没有用),都会立即转化成项目,而且通常截止日期会短得可笑。(更多讨论,请参阅模式38。)这个新项目自然会加重已经在超负荷工作的英雄们的负担,使他们更加手忙脚乱——永不停歇的需求让组织变得异常忙碌。很多这类的组织都(错误地)认为这就是敏捷的全部。“心跳游戏”型的行动是贸然的,而不会经过思考。其结果就是大部分工作都处在不断变化、无法固定的状态,没有什么可以固定下来,也没有什么可以保持较长的时间。这种不固定的状态一直延续:需求规范不固定——没人真正清楚要开发什么;设计和计划也不固定——它们很可能明天就会改变。紧迫性是唯一的标准,没有人尝试按照重要性或者工作价值来给工作排定优先级。

对于“心跳游戏”型组织,特效药是不存在的。他们没救了,除非取消那些令人心跳加速的任务,同时解雇经理,雇用那些明白“组织只有不再忙于处理突发事件才最有效率”的人。但是这样的人事变动根本不可能被采纳,因为高层领导,通常是CEO,希望看到组织长久地保持匆忙的状态,工作匆忙会给人高生产率的幻觉。而且,如果公司的经理们迷信“玩的就是心跳”,项目团队也会效仿。“心跳游戏”型组织并不是总会失败,他们当中有一些在多年里一直保持着匆忙的节奏。但是,它们都不可能构建重大的东西——那需要稳定性和计划。亢奋型行为不可能扩展——由一些相对较少的人在没有方向,也没有战略指导的前提下,只凭借非常、非常忙碌的工作,成果十分有限。

当然了,各种组织内都有紧迫的事情,也需要有一些角色去关心紧迫的任务。但是,不是所有的事情都是紧迫的,也不是所有的角色都要关心紧迫的任务。除非化紧迫性为优先级和约束,否则,这种“心跳游戏”的治愈希望是微乎其微了。模式2快,赶上

项目团队在决定谁在什么时间该做什么事情时,会有明显的紧迫感,并迫不及待地采取所有必要的行动。

想象你是一只停在墙上的苍蝇,此时开发团队正在召开例会。随着会议的进行,你能看到下面的角色分工,听到下面的谈话:我们要解决的问题是什么?解决方案的要点是什么?每项要点由谁负责?首先需要完成的事情有什么?谁来完成它们?在什么时间之内完成?如果我们不清楚某一项个别的任务要花多长时间,谁来定义任务范围,以及何时才能完成?什么时候我们再聚一起,计划接下来的任务?好了,散会。

会议之后,通常在一个小时之内,所有成员会收到一封邮件,上面总结了团队达成的行动计划。事实上,往往在这封总结邮件发出之前,其中一项或多项行动事项就已经完成了。人们在会议结束之后立刻行动。

即使以墙上苍蝇的眼睛也能看出来,这是一支高效的团队。

我们知道,高效的团队在会上就开始处理商定的事项,这一点都不稀奇。接受任务的人通常会认为,相比把任务写下来留到会后再行动,立即动手反而更容易一些——比如“把所有尚未解决的优先级为2的缺陷分派给产品管理工程师进行分类”。如果某个决定必须事先询问会场之外的某人,那么接受任务的人就会给那人发送即时消息,并且把结果汇报给参会人员,避免中断行动计划的制订。

这种“立刻行动”的例子非常特殊,而且应当承认它们是拜技术所赐。但是行动的内在基础来源于团队的文化,而不是所使用的技术。分派缺陷到底是花费10分钟还是90分钟并不是重点,重点是立刻开始。在团队日常“快,赶上”的活动中,你能观察到下面一些特点。

●他们对于时间的紧迫性有着内在的直觉。他们把延迟视为成功的真正风险,而不需要拿截止时间来吓唬。他们竭尽全力,一旦完成,就把产品推向市场(或者把系统做成产品)。他们明白时间就是金钱。

●他们对个人和集体的能力非常有信心。想象赤脚走在一间黑暗且完全陌生的房间里面。当你不确定前面有什么东西,或者不知道下一步会撞上什么东西的时候,你会慢下来。信心不足就像一种摩擦阻力,以行动为导向的团队对自己决定和行动的正确性(或者纠错能力)非常有信心,所以他们可以放心地快速前进。

●他们相信迭代的价值。他们不会特别担心做错了事情——部分是因为他们很自信,但同时也因为他们完全准备好了在工作进行过程中经常评估,不断修正。他们摆脱了“每次决定都必须毫无瑕疵”的包袱,同时坚信大多数决定都是正确的,所以可以很干净利落地决策和行动。

也许值得花点功夫考虑一下这个模式的对立面,“脱口秀”会议——它们有时十分有趣,但却缺乏行动。这种会议有如下几种形式。

●要求完美的信息。有些公司的文化把不犯错误看得比完成任务还重。换句话说,什么也不做都比做错了更安全。这种文化催生了这样一类领导和团队,他们企图搜寻到所有的信息,在第一次就作出绝对正确的决定。通常,团队会议的结果不是决定要做什么,而是决定还需要收集哪些额外的信息以决定做什么。

●对“等一等”的膜拜。弱团队比强团队更倾向于推迟他们的决定和行动事项。“推迟”的理念与强软件团队的行动方针背道而驰。强团队渴望把事情全部做完。如果需要作出决定,或者决定完成一项任务,团队一定会去完成。如果决定确实需要推迟到未来,团队会在开发计划中明确其期限。弱团队则总是会寻找借口,等着晚一会儿再作决定或者采取行动。

●未定事项大捣浆糊。会议组织杂乱,新想法层出不穷,主题不断变化,新问题源源不断,但却没有一个有答案。

●篝火旁的轶闻。一些团队会议毫无组织,纯粹是轶事趣谈,以及追忆组织过去和现在流传的故事。

●条条大路通设计。如果团队由架构师和开发人员主宰,我们有时观察到,无论会议的目标和议程如何,每一次会议最终都将演化成设计讨论会。设计讨论也许很精彩,但如果妨碍了其他更有价值的议题,再精彩也没有用。

●开会安排额外的会议。所有失败的会议最终都走上这一步,概莫能外。模式3死鱼

从开工起,项目就完全不可能完成目标,项目团队中的大多数人都很清楚这一点,却缄口不言。

很多IT项目的目标可以被扼要地概括为:我们要在截止日期之前,完成这一系列功能,达到这种准确度,并且保证足够的健壮性。于是项目团队组建起来,项目目标和约束条件落实为详细的需求和设计,然后发布。

天大的秘密是,项目团队中没有一个人相信项目最终能成功。通常看来,如果其他目标不作修改,期限是不够的。难以思议的是,并没有人指出,失败的阴影正如散发恶臭的大死鱼,把项目变得臭不可闻。

于是希腊式悲剧拉开帷幕,项目进行得步履维艰。毫无意外,在预期交付日期之前的几周,所有的项目成员、项目经理、项目经理的上司以及任何与项目沾点边的人,要么——

1.对于项目没有按照即将到来的发布日期进行,表示震惊、气馁、诧异;

要么——

2.保持低调,除非被点名问到,否则对任何事情都保持沉默。

为什么如此多的组织里面有如此多的人会用除臭剂掩盖实情,而不是直接指出“项目现在的方式不是我们所希望的方式,死鱼就在那儿”呢?

很多组织过于看重成功,所以任何表达疑虑的人都不会因为说真话得到任何奖赏。事实上,如果谁在项目的前期阶段就声称死鱼的存在,管理层的第一反应多半如下。“证明给我们看。给我们证明成功的可能性是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。请用严密的数学证明来告诉我们失败无法避免。”

一旦你提出任何缺乏精确证据的东西,就会被指责为软蛋或者是试图逃避辛苦扎实的工作:“你是软蛋还是懒汉?自己选择吧。但是我们怀疑你还能在这个奋进的组织里面待多久。”

在这样的环境里面,“努力”而无法完成比站出来说目标无法达到更安全。确实,有时我们需要勇于面对挑战,在认输之前真正地拼搏一番。非常正确——但区别是,在有确定截止时间的艰难项目中,没人会捱到最后一刻才声明情况的危急。如果项目是给只有18个月后就要发射的通信卫星开发软件(你知道如果错过了这次发射时间,就只能再等16个月),那么,你们每个人每天都要闻一闻项目有没有出现什么异味。只要闻到一丝腥味,你就应该喊出来,因为你非常清楚,如果遇到“死鱼”项目,不到最后时刻是没人说话的。

非常清楚的是,“死鱼”不仅给组织带来破坏影响,而且挫伤了“死鱼”项目团队成员和经理的士气。无论组织文化如何,没有人会觉得长期呆在发臭的“死鱼”项目里很舒服。严密封锁“死鱼”消息的成本实在太高。

献给“蒙特·派森”迷们:“项目还没死,它正在附住峡湾!”“项目没有死,只是在蜕皮!”“这项目已死。它已经驾鹤西去了。”“现在上场的是完全不同的模式……”模式4欢乐的鼓掌会议

士气是否高昂,也是个人绩效的评价因素。

高昂的士气永远是组织健康运转的一个象征。与之类似,低落的士气说明肯定有什么地方出错了。有一种管理理念就是紧盯这种关系,试图反过来利用它。其逻辑是这样的:把士气鼓舞起来,其他好东西也就跟着来了。

啊哈,那如何鼓舞士气?尤其是如何在不多投入时间、精力、金钱——虽然它们是改善的必要投入——的情况下鼓舞士气?这是个难题,但别以为人们就不会去尝试。于是,才有了这样的谚语:“打气,打到士气提升为止。”

鼓舞士气的常见举措是仪式性的会议。会上老板笑容可掬,面对集合在一起的团队自由发言。“让我听听你们的心里话,”他大度地告诉大家,“说什么都可以,坏的消息和尖锐的问题也可以。”注意这里的腔调和背后传达的信息:没有什么好隐瞒的,我们是一个欢乐的大家庭。(注意了:要欢乐,该死的,要欢乐。)

我知道有一家公司,这样欢乐的鼓掌仪式被称作全员会议。之所以称为全员会议,是因为所有人都获邀参加。可是一旦真有勇敢者举手,向CEO提出尖锐的问题,最后的结果却根本不是他所预想的。CEO应付了几句,就快步走下台去。在当天的晚些时候,这个冒失的提问者就被他的顶头上司叫去训了一顿,点破他的天真:居然真的以为这类尖锐问题会很受欢迎。从此以后,在私底下大家都把这种会议称为“一言堂”,因为再没有人会举手发言了。——TDM

一旦理解到老板并不是在征求你们的意见,而只是想听到赞同的声音时,你就能清楚地知道演的是什么戏了:欢迎参加欢乐的鼓掌会议。模式5保姆

项目经理拥有的技能与传统的英式保姆有很多共同之处。

优秀的项目经理必须对手下员工的能力了如指掌。他分派任务、制定计划,在能用的技术和任务本身的要求之间寻求最佳的平衡点。这是显而易见的。还有一些项目经理更进一步:他们创造的工作环境——不仅是技术性的,而且是社会性的——让人们可以最大限度地发挥自己的能力,并且提高这些能力。这些项目经理确保自己的员工拥有完成任务所必需的工具。这些项目经理也鼓励提问,并且乐意与员工辩论;他们给每位团队成员提出最合适的挑战;他们在需要的时候提出批评;他们建设一个人人乐于工作的场所;他们采取必要的调整以保障各个方面井井有条。简单地说,好的经理培养他们的员工,就像保姆照看孩子一样。

在传统的英式文化中,保姆受雇于某个家庭,负责照看孩子。保姆通常要具有教师、护士和厨师的技能,全面负责孩子的体格、心灵、社交、创造性和智力发展。在每天的日常活动中,保姆要确保孩子远离伤害,保证孩子们得到足够的新鲜空气与锻炼,吃到有营养的食物,加深对世界的理解,掌握更多在世界上生存的技巧。除了照看孩子,保姆还需要促进孩子天赋的发展,并与家长沟通对孩子成长方面的顾虑。保姆要创建出安全的环境,使孩子能适当冒险并从中学到新知。

经理们如果拥有这些与保姆类似的才能,就能通过鼓励和培养员工的天赋,从员工那里获得更多、更好的工作成果。

迄今为止,我为之工作过的最好的经理是Peter Ford。这再明显不过了,比如他让员工在工作时各尽其能。举个例子,我们在一大间开放式设计办公室工作,这不是最好的思考环境,于是他设法为团队弄到一些隔音屏风,并保留了几间“静音室”。所有的这些,还有他为我们做的其他事情,要用到谈判能力和手腕,却不让我们知道。他鼓励我们在系统开发的时候多阅读并讨论新的想法。他为团队买来书籍和杂志,并安排时间让我们聚在一起讨论。当我们觉得不开心或者不舒服的时候,他会注意到这一点,跟我们交谈,帮助我们。他保护我们不受组织其他人和事的干扰,但如果他对我们不满意,他会让我们知道。他办公室的门很少关着。Peter就是我们的保姆。——SQR

你所在的组织或许已经有一些“保姆型”经理,如果你留意,会发现这些现象:不必预约就能见到你的头儿,或者不必在琐碎和令人生厌的管理工作上花费太多时间。周围是开放的氛围,人们畅所欲言,互相学习。这种经理认为培训或进修非常必要,而不是视之为烧钱。他们还会专门安排时间(比如早晨咖啡闲谈或者周五下午阅读探讨),让大家在一起讨论新想法。

只要有人聚在一起,总会有流言蜚语、小道八卦和一些磨洋工的情况。然而,在被经理细心呵护的办公室里面,这类浪费时间的事情极少,因为经理确保团队成员对于实际发生的事情都非常清楚。人们不需要去打听小道消息来了解组织内发生的事情。与之相反,他们觉得自己充分知情和受到信任,把精力都放在本职工作上面。

类似于保姆的经理会把自己看成是工作的催化剂。传统保姆的工作满意度来自于看到孩子能力的发展,“保姆型”经理的工作满意度则来自于看到每个团队成员在个人角色方面得到发展、生产率得到提高,并对自己的工作更加满意。

这个模式的反面是这样的:经理关心的是争权夺利、发号施令、制定流程,逢迎上级;绘制、调整PERT图和甘特图比与团队成员交谈更重要;还有一些经理自己做了太多的实际开发,而没有解决好团队的需求。

你们的组织如何看待经理的角色?他们会因为“催化”了工作受到赞扬吗?你们雇佣的是“保姆”还是“管理者”?模式6治标还是治本

项目治愈了外部的症状,却没有根除内部的病因。“牵涉性疼痛”这个术语通常是指疼痛并不表现在病源位置,而是表现在身体的其他部位。举例来说,脊柱损伤患者并不会觉得脊柱有问题。坐骨神经痛也是如此:病人感觉到腿部疼痛,但是问题却是因为椎间盘脱垂压迫脊椎神经导致。你可以费尽心机治疗病人的腿脚,但那并不能消除疼痛——因为病因在其他的地方。类似地,患有心脏病的病人通常会感觉左臂疼痛,治疗左臂对于挽救病人的生命没有任何帮助。

在项目立项的时候,人们往往会解决表面的问题——最明显的、客户疼痛感最强的问题。但是,如果只盯住牵涉性疼痛,项目交付的产品——一旦交付了——最终就会变成极大的浪费,因为它对于解决真正的需求几乎没有任何的帮助。

看看下面的例子:忘记密码的银行客户向安全部门申请重新设置密码。在确认新密码生效之前,会牵扯到极其复杂、成本昂贵的用户鉴定流程。在一家英国银行,每年重新设定密码的开销都会超过400万英镑。于是,一项旨在构建新的软件以简化密码重置流程、降低密码重置成本的项目开始了。

项目解决了治标的问题,却没有治本(有太多人忘记了自己的密码)。因为密码设置协议无比繁杂,用户根本记不住最终得到的密码,这家银行收到的“我忘记了密码”的请求远远多于其竞争对手。如果银行解决了真正的问题,从成本的角度上看,它就能极大减少请求的数量,现有的密码重置流程也就能非常良好地继续运作。

为何治标而不治本?我们观察到的一个普遍原因是,不愿意去进行调查研究。有时是因为组织的文化,有时是因为项目需要立即开始:“听着,我非常清楚我所要的。所以,给我生成这些报表就够了。立刻!马上!”在很多组织的内部,分析师需要非常有勇气才能提出:“如果拿到这些报告,你会做什么?你真正想做的是什么?”

有时,我们只想在最亮的灯光下找寻。比如说,我们可能倚重自己所具备的技术,以我们最熟知的解决角度来看待问题:问Web服务设计人员如何解决业务问题,通常会得到基于Web服务的解决方案;问数据库设计人员,会得到从数据库出发的解决方案。不消说,二者都会轻易地忽略与自己偏好的解决方案不够契合的方面。此外,我们可能更喜欢解决最吸引人、结果最耀眼的问题。不管最终采用什么方案,工程师都急于针对明显或者明确的问题,给出富于个性的解决方案,但他的技术能力却用错了方向,结果事与愿违。

到底是在治标还是治本,一个很明显的信号是临时补丁:先让错误发生,再去解决。如果要对目前系统作一些修正,这些补丁就会猛然出现。临时补丁只解决了表面的问题,没有去修正内在的逻辑链条。它好像创可贴,很少(甚至从不)能帮助解决问题的根本原因。但是,如果一个补丁看上去有效,就会有更多的补丁跟上来,有时甚至每个补丁上面都是层叠的临时补丁。每次打临时补丁的时候,这种“创可贴”似乎要比外科手术更便宜、更划算。

很多问题的根本原因都是细微的,而且通常与表面的症状一点也不相干。但是,集中精力研究真正的需求,解决真正的问题,总是能事半功倍。模式7明日复明日

每个人都有时间窗,进入任务的时间窗,就要开始行动并持续推进,直至完成。时间窗之外的交付日期不会带来任何紧迫感,也就产生不了行动的动力。

如果美国独立战争前一年,里维尔在午夜纵马驰过马萨诸塞州的村庄和乡镇,大喊:“英国人要来了!英国人要来了!就在明年的某个时刻——我不确定具体何时何地,但是我确定是在明年,英国人就要来了!”会发生什么情况呢?

你能预料到他肯定不会遇到期望的回应,倒很可能会有人愤怒地吼道:“闭嘴,保罗!”甚至偶尔还会有人扔来夜壶。

紧迫感是采取行动的重要催化剂。如果事情不紧迫,它就会从今日待办事项清单里溜出去。其他几天内要完成的任务会显得更紧迫,所以今天应该处理那些事情。

每个人都有时间窗,提醒自己立即行动以完成工作。对于大多数人而言,时间窗的长度是30到90天。我们可以分析现在的处境,预料出未来30到90天的工作进展。我们可以计划这段时间的工作,评估紧迫程度。然后我们立刻着手,紧紧盯住需要完成的事情。

时间窗之外的都是“明天”。“明天”是这样一种状态:意识到自己需要负责完成工作,但却没意识到如果决定要做好,就必须从现在开始动手。

大多数项目的周期都超过人们认知紧迫性的时间窗。如果组织告诉他们在未来30个月之内完成项目有多么重要,大家在内心深处并不能感觉到紧迫。他们听到了这个消息,理解了它的重要性,但在脑中有个声音在告诉他们:“30个月,你能不能活到那时候都是个问题。”

大型项目会让大多数人关注时间窗,避免“明天”的影响。他们把工作落实为90天之内——通常是30天内——能够交付的具体任务。你能听到如下的交付建议。“在接下来的两周里面,我们只考虑证券交易员用户,为他们创建交易界面的原型。”“我们来写点代码,让系统能够接受新的订单,检查订单项是否有库存,然后发送一条处理消息。不用去管订单的修改或者取消,其他什么都别管,只用管新建的订单。我们要能在这个月中旬演示这个功能,怎么样?”

对于项目成员,其好处在于他们在处理这些短期任务的时候,真实的终点线如同就在眼前。在基本正常的项目里,大家努力工作,集中精力于两周之内需要完成的原型,就好像他们要在两周之内交付最终的系统。

注意,关键在于每个时间窗都真正有交付结果,只有进度是远远不够的。“让我们在5月底完成50%的规范”这样的任务,并不能达到令人满意的结果。人们会在心里嘀咕:“50%,也就是说5月底不能全部完成了。剩下的工作到底什么时候才能完成?”

还要警惕“明天”的特殊变体:耗费大量的时间来作准备。每个人都花时间去寻找完美的工具来支持测试;每个人都不厌其烦地讨论库文件的样子,向开发人员提供最完整的支持。如果把这些时间节省下来,用在项目结束阶段来收尾,价值会更大。

回忆起自己在苹果公司担任项目经理的日子,Sheila Brady对于“明天”与时间窗有这样的评论:“所有的项目,一旦到期无法收场,即使时间表上延长一周,还是摆脱不了失败的结局。”

和所有优秀的项目经理一样,Sheila意识到项目前期阶段的时间并没有像结束阶段的时间一样被仔细地对待,启动项目的最好办法就是立刻开始,而不是等“明天”。模式8眼神交流

在任务紧迫而且复杂的时候,组织往往会把项目成员安置在一起工作。

如今,采用多地协作开发的做法已经得到认可,也没有任何迹象表明这种做法将会在未来消失。你应该也了解有哪些成功案例。或许你已经发现自己的项目就是这样的案例,也可以解释为什么大部分的员工都在这个市区,也有少数在Kissimmee和Richmond- upon-Thames办公。都是因为想充分利用金钱和资源,对吧?

现在,还是痛痛快快地承认吧,如果项目的成败对你性命攸关,你难道会不想把所有的项目成员都安置在一个地方,让他们可以直接看到彼此?当然,或许远方的团队有一些人身怀特技,其他地方的项目团队无法媲美。如果这样,你可能会愿意接受分布式办公,否则就不然。关键在于,分散工作的原因应该是缺乏人才和技能,而不是金钱和资源。而且,工作越紧急,团队成员就越有必要在一起。

当所有全职的、专注的项目成员在同一地点工作时,会产生一些很神奇的效果。他们会了解彼此的需要和能力,而且随着了解的增多,他们会调整自己的行为方式,以达到最默契的配合。这种团队合作的理念,在配合熟练的曲棍球队中也可以发现。地理位置上的接近会产生一种无形的信息交流,理顺人际合作。

类似地,开发团队里有一些关键的信息交流对于紧密合作也非常必要,其中最重要的是信任的给予和获取。你可以通过电子邮件和电话与远方团队的成员交流,清楚地了解某些事情,比方说,对方要求的规范文档,以及他们应许和请求的承诺。如果问你是否相信对方向你传达的信息,你也许会说相信,为什么不呢?但是如果问你:“你对自己所了解到的信息有多少把握?”根据对方的工作地点不同,答案也迥然不同。对于一起工作的团队成员,承诺的应许和需求的表达还伴随着双方的肢体语言和之前的经历,这些也促进了关系的演化,你清楚对方的真正想法。同样的承诺和需求,如果来自万里之外,收到的时候就已经丢失了大量背景信息。

因为距离的间隔,双方很难相互信任。同样,也很难察觉语言的微妙之处、信心、某些讽刺和挖苦、真实意图、信服程度、无望感和无能为力感、轻重缓急,还有话外之音。缺乏了这些潜台词,沟通就变得脆弱。即便明白了大的背景,得出的结论也依然包含着不确定的因素。缺少了这些沟通,项目还能顺利进行吗?当然也行,但它肯定没有在一起工作的效果好。

在模式14中,我们断言不得不采取分布式开发的团队,即使成员之间会面的机会很稀少,也能从这些会面中受益匪浅。目光接触能改善交流的效果。如果项目足够重要,为了利用异地的同类资源而采取分布式开发实在毫无意义。相反,如果分散工作方式也能被本国或者全球其他地方的人员接受,那么很明显该项目不是特别重要。在可以实现目光接触的组织中,紧急性和复杂性是用来选择项目团队集中协同工作的决定因素。

在无视集中协同工作优势(这不能容忍)的组织里,分布式团队无坚不摧的神话早已根植管理层的思想深处。任何人,不管身处何方,只要在项目开始的时候可以派遣,就自然而然成为新项目团队的候选成员。在这样的环境下面,所谓的“团队”只是一个名号。模式9情绪戒指管理

经理不是基于摆在项目面前的风险、决策和问题来汇报项目状态,而是基于团队的活动、付出和热情。

去听听项目经理怎样谈论他们的工作,特别是他们怎样交流各自项目的状态。这往往在一定程度上反映出他们管理项目的方式。

下面的项目状态概要出自一位项目经理,我们假设她叫Donna。虽然这个例子可能有些极端,但它能代表众多的真实报告。“我很高兴地告诉大家,我们正处于此次发布的特性完成(Feature Complete)阶段。虽然有一些人的进度比较慢,但我依旧为团队取得的成就,以及每个人的努力工作感到骄傲。看到办公室里每个人脸上的笑容,我相信团队的士气依旧高涨。我很感激能够拥有表现如此优异的成员,而且我知道大家在不久后的某天就会完成剩下的一些特性。“接下来是一条悲伤的消息,我很遗憾地告诉大家Bob Jensen决定离开公司。Bob在过去五年里一直是我们QA团队的中流砥柱,我们会想念他的。Bob是继上月Kathy Enright后辞职离开的第二位QA。众所周知,Kathy也是一位非常有经验的测试人员,所以大家能想象我们的QA经理有得忙了。“我还有点担心某些新特性上的测试进度问题。现在来下结论还为时尚早,所以我还只是有一些不安。虽然见到好帮手和好朋友Kathy和Bob的离开我很伤心,但我们的QA团队一向以善于挺过艰难时期而著称,而且我知道他们以后会加班加点地工作。今后,我们会从QA团队那获得更多的信息。”

请注意Donna是如何描述项目当前状态的。

1.她更多是在谈高层次的活动、团队成员的认真努力,以及每个人对项目的热情。

2.她关注的是当前,以及之前或之后很短的一段时间,没有在时间、资源和交付物的整体框架内谈论团队的状态。

3.当她指出不符合计划的情况时,她表达的是由这些事引发的个人感受,比方说,“我,同样有一点担心……测试进度问题”。

4.她的观察通常不够确定,也没有设定期限,比方说,“我知道他们在不久后的某天就会解决掉剩下的一些特性”。

5.尽管偶尔有一些消沉的话语,这份报告总体上的语气是乐观的。

你也许会问,乐观的、带一点点情绪化的经理,有什么不好?当然,没有什么不好。但是如果项目经理的交流方式走向这种极端,你通常能发现两个问题。首先,这种风格的报告并没有完全实现最基本(所有的项目状态报告都应该达成)的目的:大家的注意力应当集中到那些最需要立即纠正的内容上,以尽量增加项目成功的可能性,但它没有做到。它也没有指出,在接下来的几个星期里面,有什么问题需要关注、决策、动手。由于Donna描述事情的方式,我们获得的只是从几个方面对工作整体的定性评价,根本没有对具体问题进行清晰的定量分析。

其次,频繁地进行这种交流更是有害无益,因为项目经理仅仅关注开放结论式的、目前进行中的行动,常常忽略了他们努力追求的最终结果。他们(和他们的团队)目光非常短浅,只关心速度。但是这些团队极有可能在项目的最后一分钟才发现,根本不可能按时交付,或者他们已经偏得太远,最后能交付的结果完全不同于之前的承诺。

如果说Donna的交流方式是一种极端,现在来听听Lisa,她是另一种极端的项目经理。“上周4月28号,我们赶上了特性完成(Feature Complete)的日期。本次发布包括18个组件,其中有15个已经处于‘特性完成’的状态;2个将在本周结束之前完成。最后那个组件——数据仓库接口——还要再迟一些,我们估计它得到5月20号才能达到‘特性完成’的要求。QA团队正在评估在多大程度上重新设定优先级才能解决这个延误,或者该延误是否会导致我们提出修改交付日期。在我们下次5月10号的核心小组会议上QA团队将给出一个建议方案。不管怎么样,产品管理领导已经同意,下个月可以在该特性缺失的情况下进行beta公测。“截至本周,已有特性的自动化回归测试套件已经完成,现在每晚都会运行。测试通过率是在80%左右,对于发布周期的本阶段,这是典型现象。我们希望测试通过率在四周后,也就是在beta公测的阶段能达到90%左右。“在过去的30天里面有两位QA工程师辞职,新特性测试的开发工作受到了影响。相应的招聘工作正在进行,但我们必须作好最坏的打算——假定新招聘人员不能及时入职并充分磨合,无法支援这次发布。QA正在评估从产品支持团队借几个人来帮忙的可能性。在一周内我们应该能知道这次人员流失如何影响新特性的测试覆盖率,但是现在,我们必须假定我们不能达到进度表上的测试开发完成(Test Development Complete)里程碑了。”

Lisa的项目状态概要与Donna的在如下几个方面有所不同:

1.她选择了基于最能反映工作进展的交付物的状态来评述;

2.她关注于项目的产出、问题,给出了计划的修改建议,同时指明了必要的纠正举措和决策;

3.她的评论是独立的,而非不可切分,而且大部分都是可测的;

4.她在客观和主观方面达到了很好的平衡。

很少有经理会完全像Donna或者Lisa一样交流,大部分都是两者各取一部分。不管怎样,Donna式的经理们还是值得注意:长期关注付出的努力而非进度本身,有时反映出项目经理没有很好理解领导和管理的区别。

哦,顺便说一句,尤为重要的是从自己身上寻找Donna的影子。如果你发现你的个人交流有这种影子,就要问自己是否需要这样做,因为和Donna一样,你并不清楚团队应该走向哪里,只知道每个人都在努力工作以求完成任务。模式10忠实信徒

个人把某种思想作为真理来膜拜,与经典稍有偏差即被认为是亵渎神灵。

几乎所有流行的软件工程方法学都来源于软件从业者的经验,而不是基础研究。大家积极记录下项目里对自己有用的经验,这些经验从小的群体传播给更广阔的人群。与很多业内领先的流程设计者交流之后,我们得知他们中的大部分人承认:(1)他们的方法适用于特定领域或者特定大小的项目;(2)他们的方法从来没有被期望如同描述的一样用在所有可能的环境中。

我们的CASE工具ProMod的早期版本里,很多客户认为OK的东西都被标成错误。不管用的是什么方法,我们都是按照书上写的来做——我们是忠实的信徒。无论何时,只要书中提出一项建议,或者给出一个例子,我们都从中抽象出规则,作为硬性规定写进系统里面。如果用户没有严格遵循我们的规则,就标记一个错误。后来我们意识到,应该把那些东西标记为警告而不是错误。再后来,我们又意识到,应该把所有的消息设置成可选的;换句话说,让用户决定是否开启这些选项,并且允许用户违反规则。——PH

虽然大部分的流程论著对于方法的可用性给出了适当的警告,但忠实的信徒要么忽略这些警告,要么根本不看那些包含警告信息的书页——大部分都在书的最后。如今,拥护XP的风潮日盛,但有人甚至没有读过Kent Beck第一本书的倒数第二章。在那一章里,Kent很清楚地解释了该方法的缺陷。

我有一个客户,她的软件工程技能和热情被老板认为是一个主要的成功因素。我们讨论他们最新版本2.1产品里面的UML活动图。让我吃惊的是,她竟然说拒绝使用公司选择的UML工具,“因为它不支持所有的最新特性,比如n维泳道图、中断区域,以及参数集合”。相反,她更倾向于使用Visio图形库,因为依靠这些图形库,她才能严格遵守新动作语言的所有建议。她声称她的的确确需要所有的特性。这就是忠实的信徒。——PH

项目上的忠实信徒会妨碍工作的进展。他们不去专注于内容,反而为方法争执不休。通常,你能在被请到现场帮助解决方法问题的咨询师中发现忠实的信徒。最终的冲突往往发生在两位主要负责人(内部人员或咨询师)皈依了两种不同方法的时候。于是代理人的战争爆发了!不管他们多优秀,你最好离开他们中的任何一个,以便继续做你的业务。“不同的项目需要不同的方法。”——Alistair Cockburn,《敏捷软件开发》模式11出租灵魂

从业者愿意放弃长期练就的技能或者技术。

合格的专业人士有一点令人钦佩,他们能够根据待解决问题的实际情况来裁剪解决方案,而不是把个人或者团队久经检验的技能强加在问题上。这不是说团队成员不懂应用已知的工具或方法。他们没有把灵魂卖给任何技术,只是出租了自己的灵魂。换而言之,一旦出现了好的新思路,他们能够比较优劣,明智地决策。

要放弃长期坚持甚至精通的技术不容易,但灵魂出租者能够忍受暂时的不适。他们知道,现有的技术已经足够解决问题;他们也清楚,某项新的技术也许能带来更大回报。他们并非追赶最新技术潮流的狂热分子,但也愿意放弃已经熟练的工作方式,去考虑其他名副其实的先进技术的好处。他们着眼的是未来,不会从现状中寻求安慰。

成为灵魂出租者的好处是,当技术潮流退去时,你不会在沙滩上裸泳。你可能知道,有些人自诩为开发人员,却很久都没有尝试学习新的编程语言。这些人眼巴巴地搜寻提到自己所用语言——当年也曾风行一时,但现在基本不再使用的编程语言——的工作职位。悲哀就在于,他们把灵魂卖给了那种开发语言。

整个团队都成为灵魂出租者不那么容易,不过一旦成功,最终的收益会让人们认识到,付出的艰辛是值得的。诚然,任何组织都不能任意更改自己选择的技术。组织都需要在开发语言、开发方法、技术基础设施,以及其他方面保持相对稳定。但我们这里讨论的是态度。当组织决定不断研究新技术的时候,它就打造了一块金字招牌,能吸引最优秀最聪明的人才。这相当于在向所有人宣布:“这里有一家与时俱进的组织。为我们工作吧,我们不会让你在技术潮流退去时裸泳。”

新的并不一定就是好的。新技术(编程语言、建模技巧、方法学或软件工具)问世的时候,蛊惑人心的宣传通常也随之而来,而且很多时候是大肆炒作、广告轰炸。有时,新技术被看作是银弹,最先进的技术将会带来巨大的进步。有时候人们臣服于宣传炒作,在出售灵魂的过程中变成不会思考的狂热分子。结果,他们使用新的技术解决方案去处理一切问题。灵魂出租者则相反,他们分辨出技术向人们许下的承诺和实际的效用,同时,因为看清楚了技术的优势,他们能据此作出合理的选择。

技术正以爆炸般的速度发展,今天炫目的创新,都会变成明日黄花。灵魂出租者,不管是组织还是个人,对自己使用的技术都是走马观花。他们不会狂热拥抱新技术,因为他们知道这不过是一场盛夏恋情。除了使用,他们对技术不作任何夸张的承诺。他们提出的问题往往是“这项技术适合什么问题”,而不是“我怎么用它解决这个问题”。

能够把问题本身跟解决方案区分开来是成为灵魂出租者的第一步。第二步则是要懂得,无论这门技术多优秀,明天总会有更优秀的出现。不要学浮士德把灵魂出卖给魔鬼,不要签下把灵魂卖给某项技术的契约。模式12系统开发旅鼠周期

虽然组织流程明确需要灵活定制,但项目团队依旧盲从于呆板的标准。

受CMMI、SPICE、ISO9000或者其他流程改进计划的驱动,很多公司纷纷为自己的开发流程制订了内部标准。很自然地,这类流程模型会规定开发团队必须定义的成员角色、团队必须执行的活动、团队必须交出的结果。显然,大多数的流程模型并非可以直接套在各种项目上。因此,它们中有些(比如德国V模型和RUP)也提供了可扩展的定制介绍,允许团队根据项目的实际情况调整角色、活动和结果。

定制流程并(特别是)改动交付结果需要勇气。如果你略过了某些步骤或者拒绝交出一些结果,万一项目失败,你会为千夫所指。很快就会有批评说,如果你严格遵循流程,写完建议的所有文档,项目可能就成功了。大家因为害怕指责(或者害怕惩罚)而不愿意打破陈规。最后的结果是,团队出于保险起见而抓住了每个细节,把所有建议的章节和段落都事无巨细地加进需求规范里面,制订质量管理计划(每个里程碑都有相关规定),把任务分解结构(WBS)中的每个工作单元都分派到个人:林林总总,不一而足。

我问Philippe Kruchten,如果重做,会有什么改变。他的大致意思是说,如果能再次开发RUP,他会让根据具体情况定制流程变得更加容易,并且提供工具支持,以鼓励项目真正去这样做。——PH

缺乏勇气并不是墨守陈规的唯一原因。通常的原因更简单。根据项目的实际情况定制流程需要做更多的工作。项目经理已经被其他更紧急的项目因素缠住了,哪里还能分身进行头脑风暴,为这个项目去建立一套规范?理由往往是这样的:公司已经(从项目团队之外)聘用了聪明人来定义流程和交付目标。我们为什么要质疑他们的才智?按部就班地做吧。他们不可能犯那种错。再说,又没有人给我付钱来根据实际约束来修改流程。所以,我们别在流程实施上浪费时间了,照章办事就成了。这样的话,我们就能立即开始做项目了。

如果流程没有考虑到项目的实际需要,直接套用也许能提前开工,但却无法提前完工。

项目经理放弃定制流程,就像厨师死板地照菜谱来烧菜,永远也不会成为好厨师。当然,好的厨师也是从学徒工开始的,从他们的师傅那里学习基本的做菜手艺,模仿师傅的菜谱。一旦掌握了基本技能,摆脱了标准菜谱的约束,他们就能脱颖而出。模式13清空“板凳”

组织过于精简,以致于任何关键人物的缺失都会造成灾难。

如果你曾经设定过两个闹钟,或者在汽车的储物空间里放一些零钱,目的“只是为防万一”,你知道自己不过是采取了最实用的风险管理手段。天有不测风云,你保护自己的方法就是多储备资源。

如果你来管理一支专业知识人员组成的项目团队,关键人物的缺失很可能就是最明显的风险。所以很自然地,你也早已暗地预备了替身,对吗?兴许只是一两个人,他们拥有需要的技能,可以直接顶替项目中任何一位关键的人物。没有?真的吗,这怎么可能?

你没有安排人员储备的原因是想省钱(请注意,这非常重要)。如果储备人员不用花钱,你可能就会大量储备,可惜他们都得花钱,所以你没有这么做。要保证效率,就要用尽量少的人员来完成工作。经济上卡紧一点可能不好玩,但它的确有效地利用了资源,不是吗?

这种逻辑的问题在于它只看到了金钱,丝毫没有考虑时间。在大多数开发项目里,时间是比金钱更稀缺的资源。你的项目,在未来的某个时间点上,很可能会发现时间不够。一旦发生这种事情,你和上级管理人员就只能寄希望于贴点小钱来“购买”更多的时间。可是已经太晚了,已经没机会“购买”时间了。

留些“板凳成员”,在关键人物离开的时候,可能就是种拿金钱换取时间的方法。如果你审慎地储备人员,也许就能储备某些关键的项目技能。从表面上看,你的团队规模超出了最低成本的要求,但是储备的人员不会闲置。他们的能力可能会稍微超出任务的要求,毕竟他们需要在必要时刻顶上去。这样的好处在于,如果某个人离开,也许在手边就有一个合格的替补,并且他作好了迅速填空的准备。比起事到临头才开始寻找替代人员,你的项目会节省很多时间。模式14面对面

分布式团队需要在不同地点进行大量的面对面交流,才能建立熟悉和可靠的感觉,使异地合作开发成为可能。“在计算机学会会议上,总能听到年轻的开发主管声称他们更喜欢一个小型的、由一流人员组成的精英团队,而不是由几百个——同时也意味着平庸的——程序员组成的项目团队。我们都这样认为。”

有些人可能会觉得这几句话似曾相识,有些人也许会惊讶地发现,30多年前就有人说过了。今天,虽然头衔由“程序员”变成了“开发人员”,但这样的言论依然存在。今天的经理们仍然偏爱那种由明星成员组成的、小型的、集中办公的团队。30年前如此,40年前如此,50年前也是如此,直到今天依然如此——这才是开发软件最正确的方式。

但是如今,异地合作的大型开发团队似乎比以往更常见。你也许参与过团队分布在六个以上地点的项目,不过分布于两三个地点的更为普遍。没错,虽然一个大型分布式团队可以由多个更小的、集中办公的团队组成,但是如果子团队负责的是整个系统或者需要集成的各个组成部分,就只能采取分布式团队的管理方式。

无论动机如何,分布式开发之所以迅速盛行,可能仅仅是因为协作技术的出现使之不再像以前那样让人望而却步。团队借助即时聊天工具、wiki、视频会议和网络会议以及传统的电话会议和电子邮件,克服分布式开发带来的重重困难。

所有把分布式团队管理得井井有条的管理者,都会专门为团队成员提供至少是偶尔聚在一起的机会。为什么面对面交流对分布式团队的成功如此重要?如果面对面交流不够充分,同一地点的团队往往会以高傲的姿态对待其他地点的团队。“其他地点”通常就意味着“蠢材、白痴”。定期的、适度频率的、跨职能的面对面交流能增进友谊,出现问题时大家也会从好的方面去理解,而电话会议和网络会议则会起到相反的效果。

那么,什么程度的面对面交流才足够?这一点因团队而异,但下面的通用建议也许能帮助你对自己的项目作出决定。

●在几个地点之间负责协调工作的人需要最频繁的交流。这些人通常都顶着程序经理、项目经理或者发布经理的头衔,他们在每次发布周期里面都需要多次面对面的交流,每季度碰面对他们远远不够。

●对于开发人员、QA工程师和技术文档作者,其中的资深人员在每次发布周期里面至少需要与其他地点的同行碰头一次。在这个层次建立相互的信任和尊重,有助于这些意见领袖在本地影响初级的团队成员。

●偶尔允许初级的团队成员前往其他地点。这能帮助他们认识到自己的工作如何配合团队的整体任务,也让他们有机会接触到其他地点资深员工的榜样,学习其职业生涯规划。同时,在他们凭自己的才华争取晋升的时候,其他地点的同级对他们的肯定也是非常有帮助的。

在建立远程团队之后,因为削减成本的压力无可避免,组织作出“临时”限制出差的决定,“直到情况有所改善”:这样的分布式开发毫无疑问是百分百失败的。要想成功进行分布式开发,几乎可以肯定的是,必须增加而不是减少出差预算。

分布式开发天生就是高难度、高风险的活动。有时,接触并留住令人满意的人才可以抵消一部分分布式开发的风险。借用Tom Wolfe的名言:“我不建议这么做,你知道的,但真要做的话也是可以的。”

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载