主题：【文摘】微软公司的产品生产管理经验 -- 懒厨

优秀的产品与“松弛”的管理

　　微软公司如何去做一个软件产品呢？

　　产品，最初来自一个大家认同的好主意

　　就D在瑞特蒙得园区数年来的经验而言，对一位高级软件设计师来说，任何一个研发新产品的设想与建议都是受公司鼓励的，哪怕一时还没有用。如果你又能纠集几位与你差不多的同事认同你的设想，同时也能在公司整个市场战略中找到你设想产品的位置的话，你拿到预算经费的可能性已经很大了。

　　一个好主意当然也要来自群众。因此，在早期的微软，每隔一段时间，便会将小组内全体人马集中到“与世隔绝”的风景名胜之地。好吃，好喝，好玩，然后便“胡思乱想，畅所欲言”。每个人都要求到台上来畅想一番，你心中的产品应该是个何等模样？其目的无非是一个：集思广益。好主意，当然是“宁肯错抓一千，不可放过一个”，有过此种经验的微软人都会对这种极认真的“玩”记忆犹新。

　　一个好的产品，起始于一个好的Spec

　　光有一个好主意不足以使你心目中的产品形象化，更不能组织生产。虽然有几个同事认同了你的主意，但你还必须把你的产品是什么东西，向方方面面交待清楚。也就是说，你要开始做你的Spec。

　　Spec是英文Specification（软件详细加工说明书）的缩写字头，行内人已习惯只说这前四个字母。反正，越简单越好。

　　一个完善的Spec是美国任何一个大型软件项目最为重要的一步。这在美国软件业同行中恐怕也是全民共识。就如同你要造一辆汽车，总要先把一张张蓝图一丝不苟地画清楚。不过，也有相当一部分软件工程师在动手做自己想做的软件项目时，并不真的从写Spec开始。比如D吧，直到加入微软前，都没写过Spec。那时候，D所编写的大多是功能单一的程序。一般是搞明白了每一个程序的输入输出要求，便动手干起来再说。边写边改，十分灵活。一个程序跑通了，结果出来了，也就大功告成了。今天，就算在美国大学里或某些科研机构中，许多人也还是这样做。但程序一大，或者作为一个工业产品，这种干起来再说的办法显然不行了。

　　实际上，做软件又不同于造汽车。汽车必须一辆一辆地造。软件却只要做一套，如果想批量生产，压拷贝就可以了。有过十几年的软件生涯，在微软又浸泡过几年之后，D倒是觉得，做一项软件工程可能更像拍一部电影。而Spec则更像是拍电影用的剧本，一剧之本。

　　到东京去出差，D曾有机会读过日本人为某个软件项目写的Spec。在这一套Spec中，对该软件产品应该包含的一切，事无巨细，一一定义罗列。计划中的每一个文件与函数都用自己定义的伪语言（一种接近自然语言的算法语言）写出来了。翻着翻着，D便想，虽然按这本Spec来写程序的程序员，理论上只需将函数中一行行伪码，用写程序时的真实电脑语言置换一下就可以了。但是，其一，程序员一定少不了那种被牵着牛鼻子走的无可奈何的感觉；其二，编写这样一本详细的Spec，几乎相当于用伪码将这个软件写了一遍。这样做，不是将直接写软件会遇到的问题转移到写Spec中来了吗？效率高吗？这个Spec肯定要用极大的努力去写。日本人的确是在拿做汽车的精神在做软件。日本人有他们的道理与风格。

　　但在D看来，一个好的电影剧本,有一个故事，有一系列人物和一系列故事发生与展开的时间地点等场景。但在电影的拍摄过程中，从一部电影文学剧本到一部电影，又给导演、演员、摄影、音乐服装等留下了许多发挥的余地与创造的空间。

　　就像一个好的剧本一样，软件的Spec也是从一系列Features（功能，特色）开始的。Feature这个字应该是指，软件包括哪些功能与特征、软件将要做哪些事情、事情与事情之间的关系、事情与软件用户间的关系。功能多少有点像剧本中的故事与人物。

　　有了功能的准确定义与描述，接着要设计用户如何使用这些功能。即，你的软件会涉及哪些输入输出设备，比如鼠标、键盘、电脑屏幕与打印机。这就又涉及到，软件产品的各种功能在这些设备上的所有可能的表现形式，在软件业内习惯称为界面①。也就是说，软件用户为了使用这些功能，与这些功能交流对话时用的界面。界面的设计，关系到软件产品是否方便使用，是否通情达理，善解人意。界面反映了你的软件是否具备某种人性。打开PC的电源，你在电脑屏幕上看到的一个又一个画面，就是Windows最开始的界面。从一个电影剧本的角度看，界面多少有点类似故事与人物活动时的场景。

　　过去的20年，年复一年，电脑的界面发生着巨大的变化！在20世纪70年代初，电脑的输入手段只限于拨盘开关、穿孔卡片与纸带，最豪华的装备也不过是台电传打字机罢了。输出设备只有一台宽行打印机或者绘图仪。电脑的CRT终端还只能算大型机上尚未普及的奢侈品。因而，“界面设计”从来都没有成为一个软件设计中的主要问题。那时开发人员主要的注意力都在算法上，他们要考虑如何用小得可怜的机器内存与慢得让人焦急的CPU来完成计划中的工作。80年代，图形屏幕终端开始普及，界面设计提上了日程。一门新的学科，软件心理学也随之诞生。今天，在已走进千家万户，甚至人们衣服口袋中的各种电脑中，商业软件的界面已变成了软件设计中举足轻重的一个部分。

　　功能与界面设计这两个过程，并不一定需要电脑编程人员介入，就如同写剧本并不一定要有导演和演员参与一样。功能与界面设计，甚至无须电脑专业的人员介入，但设计人员要对该软件所应用的领域有充分的了解，对该领域如何使用电脑要有充分的想象力与创意。设计人员还须对市场上已有相关产品胸中有数，并找准自己的设计在市场上的位置，扬长避短。这其中也应包括了对正在设计的软件与其他市场上同类软件是否“兼容”的一系列技术上与商业上的考虑。公司大到如微软，设计人员还需要具备一定的人际交流与协调能力，使自己的设计得到市场上大部分同业厂商中潜在的同盟军与合作者认同的能力。

　　功能与界面的设计完成之后，才是Coding设计开始之时

　　完成了上述过程，接下来的设计工作要交给软件工程师来做了。这有点像电影开拍前还需要准确的分镜头剧本一样。工程师们现在要设计和制定一个技术规则了。这个技术规则包括，采用哪些软件技术，用什么样的软件工具语言，在一个什么样的环境与平台上，如何将整个项目分割为一块块的子任务，详细的子任务清单等等细节。这个过程当然也要强调想象力与创造性，但更重要的是技术上的可行性，子任务间相互配合与协调的高效率，以及完成整个功能与界面设计的准确与无误。

　　一方面，照这样做出来的Spec，对每一个子任务如何完成并未给出更详细的约束。另一方面，所有的界面，与产品应该包含的功能，都通过演示程序在电脑上实时演示过了。设计中的问题，也通过这些演示看得清清楚楚了。在你的产品设计真正定稿之前，以上过程会反复几次。这是公司里产品研制过程中最民主的阶段。全体人员“没大没小”，“横挑鼻子竖挑眼”，畅所欲言，直到大部分同仁认可为止。

　　以上步骤，是D在微软公司工作时，完成一个软件工程Spec的过程（如果更详细的话，就要变成专题论文了）。到此为止，产品已经是看得见摸得着的东西了。这样，一个Spec可以成文，人手一份了。

　　有了一个Spec，目标已经很明确了。接下来就是一张抵达目标的时间表，从整个大组，直到每个工程师都要遵循。这张表，大家习惯称为“Milestone”，也就是公路边那一块块标志着离下一站还有多少公里数的小石碑。这张表，以及将其分解到的每一个小组与个人，（针对个人，又可称做每人的日程表（Schedule））虽然这主要是大小头目的任务，但如果工程师自己兴趣的话仍有足够的权力参与。值得指出的是，如果已经有了一个全组反复参与下做出的Spec，那么这个时间表的产生，也就很清晰明了，并无太大困难的工作了。但时间表一经确立，就变成约束你自己的纪律了。再说一遍，这是微软公司内最重要的纪律！

　　目标有了，路线有了，走完每一站的时间也有了，就该轮到一个个自命不凡的研发工程师们上阵了。在一个个的Milestone之间，微软风格的Spec，是留下了足够的余地给他们在编程过程中去“八仙过海，各显神通”。

　　有了网络，研发管理变得十分“松弛”

　　瑞特蒙得园区内，研发队伍的管理其实是非常松弛的。除了极少数临时工（Contractor），每位员工单独拥有自己一间十余平米的办公室，均有一套价值千元、高低任意调节、按人体功能设计的工作台与工作椅。书架、文件柜、白板、至少两套PC，这些都是标准配置。许多人喜欢在自己的房间里贴满各自心爱的照片、卡通，摆放或悬挂花草、盆栽、风铃……。将沙发床、健身器、音响设备搬进房间的也不在少数。

　　看到别人有趣，D也将70年代戴着领章帽徽的解放军军人半身标准照放得老大，端挂在墙上。照片之下再标上一行大字：中国军人占领了美国（Chinese Soldier Takes Over USA）！

　　除不考勤上下班时间之外，公司还从早10点到下午2点，每一小时一趟的班车，在园区内与园区边设备豪华的健身俱乐部间穿梭。公司支付一切费用，员工可游泳，或网球……，活动筋骨，锻炼身体；一年四季，或小组，或大组，或整个公司，三日一小宴，五日一大宴。美食美酒，Party不断；新上档的电影、热门棒球赛、NBA篮球赛、橄榄球大赛、歌星演唱会，……，公司赠票给员工全家，请你务必赏光。一年三百六十五天，公司开满了各式各样的进修课程，鼓励诸位踊跃参加。如诸位能大体上不影响日常工作，而学校又肯收你，读博士、读硕士，公司均乐于为你支付学费。听起来真是神仙过的日子。

　　其实也不只是“听起来”。头一回参加全公司每年一次的Party，D还真的小有震撼。在西雅图湖东区的一个大农场，幸亏有这么大一块地方容得下这么多人和车。那时公司还只有7000人，但7000辆车密密麻麻地排在一起就已经是很大一片了。那一天，几英里之外，便站满了值勤的警察。一辆辆贴着微软特别通行证的车辆，打扮如嘉年华会。方圆数百英亩的会场上早已搭起了一座座各色帐篷，摆满中国的春卷、日本的生鱼片、比利时的巧克力、美国的烤牛排、老俄的鱼子酱……，几乎全球的各色食品应有尽有。所有人，一律免费自助。不怕你肚子大，就怕你吃不下。所有饮料，包括低度数酒，当然也是无限制供应。各种各样的音乐，混杂着烧烤的焦香在农场上空飘荡。加拿大国家马术队在做着精彩的跳跃。一架架飞机拖着彩带在天上盘旋，一朵朵花伞从天而降直落靶心。这是前来助兴的奥林匹克跳伞队。今天还有吗？五万人了，一天又要吃掉多少吨美食呢？D还真有点怀念这让微软人自豪的华宴。

　　不过，公司终究不是疗养院。公司更不可能养“大爷”。任务已经明确了。Spec已交到你手中，Milestone已清清楚楚。好酒好饭无非是让你上阵时精力充沛、生龙活虎罢了。就如同那第一流的奶牛场，请你听音乐，给你做按摩，为的是请你多出牛奶。

　　既然公司已待诸位如上宾，吃饱喝足之后，就轮到把诸位的“牵出来溜一溜”了。公司也必须对诸位一举一动了如指掌，方不为过。因此，每天，诸位从使用Card Key（身份证兼开门的电子钥匙）进入办公大楼开始，你打过的每一个电话，你每一次访问源码库和数据库（作为可选项，你在办公室内电脑上每敲下的一个键），其时间、地点都记录在案。如有必要，均可查询。

　　一般而言，在你决定要结束一天工作离开办公室之前，应给小组的每一位同事发一个日报告（Daily Report），有事则长，无事则短。这样，同事们相互间知道你今天有哪些值得骄傲的进展，发现了什么问题，有什么需要求助？再加上周报告与月报告，这是不可偷懒的“琐事”。各级头目基本上靠这些电子邮件来了解和掌握工程的进展。（聪明如中国人，便有人也有这个本事，一天便干完预计三天的工作，然后写上三份Daily Report定时发出，乐得赚来两天假期。多好的管理都有漏洞，但这是以你完成任务为前提的。当头儿的知道不知道也都睁一眼闭一眼了。）

　　如果有必要，每天三五成群、共进午餐通常是大家一个非正式讨论工作的时候。此外，除非公司有活动，小组通常每周仅有一次例会，探讨那些E-mail中不容易说清楚和解决的问题。

　　公司内部不仅是省掉了许多会议，员工所有的公司布告与通知、出差购票与报销、领取杂物、查找资料、借阅图书，微软公司的网络将这些都包办了。行政后勤人员在前方第一线无事可做了。因此，比如D的部门，除一位为全体人员服务的秘书外，百分之百，包括总经理在内，全部是为第一线干活的工程师。

　　一张企业网（Intranet），将一个个不考勤、不开会、整年嚼着口香糖的“美国大兵”，紧紧地网在一起，成为一支协调一致的队伍。也使得拼杀在第一线的队伍，将自己的行政与后勤，统统甩给了公司内的少数直属部门。微软创造了在美国也是极高的前后方人数比。网络，用盖茨先生的话讲，是公司的神经系统！

　　产品的按时完成，源于雷打不动的 Milestone

　　“Deliver，Deliver And Deliver”，这句话的中文意思是说：一是按时出货，二是按时出货，三还是按时出货。这是在微软瑞特蒙得园区工作的，任何一个研发队伍的大小头目，都要牢记在心的最重要的一句话。相信这也是美国任何一间软件公司都要追求的一个目标。虽然每一个大的软件项目，比如在微软，从Windows 95到Windows XP，几乎每一次都比预计的时间延后投放市场，虽然理想与实际总是有一段距离，但理想总是要追求的。相对而言，对完成Windows这类规模已达几百兆字节、又要涵盖数以万计PC硬件厂家的底层系统软件，微软还是做得相当出色的。

　　员工各自的Milestone，是从每位工程师到大小头目最重要、也最醒目的目标。花香鸟语的微软园区里，前面讲了那么多事，都可以请随尊便，都是为了在诸位的Milestone上，容不得半点含糊。Milestone，可以说是微软公司软件产品项目管理中的核心。坦率地讲，90年代初，直到D离开岗位（以后，就不便妄言了），微软的进度管理是相当苛刻的。新老员工一视同仁，并不会因为你是新加入的员工给你更多的学习时间。在一群自命不凡的聪明人中，别人可以完成，你却不能，这种压力是可想而知的。在那个年头，无论几点钟走进微软园区，停车场上永远停着一片片的车辆。加班加点是普遍的事情。所以，不考勤的好处就是不必付加班费。将沙发床搬进办公室，连跑回家睡觉的时间都省了。无怪乎，法官大人对垄断案的判词中要指责微软每周平均60小时的工作时间。

　　除了朋友间的相互帮助，政治思想工作外，那是心理医生或者教会分管的职责，不在公司的议程之内。除了电子邮件中乃至会议上就事论事的争论外，美式的日常管理中较少听得到对哪位员工正式的批评意见。会议上听到的大多是“你好我好他也好”的正面鼓励。打工的诸位要想发现与自己相关的问题，就看听话的诸位，能否敏感地直觉到，你好我好中的奥妙与异同。

　　如果老弟真的糊里糊涂，完不成任务，而又自我感觉良好，那么，一年两次的评审（review）就是毫不含糊地与你清账的时候了：你自己给出一番自我鉴定，你的顶头上司也会给你一个鉴定，一项一项为你打出一个分数来。这次不再会是“你好我好他也好”，这关系到你这半年的奖金、股票、工资乃至你是否还干得下去。因为这也关系到你上司，他的奖金、股票、工资乃至他是否还干得下去。

　　坦率地讲，无论公司为你准备了多么优秀的工作条件，提供了多好的福利待遇，努力为你营造一个松弛的环境，早期员工所承受的压力也是无须掩饰的事实。压力就是来自不太容易“泛竽”的Team Job和雷打不动的Milestone。

　　在D的微软岁月中，D未解雇过自己的员工，也未见过开除员工的现象。但用不着多久，完不成任务的员工大多选择自动辞职。以下随便捡出几个实例：

　　1992年，D曾从加州硅谷聘请了一位已有5年软件工作经验的台湾同胞加盟D的部门。但上班仅一周，这位同胞便跑来向D辞职。他抱怨，他无法承受这种不给切入时间便得立即上阵的压力。他没有信心按时完成任务，这与他过去5年的经验不相符合。三十六计，走为上。

　　1993年，Visual Basic 未能按时出货，该部门从上到下正职领导全部辞职。

　　1995年，一位毕业于中国名校，加入微软前又曾在北京某一知名软件企业工作过数年的北京老乡，跑来向D投诉：他在自己工作部门内受到洋鬼子无法忍受的不公正待遇，希望D利用自己的位置给予申诉与帮助。D费尽了力气，才发现，这位自视甚高的老弟实在是忍受不了 Milestone的压力，精神开始变得恍惚了。虽然D为此事，求助了许多公司中包括其他中国人在内的同事，也包括今天任微软（中国）公司总经理的唐俊能否为他更换一个压力相对轻微些的位置，均未能解决他的问题。公司毕竟是公司，何况众矢之的微软公司。

　　1996年，D深感自己三板斧已经耍尽，“宝刀”已老，已无法胜任微软公司高级软件设计师的重压，乘着公司尚未讨厌自己之时，向盖茨先生递出辞呈，飘然而去，实也一例。虽然形式不同，其本质一样。

　　……

　　对员工的充实与培训是公司的责任。但在美国，照顾弱者通常是社会与各级政府的任务。在战场上，冲不上去的士兵，无论在哪个军队里日子都不好过。

　　细致的源码管理，与严格的质量控制

　　Milestone与按时出货，关系着每位员工在公司内的“生死存亡”。但还有更重要的，关系着公司自己的生死存亡，那就是产品的质量！

　　在美国，不仅是微软，任何一间真正的公司，在他们的“多快好省”总路线中，“好”字永远是摆在首位的。有人说，老美有钱，可以把钱往里砸。但也有人说，这其实更是一种文化。看看上海外滩上那一排排百年沧桑的花岗石大厦，的确是一种文化。再看看北京故宫那金碧辉煌的建筑群，那是更古老的文化。无论各路专家如何诠释这些文化，这里都包含着一件共同的组成部分，让人叹服的质量。

　　微软研发产品，的确不吝惜金钱。他已花了足够的人力物力去做市场的调查，去琢磨产品的Features（功能、特色），去反复完善产品的设计。在程序员开始动手Coding（编写程序）之后，公司还要组织几乎和研发人员人数1：1的测试人员反复测试设计中所有的功能。这是一支千万人的庞大的队伍（如果算上微软外承担了贝塔测试的数千家公司，人数将多达几十万人）。从产品的第一次合成（Build）开始，到阿尔发（α）出货，到β出货，直到投放市场前最后一分钟（已经是数千次合成过了），这支队伍数年如一日，一直都在做着永不停歇的质量测试，不停地寻找一个又一个各式各样的问题。即使是这样，由于一个大型软件的特殊性，它的所有功能间排列组合所产生的近天文数字的不同情况还是难以完全覆盖。这也是为什么每次微软的Windows产品投放市场之后，仍能发现其中某些问题的原因。庆幸的是，至今为止，尚未发现过严重的弊病。试想，几千万份软件在上亿台PC上运转，如果也像某些公司的某些做法，将大部分测试交由市场去完成，这样大规模的产品，待到问题“百花齐放”，那垮台的就不仅是微软，一时间，会为全球的PC业造成难以估计的灾难。

　　人们常说，股票价值数千亿美元的微软公司，除了几千个聪明的脑袋就没有什么了（园区虽然漂亮，那几幢楼可值不了这些钱）。脑袋值多少钱，多少有点虚。从这些脑袋里写出的一串串源码才是微软看得见的财产。

　　微软公司当然有一整套严格的制度与措施。在这套措施的管理之下，你写的每一行码，都会保存得十分妥当和有序。每个程序员的源码都会、也必须定期存档（Check In），这是你创造的财富，也是你的工作纪录。无论什么原因毁坏了你的硬盘，或损毁了某个文件，你自己再也无法挽救时，打个电话，就会有人在一个新硬盘上恢复你昨天下班前所做过的一切。

　　就D的部门而言，事前对每位程序员的源码风格不做硬性规定。但每一阶段，小组都会对全组的源码做一次统一的整理（Code Review）。签上各自的姓名，补上必要的说明，并使全组程序简明、易读，书写风格大体一致。一套仔细有序的源码保存与查询体制，不仅仅是质量控制的必要保证（大大加速发现和修改错误的过程），也同时保障了产品的连续性。一个公司才有可能，“走了张屠户，不吃混毛猪”，才能应上那句话，“铁打的营盘，流水的兵”。

　　源码还必须有一套无懈可击的保护系统。源码在软件公司，犹如钞票在银行。Windows NT 4.0中文投放市场前夕，北京某个著名电脑公司向微软派来了四位得力干将，作为OEM代表，在微软提供的园区内办公室，由微软协助共同解决该公司预装NT4.0有可能出现的硬件兼容性等技术问题。四位老弟，刚一上班，网上一转，大概是颇有发现，立刻将余事扔到一边，找来软盘，捡其所好，先下载再说。未料到，文件尚未拷完，公司保安人员已站在了办公室门口。幸亏该北京公司反应及时，立即将四人调回中国，息事宁人，未酿成不必要的风波。

　　1994年，D陪同盖茨先生访问北京。访问中，有人当面指出：微软公司的软件价格太高，不符中国国情。盖茨先生回答：既然中国能够接受收彩色电视的价格，为什么不能接受电脑软件的价格呢？

　　软件靠进口，当然越便宜越好。软件若能出口，那可能就是另一种考虑了。

①如果分得更细致一点，界面应包括电脑总线面对外部设备的界面与电脑整体面对用户的界面。这里强调的是面对用户的各种界面，泛称用户界面，User Interface，简称UI。而电脑总线与外部设备之间的界面，将由电脑工程师处理，不是此处论述的重

微软产品的Bug实在是多，和Java类产品相比尤其明显。

如果说和UNIX类不好比（UNIX存在很多年了，磨合期已经过了），那么和比自己年轻的Java比比总可以吧。

Sun Java App Server Ent，别的不说，竟然连它自己的sample都不work。一deploy就出错。

Sun Java我只用它的J2SE和J2EE类库，其它的根本不碰，产品类则是Weblogic和Websphere。

我在这个倒霉项目以前还没用过sun，看看网上的几个评价，好像还行。另外，一想，这java好歹还算是sun亲生的，自己的孩子难道还是别人清楚？没想到，还真是这样。

象Windows 2000 XP等，.Net 也不错的。

唉，靠微软吃饭，就帮他说句好话吧

NetBeans，Sun自己的开发工具和应用服务器都不怎么样，功能不行，开销却很大。