软件随想录(local.joelonsoftware.com/wiki)-2000年10月04日 无痛功能规格 - 第三篇: 不过...要怎么做呢? - Painless Functional Spe

From The Joel on Software Translation Project

无痛功能规格 - 第三篇：不过...要怎么做呢？

作者：周思博 (Joel Spolsky)
译：Paul May 梅普华
编辑：Jeff Wang 王家麒
October 4, 2000
A part of Joel on Software, http://www.joelonsoftware.com

现在你已经读过为什么要规格和规格里有什么，可以来谈谈什么人该写规格。

谁在写规格？

请容我在此提一点微软的历史。1980年代当微软开始快速成长时，那里每个人都读过The Mythical Man-Month这本软件管理经典(如果你还没读过这本书，我可是极度推荐)。这本书的主要重点是说，在进度落后的项目中增加更多程序员，只会让进度更加落后。这是因为当团体中有n个程序员时，沟通路径的数量会变成n(n-1)/2，也就是以O(n²)增加。

既然当时众所周知增加程序人员只会让事情更糟，所以微软的程序人员都在思考要如何撰写更大的程序。

担任微软「主设计师」多年的Charles Simonyi提出了主程序员的概念。这个点子基本上是让一个主程序员负责撰写所有程序，不过他或她底下有整组充当「程序奴隶」的菜鸟程序员。主程序员不必费心替每个函数除错，而是定出各个函数的原型，建立基本结构再丟给菜鸟程序员实现(理所当然的，Simonyi会是最大的主程序员)。主程序员这字眼有点古老，所以微软用的词是「程序经理(Program Manager)」。

理论上这应该能解决Mythical Man-Month的问题，因为大家不需要互相沟通(各个菜鸟程序员都只和程序经理沟通)，所以沟通路径是以O(n)而非O(n²)成长。

哎呀，Simonyi可能精通匈牙利表示法，不过他不懂Peopleware。没有人会想当写程序奴隶的。这种系统根本行不通。最后微软发现，尽管有著所谓人月神话(Mythical Man Month)的问题，还是能在团队中增加聪明人而提升产出，不过边际价值也会减少。我待在Excel团队时里面有50个程序员，生产力的确比25个人团队高(不过没有多到两倍)。

主奴式程序作业的点子行不通，不过微软里面还是有一堆叫程序经理的人跑来跑去。有个叫Jabe Blumenthal的聪明人重新创造了程序经理这个职位。从此之后程序经理就负责产品的设计及规格。

自此至今，微软的程序经理就是在搜集需求，定义程序应有作用并撰写规格。每个程序经理通常配5位程序员；程序经理以规格方式定义产品，而程序员则负责以程序实现写出产品。程序经理也必须负责协调行销，文件撰写，测试，地区化，以及程序员不会花时间处理的其他烦琐细节。最后当程序员只要全心贯注让程序正确无误时，微软的程序经理还得心系公司的「愿景」。

程序经理是非常宝贵的。如果你曾经抱怨程序员太重视技术优雅而忽略市场性，你需要程序经理。如果你曾抱怨大家写得一手好程序却写不出好中文，你需要程序经理。如果你曾抱怨产品方向不明确，你需要程序经理。

你要如何雇到一个程序经理呢？

大部份公司甚至没有程序经理的概念。我觉得这实在是太糟糕了。当我在微软工作时，公司內程序经理很强的团队都有非常成功的产品(比如Excel，Windows 95，Access)。不过其他团队(如MSN 1.0和Windows NT 1.0)则的领导人通常忽视程序经理角色(这些程序经理反正也不是很优秀，或许本来就该被忽视)，而他们的产品就没那么成功了。

下面列出必须避免的三件事。

1。不要把程序员升为程序经理。良好程序经理所需的技能(撰写清楚的中文，外交手腕，对市场的察觉，对使用者的认同以及良好的使用介面设计)几乎都不是良好程序员所需的。当然有人两者都行，不过少之又少。为了奖励好程序员而把他升到不同的职位(一个改去写中文而非C++的位子)，这是个Peter Principle的典型例子：人们通常会被擢升到他们无法胜任的阶层。

2。别让行销人员当程序经理。这没有不敬的意思，不过我认为我的读者应该会同意，好的行销人员很少能好好掌握产品设计的技术性问题。

程序管理基本上是完全不同的职业生涯。程序经理一定都是很技术性的，不过却不必是个好的程序人员。程序经理会研究使用介面接触客户并且撰写规格。他们必须与各式各样的人为伍，由「白痴」客户到穿著星舰制服上班，孤癖又惹人厌的程序员，还有身穿2000美元套装大摆架子的销售人员。就某方面而言，程序经理相当于软件团队的黏着剂。所以领导魅力非常重要。

3。别让程序人员对程序经理报告。这是很微妙的错误。我在微软当程序经理时设计了Excel的Visual Basic(VBA)策略，并且订出涵盖最微小细节的完整规格，详细敘述应该如何在Excel里实现VBA。我的规格大约有500页。在Excel 5.0开发的巅峰时期，我估计每天早上有250人来上班，主要任务就是要实现我写的这份庞大规格。我完全不知道这些人是谁，不过Visual Basic组就有十几个人光是在写这玩意的文件(更不用提写Excel的文件或是全职负责说明档內超连结的人了)。不过最夸张的是我位在这层层结构的「底层」。没错。没有人要向我报告。如果想让大家去做某件事，我必须说服他们这件事该做。当主开发师Ben Waldman不想做我规格定义的某个项目，他跳过不做就好了。当测试人员报怨规格中某个项目不可能做完整的测试，我就得去把这个项目简化。如果这些人得向我报告，产品可能不会这么好。因为有些人可能会认为对上司放马后炮不太好。另外我也可能坚持己见，独断短视地命令他们照我的方式进行。这样做的话就不可能有机会建立共识。而凝聚共识的决策型式却是做对事的最好方法。

规格系列的最后一篇要讨论如何写出大家想看的优质规格。

这些网页的內容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved。