大道至易:实践者的思想(五十六):谋定后动,项目的存在权——自己想办法(再谈《人月神话》)

阅读数:15 2019 年 10 月 10 日 14:39

大道至易:实践者的思想(五十六):谋定后动,项目的存在权——自己想办法(再谈《人月神话》)

软件工程原本是只讨论“过程 + 方法 + 工具”的,这是纯粹工程学的视角2。这其中即使有一些看起来与人相关的话题,也不会被过深地讨论到。例如,过程中显然涉及人,但不会因此而讨论到“过程中的产品环节是否可以由开发人员来兼任”这样的问题。事实上,在“纯粹的”软件工程的讨论中,过程的各个环节都是由一些“角色”来推动的,这些角色如何存在于一个具体组织的部门中,其职业定位、能力结构等都并不算一个严格意义上的工程话题。

2 事实上,还会讨论到“目标”问题。但在传统工程中的“工程目标”并不是确指,而是使用“需求”来指代的一系列技术方法。传统工程基于“需求”而非基于“具体目标”,并且——与此相关的——它与架构的“面向问题”也是互相背离的。因此传统工程中的工程师视角下的思考,对“架构师”这一角色在团队中的融入帮助并不大。

但是这样的“纯粹”显然遇到了挑战。当我们试图将工程完全地理论化之后,它就必然面临实践的困境。“人”的问题在这方面首当其冲。《人月神话》并不是一个“人 / 月”的度量理论那样简单——事实上那本书很少讨论工程度量的问题。《人月神话》在工程上的重要性在于,它严肃地提出了“人,是不是工程学问题的一部分”这样的话题。这本书的答案将这个话题引向了一个极其巨大的迷局,即如果需要更多的人来实现工程,则应付由人带来的复杂性可能将超过工程本身的技术复杂性。《人月神话》一方面有先见地对技术复杂性提出了一些可靠、可行的方案,另一方面也悲观地认为由人带来的复杂性必然导致“巴比伦塔”最终的倒掉。“没有银弹”的论证过程将所有的焦点集中于:通过(较小规模的)程序实现的过程,无助于求解(包含大规模工程在内的、普遍含义的)根本任务。

作者 Brooks 把三个问题从《人月神话》的讨论中摒除了出去。其一,项目必是有始终的;其二,哪怕是一个不成功的产品,也是需要交付的;其三,团队是人的问题,并不是事的问题。《人月神话》将这三个问题的前题隐设为:项目需要承担大量的附加责任,产品必须是尽善尽美的,以及人是私利的。而这正体现了“工程学”的学术本质,即如果我们可以的话,应当基于工程来解决一切问题;因而它必须首先是能解决一切问题的。

在这些年的实践中,这是我所见的、对“一件事”具有最大伤害的但又貌似义正辞严的、跨越行业与组织的普遍观点了。我之所以用这样复杂的定语来说明这一“普遍观点”,是因为它确实那样“自然而然”地存在着,就像我们每个行业都受了同一个神灵的启迪一般。事实正是如此。任何一个有道德、正义而又富有职业责任感的产品经理都会跳出来,说“这个产品没做好是我们的责任”,然后历数种种设计细节,再加以细化,并立时加入你的需求库;任何一个有同样品质的项目经理也都会跳出来,说“这个项目没做好是因为我们对流程的贯彻不够”,然后开始制定更详细的管理措施;然后开发人员也跳出来,说出超过 200 个的技术改进点……

但每个人都将问题揽在自己头上,这难道不是一种好的品质吗?如果是,那么我又怎么会用一种调侃的语气来说出上面的假设?

这样的假设,在于警示我们一个被忘掉的事实:这是一个系统,并不在于一人一已或者一个角色的过失,也不取决于某一个角色的单方面的努力。这些“积极、冲动而又充满道德责任感”的人,事实上是无助于找到系统问题的答案的。我们总是可以现实中找到许许多多具有这种性质的工程、产品与过程模型,并且在这样的模型中,(提出模型者所代表的)中心角色也总是认为自己应当能够并且也必须能够去承担更多——因而也就更重要,因而其他所有角色都应该围着自己打转转。

然而这样一来,每一个角色都站在一个自己认为“更合适”的角度来看我们在做的事情,而全然不管那件事情本身为何。例如,开发人员可能认为自己的某项技术发明有着相当“巨大”的前景,于是期望着有一个团队来配合自己将它实现为产品。至少在他看来,由技术推动产品和市场是相当伟大的成就。但是,一旦他提的这个想法如同扔进了泥坑一样丝毫得不到反馈,那么他又立即开始着手“发明”下一个技术与想法了。

你会发现,他原来根本不需要对产品和市场负上任何责任的!他只管提出,而不需要负责任,那么又怎么可能站在别的角色上去思考问题呢?

所以我再读《软件工程》这本教材的时候3,就只会看到一些“管理的技术”了。然而我从不指望,把“管理”当成技术手段和工程方法的人能真正地做好项目。

3 早些时候的《软件工程》教材是不讲团队、管理等内容的,但后来它们都逐渐地加入了相应内容。但老实说,这些书——例如《软件工程——实践者的研究方法》与《软件工程(Ian Sommerville 著)》等——中有关于人的讨论都是隔靴搔痒、无济于事的。这些经典的、学术化的工程方法仍是以自己为中心的,它们试图把管理学、组织学或社会学“拿来一用”,其思想离“看到一个项目自身的系统性”还相当之远。

我的意思是那个具体的、眼前的项目。

评论

发布