# 七、轻松写就功能规格说明书 - 第3节：但是……如何？ 现在你已经读过为什么要规格和规格里有什么，可以来谈谈什么人该写规格. 谁在写规格？ 请容我在此提一点微软的历史.1980年代当微软开始快速成长时，那里每个人都 读过The Mythical Man-Month这本软件管理经典(如果你还没读过这本书，我可 是极度推荐）.这本书的主要重点是说，在进度落后的项目中增加更多程序员， 只会让进度更加落后.这是因为当团体中有n个程序员时，沟通路径的数量会变 成n(n-1)/2,也就是以0(n2)增加. 既然当时众所周知增加程序人员只会让事情更糟，所以微软的程序人员都在思 考要如何撰写更大的程序. 担任微软〃主设计师〃多年的Charles Simonyi提出了主程序员的概念.这个点子 基本上是让一个主程序员负责撰写所有程序，不过他或她底下有整组充当〃程序 奴隶”的菜鸟程序员.主程序员不必费心替每个函数除错，而是定出各个函数的 原型，建立基本结构再丢给菜鸟程序员实作（理所当然的，Simonyi会是最大的 主程序员）.主程序员这字眼有点古老，所以微软用的词是〃程序经理(Program Manager)”. 理论上这应该能解决Mythical Man-Month的问题，因为大家不需要互相沟通(各 个菜鸟程序员都只和程序经理沟通），所以沟通路径是以O(n)而非O(n2)成长. 哎呀，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不想 做我规格定义的某个项目，他跳过不做就好了.当测试人员报怨规格中某个项 目不可能做完整的测试，我就得去把这个项目简化.如果这些人得向我报告， 产品可能不会这么好.因为有些人可能会认为对上司放马后炮不太好.另外我也 可能坚持己见，独断短视地命令他们照我的方式进行.这样做的话就不可能有 机会建立共识.而凝聚共识的决策型式却是做对事的最好方法.