一个名称空间牢笼的例子

本文为这个文档写一个例子,因为比较长,所以独立成文:

in nek:狂人日记读后感——名称空间囚笼zhuanlan.zhihu.com图标

我们是一个从学习、跟随逐步走向领先并参与国际顶级竞争的IT企业,在这个发展的过程中,我们从“创新”导向转向“实现”导向(“以客户为中心”)导向,我们培养了完善的开发流程,质量保证手段,和一大批以“完美服务客户”为目的的管理者、项目经理、设计师和一线工程师。所以,当我们开始领先,开始定制自己的标准的时候。这些流程,人员全部成为了我们设计标准的障碍。为了满足一个标准,我们必须进行大量的测试,要维持一个版本的持续质量。这个过程中,设计师,特别是高层的设计师和构架师,其实是不那么重要的,而测试流程才是第一位的。而实现一个标准本身,我们必须“设计”,必须“试错”,至少在落地以前,必须聚焦到设计上,质量保证相比来说,几乎可以忽略。这其实就是整个工业生态完整工作的两个关键部分:构架师负责设计,实现者负责落地(所谓Landing)。由于这个巨大的分工,处于下游的企业会形成一个人力模型,他们的人力和制度都趋向于支持落地,反对设计。

这下问题就来了,当我们做设计一类的工作的时候,无数的人给你提出这样的要求(本例子中的“我”讨论的方便,区分两个理念的表达方,不一定表示我自己或者某个特定的人):

“既然你们已经写代码了,为什么不加入CI系统进行质量保证?”

“你说你是验证构架,好,我对你的的要求可以低一点,你自己制定标准,你说怎么测试?”

我给他们解释说,“你看,我们有一些Idea,为了证明这些Idea,我们可能会纸面写一个流程,一旦发现有逻辑冲突了,我们就抛弃它了。也有可能呢,我会为此写一个程序,这个程序写到一半,我发现它没有前途,我也会抛弃它。我会写代码,但这些代码的目的是那个标准,不是这些代码本身。如果你看到我写点东西,就要我放到CI系统去,然后每天给我发看板,让我和其他项目的‘进度’比较,我们这些团队在大家面前受怎样的压力?我们真要做交付,不比其他开发组做得差呀,我们因为重心是推演架构所以才不适合玩这个游戏而已,你非要我玩这个游戏,这不是给我做这个工作制造障碍吗?”

对方说:“我明白你的困难了。那我们对这个工作降低一点标准,我们只要把这个代码备份下来,大家Review过就好了”

我说:“你说出‘降低标准’这句话,就已经把团队置于不想干这个活的境地了。凭什么不动脑就做质量保证的团队干的活就叫‘高标准’,我们干这么难的活叫‘降低’标准啊?而且,我这个就是临时的推演,你非要走一个‘仪式’,要Review,付出Review这个时间,大家就有‘珍惜’的心了,怎么还会把目标聚焦在‘做好这个标准’上呢?”

对方:“那你们就不review你们的代码了?”

我:“那也不一定,这完全取决于对标准的推演是否有必要,这个问题要具体问题具体分析啊。”

对方说:“好吧,我考虑到你的难处了,但你这个架构或者标准定义好了,最终不是要实现的吗?你可以先把架构定义好,然后再把代码写好啊,这样我们就可以做质量保证了。”

我说:“按你这个意思,其实你是看不懂我架构设计的部分的,你其实只关注最后写成的代码。如果是这样,你认为我们团队中的工程师会努力做一个让整个行业参与的标准吗?他们要快速达成目的,显然会首先保证他自己的实现能做好啊。这样的结果我们构造产业和生态的目的不就落空了吗?”

对方说:“那你的意思是你们写的软件都是没用的喽?”

我说:“这个问题的答案是‘我不知道’,你说这个软件‘没用’,这不对,因为我们写了这么多软件,总是会有用的。但‘部分有用’,不表示我所有软件要参与‘交付’才用的QA过程啊。”

对方说:“说它‘有用’也不对,说它‘没用’也不对,你到底要怎么说才对啊?”

我说:“但这是现实啊,本来这个东西就不能简单认为它‘必然有用’,也不能认为它‘必然无用’啊。我们写了这么多推演代码,当然不能说都有用,但你认为他们必然没用,这也掩盖了这个工作本来可以起的作用啊。”

对方说:“哎,难道我们非要在一些这样空口概念的问题上纠结吗?我们赶紧开始工作不好吗?”

我说:“如果你觉得这些不过是些‘空口概念’的问题,你让我一下不就行了吗?你又何必跟我争?你按我们的方案赶紧开始工作不好吗?”

对方说:“哎,你这么强势,你让我们的QA团队,项目管理团队怎么干活啊?”

我说:“他们应该学习新的工作的特点,按新的特点来考量QA策略和项目管理策略啊,难道项目资源是为QA和项目经理服务的,而不是为项目目标服务的?是项目需要为项目经理和QA做出改变,还是项目经理和QA为项目目标做出改变啊?”

对方说:“他们要学习也没有这么快啊,要不这样:我们做一个最轻量级的流程,尽量不拖累项目,你们该干嘛干嘛,但还是要走一走流程,这样可以不?”

我说:“不行!我接受了一个极其困难的工作,我们并非不需要项目经理和QA,我们需要他们换一种方式工作而已,如果我这样妥协,大家的心思都不在面对我们的困难上,而在怎么让流程好看上,我们用什么力量去面对挑战?这好比打仗,我们面对强大的敌人,结果一群领导都不认为冲锋陷阵有什么困难,而每天给我讨论军容军姿是否正确,那还打个屁的仗啊?我们得让大部分人看见敌人才有可能战胜强大的敌人啊。”

……

不知道读者能否在这个例子中看到多少因为概念空间而导致讨论不下去的点?看到多少因为利益关系而被人们避免讨论的点?人们习惯了出一个版本,测试,再出一个版本,测试,然后发布这样的流程。你和他们说你推演,重定义,再推演,再定义……这个东西,他们根本没有直观感觉,要学习这些新知识需要时间,你要“说服”,你就根本缺乏概念去说服他们。这样反而显得别人振振有词,而你在强词夺理。就好比《呐喊》中的祥林嫂们,阿Q们,你怎么给他们讲现代科学,讲民主,讲人性?你越是个谦谦君子,希望使用他们的语言,就越显得你没有道理。

更大的问题是,你就算很辛苦说服他们接受你的意见了,你的万里长征才刚刚开始,因为你只是破坏了他们原来的逻辑空间,你自己的逻辑空间还需要资源来建。你的方法还需要时间来推演补漏,要有一个建设的过程,而这些辛辛苦苦放弃他们的设想的人,不来批评就已经很君子了,你想他们和你一起奋力建这个新的逻辑空间?难之又难。

但你能怎么办呢?就以上面这个定义标准来说,你要定义一个标准,你的方法就一定不能是开发的手段,一次编码,立即要质量保证,稳定,然后发布,上线。用这种方法,他们就没有成功过,你看到了“月亮”,你知道这是“吃人”,你要挣扎,你就只是精神病,只是狂人。他们的名称空间中,这一切都可以解释,比如他们做的“标准”没人用,主要是因为其他人妒忌,是因为推广资金不够,是因为我们太强大,吓跑了合作伙伴……但他们不会承认,他们的根本不是标准,而是一个“实现”,他们的设计逻辑不自恰,除了他们那个实现能跑,任何其他人根本都加不进来。你不破坏他们原来的逻辑空间,你这个工作连开始都没法开始。你当然可以独善其身当白莲花,但白莲花改变不了现实,只能孤芳自赏。

所以,除非真正的革命者,大部分人到头来就还是像狂人一样——赴某地候补矣。

救救孩子。

编辑于 01-12

文章被以下专栏收录