[翻译Joel On Software]无痛功能规范 – 第三部分：不过…如何去做？/Painless Functional Specifications - Part 3: But... How?

Joel on Software

Painless Functional Specifications - Part 3: But... How?

无痛功能规范 – 第三部分：不过…如何去做？

by Joel Spolsky Wednesday, October 04, 2000

Now that you'veread all about why you need aspec and what a spechas in it, let's talk about who should write them.

既然你已经了解了为什么你需要规范和规范包含了那些部分，让我们聊聊谁应该写规范。

Who writesspecs?

谁应该写规范。

Let me give you alittle Microsoft history here. When Microsoft started growing seriously in the1980s, everybody there had read TheMythical Man-Month, one of the classics of software management. (If youhaven't read it, I highly recommend it.) The main point of that book was thatwhen you add more programmers to a late project, it gets even later. That'sbecause when you have n programmers on a team, the number ofcommunication paths is n(n-1)/2, which grows at O(n²).

让我先给你讲一点微软的历史。严格来说，20世纪80年代的微软开始增长的时候，每个人都读过 人月神话 ，软件管理的经典之一。（如果你没读过，我极度推荐你去读读。）那本书的主要观点是当你往一个延迟的项目加派程序员的时候，项目会延迟的更多。 因为当你的团队里有n个程序员的时候，沟通路径为n(n-1)/2，以O(n²)渐进速度增长。

So theprogrammers at Microsoft were worried about how to write bigger and biggerprograms, when the prevailing wisdom of the day was that adding programmersjust makes things worse.

因此微软的程序员担心如何来编写越来越大的程序，因为那个时候盛行的观点认为往项目加派程序员只会把事情变得更糟。

Charles Simonyi,Microsoft's long time "chief architect", suggested the conceptof master programmers. The idea was basically that one masterprogrammer would be responsible for writing all the code, but he or she wouldrely on a team of junior programmers as "code slaves". Instead ofworrying about debugging every function, the master programmer would basicallyjust prototype each function, creating the bare outline, and then throw it toone of the junior programmers to implement.  (Of course, Simonyi would bethe Master Master Programmer.) The term "Master Programmer" was a bittoo medieval, so Microsoft went with "Program Manager."

Charles Simonyi，微软长久以来的“首席架构师”，提出了称为“主程序员”的概念。主要观点是：一个主程序员负责所有代码的编写，但是他或她可以依赖一个团队的初级程序员-“码奴”。主程序员基本上应该给出每个程序的原型，仅创建大致的轮廓，然后把它扔给初级的程序员去实现而不是担心去调试每一个函数。（当然，Charles Simonyi自己是主程序员。）“主程序员”的这种概念太中世纪了，所以微软使用了“程序经理”这一称谓。

Theoretically,this was supposed to solve the Mythical Man-Month problem, because nobody hasto talk to anyone else -- every junior programmer only talks to the one programmanager, and so communication grows at O(n) instead of O(n²).

理论上，这应该可以解决“人月神话”问题的，因为没有人需要跟其他人交谈了—每个初级的程序员只和一个程序经理交流，因此交流以O(n)而非O(n²)渐进增长。

Well, Simonyi mayknow HungarianNotation, but he doesn't knowPeopleware.Nobody wants to be a code slave. The system didn't work at all. Eventually,Microsoft discovered that despite the alleged Mythical Man Month, you can stilladd smart people to a team and get increased output, although at decreasingmarginal values. The Excel team had 50 programmers when I was there, and it wasmarginally more productive than a team of 25 would have been -- but not twiceasproductive.

恩，Simonyi也许知道匈牙利符号表示，但他不知道人件。没有人想要成为码奴。这种体系根本无法工作。实际上，微软发现虽然有宣称的人月神话，但你还是可以把聪明人加入到团队里获得增长的家国，虽然边际效值减了。当我在的时候Excel团队有50个程序员，边际上来讲是比25个人的团队更加有效率的， 应该是 – 但不是两倍那么有效率。

The idea ofmaster/slave programming was discredited, but Microsoft still had these peoplecalled program managers bouncing around. A smart man named Jabe Blumenthalbasically reinvented the position of program manager. Henceforth, the programmanager would own thedesign and the spec forproducts.

主/从编程的概念被扫地出门了，但微软还是到处保留着这些叫做程序经理的人。一个叫做Jabe Blumenthal的聪明人基本上重新发明了这种程序经理的职位。从那以后，程序经理负责产品的功能规范和设计。

Since then,program managers at Microsoft gather requirements, figure out what the code issupposed to do, and write the specs. There are usually about 5programmers for every program manager; these programmers are responsible forimplementing in code what the program manager has implemented in the form of aspec. A program manager also needs to coordinate marketing, documentation,testing, localization, and all the other annoying details that programmersshouldn't spend time on. Finally, program managers at Microsoft are supposed tohave the "big picture" of the company in mind, while programmers arefree to concentrate on getting their bits of code exactly right.

从那以后，微软的程序经理搜集需求，搞清楚代码应该要做什么，然后编写规范。 通常一个程序经理配有5个程序员；这些程序员负责用代码实现程序经理用规范描述的功能。程序经理同时需要协调销售，文档，测试，本地化，以及其他所有程序员不应该花时间的繁琐细节。最后微软的程序经理应该脑海中有公司的“大方向”，而程序员可以自由地专注在把他们的代码写对。

Program managersare invaluable. If you've ever complained about how programmers are moreconcerned with technical elegance than with marketability, you need a programmanager. If you've ever complained about how people who can write good codenever do a good job of writing good English, you need a program manager. Ifyou've ever complained about how your product seems to drift without any cleardirection, you need a program manager.

程序经理是无价的，如果你曾经抱怨过程序员应该专注员技术优雅而不是销售，那么你需要个程序经理。如果你曾经抱怨过能够写得一手好代码的人绝不可能写出好英语文章，那么你需要个程序经理。如果你曾经抱怨过你的产品如何漂浮着找不到方向，那么你需要个程序经理。

How do you hirea program manager?

怎样招聘程序经理？

Most companiesdon't even have the concept of program manager. I think that's too bad. In mytime, the groups at Microsoft with strong program managers had very successfulproducts: Excel, Windows 95, and Access come to mind. But other groups (such asMSN 1.0 and Windows NT 1.0) were run by developers who generally ignored theprogram managers (who weren't very good anyway, and probably deserved to beignored), and their products were not as successful.

大多数公司甚至没有程序经理的概念。这太糟糕了。在我那个年代，微软有着优秀程序员的团队有着非常成功的产品：Excel，Windows95和Access浮现在脑海里。但其他的团队（例如MSN1.0和WindowsNT1.0）由通常忽视程序经理（实际上没那么好，应许应该被忽略[w1] ）的开发者运行，他们的产品就没那么成功。

Here are threethings to avoid.

三件事性应该避免。

1.      Don't promote a coder tobe a program manager.  The skills for being agood program manager (writing clear English, diplomacy, market awareness, userempathy, and good UI design) are very rarely the skills for being a good coder.Sure, some people can do both, but they are rare. Rewarding good coders bypromoting them to a different position, one that involves writingEnglish, not C++, is a classic case of the PeterPrinciple: people tend to be promoted to their level of incompetence.

2.     不要把程序员提升成程序经理。 当好程序经理需要的技能（清晰的英语写作，沟通能力，销售意识，深入用户，好的界面设计）通常不会是好的程序员的技能。 当然有的人两样都能做，但是这很少见。奖励好的程序员但把他们提升到不同的职位上，这个职位要求的是好的英语写作水平而不是C++编写水平，这种情况是典型的Perter原则：人们倾向于被提升到他们不擅长的水平。

3.     Don't let the marketingpeople be program managers. No offense, but Ithink my readers will agree that good marketing people rarely have a goodenough grasp of the technology issues to design products.

4.    不要让销售人员担任程序经理。无意冒犯，但我觉得读者们都会同意好的销售人员几乎不可能足够了解技术问题来设计产品。

Basically,program management is a separate career path. All program managers need to bevery technical, but they don't have to be good coders.  Program managersstudy UI, meet customers, and write specs. They need to get alongwith a wide variety of people -- from "moron" customers, toirritating hermit programmers who come to work in Star Trek uniforms, topompous sales guys in $2000 suits. In some ways, program managers are the glueof software teams. Charisma is crucial.

基本上，项目管理是个完全不同的职业发展。所有的程序经理都必须是非常技术类型的，但他们不需要成为很好的程序员。程序经理研究UI，拜会顾客并且编写规范。他们需要和各种各样的人搞好关系 -- 从“白痴”客户，到穿着星际迷航制服来上班的烦人的隐士程序员，到自大的穿着2000美金的销售人员。 在某种程度上程序经理是软件团队的胶水。魅力是至关重要的。

3. Don't havecoders report to the program manager. This is a subtle mistake. As a program manager at Microsoft, Idesigned the Visual Basic (VBA) strategy for Excel and completely speced out,to the smallest detail, how VBA should be implemented in Excel. My spec ran toabout 500 pages. At the height of development for Excel 5.0, I estimated thatevery morning, 250 people came to work and basically worked off of that hugespec I wrote. I had no idea who all these people were, but there were about adozen people on the Visual Basic team alone just writing documentation forthis thing (not to mention the team writing documentation from the Excel side,or the full time person who was responsible for hyperlinks in the help file.)The weird thing was that I was at the "bottom" of the reporting tree.That's right.NOBODY reported to me. If I wanted people to dosomething, I had to convince them that it was the right thing to do. When BenWaldman, the lead developer, didn't want to do something I had speced out, hejust didn't do it. When the testers complained that something I had speced wasimpossible to test completely, I had to simplify it. If any of thesepeople had reported to me, the product wouldn't have been as good. Someof them would have thought that it's inappropriate to second-guess a superior.Other times, I would have just put my foot down and ordered themto do it my way, out of conceit or nearsightedness. As it was, I had no choicebut to build consensus. This form of decision making was the best way toget the right thingdone.

不要让程序员汇报给程序经理。 这是个细微的错误。作为微软的程序经理， 我设计了ExcelVisualBasic（VBA）策略，完整的规范了所有最小细节，VBA在Excel里应该如何实现。 我的规范大概有500多页。 在Excel5.0开发的时候，我预计每天早上，250个人来上班，都在实现那个大规范里的东西。 我完全不知道这些人是谁，但是仅VisualBasic团队就有几十个人在负责为这个东西文档（更不要说为Excel那边写文档的团队了，或者是负责为帮助文件创建超链接的那些人了）奇怪的是，我处于汇报层级的底端。这是对的。没人汇报给我。如果我想要人们做点儿什么，我必须说服他们这是正确的要做的事情。当开发领导Ben Waldman不想要做我规范里的东西的时候，他就没做，当测试人员抱怨说我规范里的东西无法完整测试的时候，我就要去简化它。如果这些人汇报给我，产品就不会像现在这样好。他们中的某些人认为不应该猜测上级。其他时候，实际上是的，处于短见和虚荣，我就会把腿放下命令他们以我的方式来做。 这种形式的决策制定是做好正确事情的最佳方式。

The final article inmy series on specs talks about how to write good specs that people want toread.

这一系列里的最后一篇文章讨论了如何写出人们想要读的功能规范。