译者序

什么是项目?按照PMBOK的解释,项目是为提供某项独特产品、服务或者成果所做的临时性努力。现代项目管理通常被认为始于20世纪40年代,但项目管理自古已经开展于一些主要基础设施如埃及金字塔、运河、大桥、教堂、道路、城堡等的建设之中。从古老的“巴别塔”到20世纪40年代的美国曼哈顿计划,再到如今全球性的项目运作,项目管理的思想和实践已经走过了洪荒时代,进入到成熟、科学的阶段,在各个领域中大放异彩。

然而,相较于其他领域而言,软件还是一门非常年轻的领域。也正因为此,软件自从诞生伊始,尤其是在20世纪60年代软件危机爆发之后,其从业人员就一直在尝试着借鉴其他领域的思想,引入各种隐喻来描述软件领域的行为和事物,加深人们对于软件开发的理解,提高人们对于软件开发项目的洞察力。《代码大全(第2版)》指出:“David Gries说编写软件是一门科学(a science)(1981年),而Donald Knuth说它是艺术(an art)(1998),Watts Humphrey则说它是一个过程(a process)(1989),P. J. Plauger和Kent Beck都说它就像是驾驶汽车(driving a car)——可他们两个却几乎得出了完全相反的结论(Plauger 1993,Beck 2000)。Alistair Cockburn说它是一场游戏(a game)(2002)……而Fred Brooks说它像耕田、像捕猎,或像是跟恐龙一起淹死在‘焦油坑’里面(1995)……”

如果拭去隐喻带来的神秘性质,翻开思想和方法的装饰,直面软件领域与其他领域的根本差异,我们可以发现软件的核心特征在于其抽象性。软件开发由需求(问题域)到可执行的源代码(解决域),正是试图以一种抽象的形式捕捉或者展示另一种抽象。软件的抽象性导致了其他领域所不具备的两个重要特征。

  • 项目的不可见性。软件开发主要是一项抽象性活动。基于此,计划的执行情况、变更的影响范围、风险的大小等因素对于软件项目都是在一定程度不可见的。如果缺乏对这些因素的把握,项目必然是不可控的,必将走向失败。

  • 概念建模的复杂性。软件的本质复杂性源于概念模型的抽象和构建。而这一活动又属于智力的创造性活动,极大地取决于程序员对概念的掌握、理解以及再具象化。这些行动是无法通过灌输、强制等措施来做到的。

这两个特征使得软件开发蒙上了一层诗意的瑰丽色彩。《人月神话》在首篇“焦油坑”中对程序开发有非常形象的描写:“程序员,就像诗人一样,几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象,来建造自己的‘城堡’。”软件以及软件开发与其他领域的差异正导致了软件项目异于其他领域项目的一个很重要的特点:对人的依赖性。人是摆在第一位的,正如Alistair Cockburn在《敏捷软件开发》之中把软件开发形容为“关于创新和沟通的正和博弈”,能否玩好这个博弈游戏,取决于游戏中每位个体以及他们之间的沟通与协作。如何施以管理,让人发挥最大的创造力,让团队保持持续稳定的开发速度,让项目最终走上成功?

也正因为此,二十年前的《人件》试图从社会学的角度来重新诠释软件的开发和管理,“我们工作的主要问题,与其说是技术性的,不如说更多的是社会性的”,围绕着“高效的项目和团队”探讨了资源管理、环境、团队建设等方面的种种实践。其中,作者指出了“管理工作需要系统思考、启发式判断和建立在经验基础上的直觉”。技术也许可以通过技能训练弥补,但经验的缺失却只能是通过经验的积累和传递。可惜的是,当下的软件管理书籍更多的是来自于学院派的理论和指导,缺少具体经验的传承。比如,项目的不可见性会有哪些形态?如何解决项目的不可见性?如何简化概念建模的复杂性?这些经验对于软件从业人士是亟需且多多益善的。

二十年后,《人件》的两位作者再次携手,延续《人件》的风趣和尖锐,推出了这部《项目百态》。《项目百态》包含了86种项目行为的模式,每一种模式都是实际经验的提炼,在风格上与《人件》一脉相承。每一种模式都命以一个通俗直观的名字,配以一张关联的图片和一段点题的说明。大部分的模式都是通过一则有趣的故事来引出问题,再以作者们的真知灼见一针见血地分析问题的根源与特征,最后以作者意味深长的总结收尾。

对于任何一项模式,作者平白表述的背后都是一个个倒下项目的身影。比如“明日复明日”(模式7),有多少项目因为目标设置过于遥远,导致项目计划对人们不再有紧迫感。又比如“残局游戏”(模式47),有多少项目沉醉于项目就绪度舞会之中,却浑然不觉截止日期渐进,而交付物的质量尚不曾经过检验。又比如“牵涉性疼痛”(模式6),“头痛医头,脚痛医脚”的庸医做法把多少项目扼杀在尚未可期的状态。又比如“主面板”(模式16),相信有很多项目已经使用主面板来直观了解项目状态,但对于如何设计良好的主面板却所知甚少,作者分享了一些经验。又比如“稻草人”(模式26),建模是困难的,从无到有的建模更是难上加难,何妨试试“稻草人”,阅后即焚?掩卷沉思,既悚然于种种模式的似曾相识,又庆幸于有些错误仍未出现于项目上,还有时间处理出现的问题。此时,不禁长叹一声:软件项目还可以这么玩!

本书不仅适合于项目团队的各种角色,也适合于软件组织参与到组织间“博弈游戏”的各种角色。事实上,围绕着软件项目的各种角色都能从本书中受益。从项目监控的角度上,分析自身项目的态征,如是否存在“错误的质量关卡” (模式34)、“造纸厂”(模式79)等;从团队建设的角度上,团队之中是否存在“英式保姆”,“本”(模式54),或者“记者”(模式49)和“影评人”(模式19),或者勇于跨出“蓝色区域”(模式44)的人;从项目交付上,团队是否交付了“没人在意的交付物” (模式61);从项目生态管理上,“空椅子”(模式50)、“堆积”(模式77)是否存在于项目之中,各种角色是否“互相教学”(模式65)。

当然,相对于《人件》,这本书可能在结构上存在着白璧微瑕。它没有像《人件》一样把相似的模式归并在一起,而是选择了以相对零乱的顺序来阐述。事实上,本书中的很多模式,比如“错误的质量关卡”、“造纸厂”等都可以归为一类。但这或许也是作者的匠心,并不试图勾勒软件项目的全貌或者结构,而是试图从不同的视角来观察、投影软件项目,然后从每一个视角窥一斑而识全豹。回忆对未知事物的认知模式,分解和投影往往能给人相对直接和较深入的体验。这些体验汇合在一起,给我们一个对软件项目的全面而直观的认识,又岂不快哉?

本书的翻译得到了很多人的帮助,我无法逐一列出。首先,要感谢刘江,正是他的推荐,才让我没有与这本书擦肩而过。其次,要感谢图灵的各位编辑们:他们的耐心,让我可以慢慢地斟酌自己的翻译;他们的细心,帮我发现了不少错误;他们的专业,让本书的排版和标注不再凌乱。

感谢我的父亲金建华和母亲胡赛花,我对文字的热爱很大一部分是来自于父亲深夜挑灯读书的背影,而母亲一直尊重我对软件工作的选择,即使那意味着她的儿子离开自己、置身于千里之外。虽然他们都已经不在了,但是当我孤单的时候,他们的目光一直是我前进的动力。我要感谢我的弟弟金成,他承担了照顾父亲和母亲的大部分责任,让做兄长的我可以将更多的精力放在工作上面。我还要感谢我的女朋友,虽然我们身处两地,但她始终给予了我足够的信任和支持,让我可以做我感兴趣的事情。

最后,由于本书是由六位风格迥异的作者写就,各成风格却又风趣一致。将原意表达出来又不失趣味是我的目标。虽然我已经下了不少功夫,但终究经验和能力有限,译稿之中难免有疏漏之处,欢迎读者批评指正。

目录