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

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

现在你已经读过[为什么要规格](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6%A0 %BC(%E4%B8%80) “The Joel on Software Translation Project:无痛功能规格(一)")和[规格里有什么](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD% E8%A6%8F%E6%A0%BC(%E4%BA%8C) “The Joel on Software Translation Project:无痛功能规格(二)")，可以来谈谈什么人该写规格。

谁在写规格？

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

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

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

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

哎呀，Simonyi可能精通匈牙利表示法，不过他不懂[Peopleware](http://www.amazon.com/exec/ obidos/ASIN/0932633439/ref=nosim/joelonsoftware/)。没有人会想当写程式奴隶的。这种系统根本行不通。最后微软发现，尽管有着所谓人月神话(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不想做我规格定义的某个项目，他跳过不做就好了。当测试人员报怨规格中某个项目不可能做完整的测试，我就得去把这个项目简化。 如果这些人得向我报告，产品可能不会这么好。 因为有些人可能会认为对上司放马后炮不太好。另外我也可能坚持己见，独断短视地_命令_ 他们照我的方式进行。这样做的话就不可能有机会建立共识。而凝聚共识的决策型式却是_做对事_ 的最好方法。

规格系列的[最后一篇](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6%A0%BC (%E5%9B%9B) “The Joel on Software Translation Project:无痛功能规格(四)")要讨论如何写出大家想看的优质规格。

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

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