# 七、轻松写就功能规格说明书 - 第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不想 做我规格定义的某个项目,他跳过不做就好了.当测试人员报怨规格中某个项 目不可能做完整的测试,我就得去把这个项目简化.如果这些人得向我报告, 产品可能不会这么好.因为有些人可能会认为对上司放马后炮不太好.另外我也 可能坚持己见,独断短视地命令他们照我的方式进行.这样做的话就不可能有 机会建立共识.而凝聚共识的决策型式却是做对事的最好方法.