JoelOnSoftware

Joel on Software

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

无痛功能规范 – 第三部分:不过…怎样做呢?

by Joel Spolsky Wednesday, October 04, 2000


Now that you've read all about why you need a spec and what a spec has in it, let's talk about who should write them.

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

Who writes specs?

谁写规范。

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

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

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

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

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

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

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

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

Well, Simonyi may know Hungarian Notation, 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 still add smart people to a team and get increased output, although at decreasing marginal values. The Excel team had 50 programmers when I was there, and it was marginally more productive than a team of 25 would have been -- but not twiceas productive.

恩,Simonyi也许知道如何用匈牙利符号命名规范,但他不知道人件的概念。没有人想要成为码奴。这种体系根本没有可能行得通。实际上,微软发现虽然有所谓的人月神话,但你还是可以把聪明人加入到团队里获得项目增长的输出,当然边际效值却递减了。当我还在微软的时候,Excel团队有50个程序员,边际上来讲是比25个人的团队更加有效率的, 应该是 –- 但不是两倍那么有效率。

The idea of master/slave programming was discredited, but Microsoft still had these people called program managers bouncing around. A smart man named Jabe Blumenthal basically reinvented the position of program manager. Henceforth, the program manager would own thedesign and the spec for products.

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

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

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

Program managers are invaluable. If you've ever complained about how programmers are more concerned with technical elegance than with marketability, you need a program manager. If you've ever complained about how people who can write good code never do a good job of writing good English, you need a program manager. If you've ever complained about how your product seems to drift without any clear direction, you need a program manager.

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

How do you hire a program manager?

怎样招聘程序经理?

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

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

Here are three things to avoid.

三件事性应该避免。

  • Don't promote a coder to be a program manager. The skills for being a good program manager (writing clear English, diplomacy, market awareness, user empathy, 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 by promoting them to a different position, one that involves writing English, not C++, is a classic case of the Peter Principle: people tend to be promoted to their level of incompetence.
  • 不要把程序员晋升成程序经理。 当好程序经理需要的技能(清晰的英语写作,沟通能力,销售意识,深入用户,好的界面设计)通常不会是好的程序员的技能。 当然有的人两样都能做,但是这很少见。奖励好的程序员但把他们提升到不同的职位上,这个职位要求的是好的英语写作水平而不是C++编写水平,这种情况是典型的Perter原则:人们倾向于被提升到他们不擅长的水平。
  • Don't let the marketing people be program managers. No offense, but I think my readers will agree that good marketing people rarely have a good enough grasp of the technology issues to design products.
  • 不要让销售人员担任程序经理。无意冒犯,但我觉得读者们都会同意好的销售人员几乎不可能足够了解技术问题来设计产品。
  • Basically, program management is a separate career path. All program managers need to be very technical, but they don't have to be good coders. Program managers study UI, meet customers, and write specs. They need to get along with a wide variety of people -- from "moron" customers, to irritating hermit programmers who come to work in Star Trek uniforms, to pompous sales guys in $2000 suits. In some ways, program managers are the glue of software teams. Charisma is crucial.
  • 基本上,项目管理是个完全不同的职业发展。所有的程序经理都必须是非常技术类型的,但他们不需要成为很好的程序员。程序经理研究UI,拜会顾客并且编写规范。他们需要和各种各样的人搞好关系 -- 从“白痴”客户,到穿着星际迷航制服来上班的烦人的隐士程序员,到自大的穿着2000美金西装的销售人员。 在某种程度上程序经理是软件团队的胶水。魅力是至关重要的。
  • Don't have coders report to the program manager. This is a subtle mistake. As a program manager at Microsoft, I designed 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 to about 500 pages. At the height of development for Excel 5.0, I estimated that every morning, 250 people came to work and basically worked off of that huge spec I wrote. I had no idea who all these people were, but there were about a dozen people on the Visual Basic team alone just writing documentation for this 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 do something, I had to convince them that it was the right thing to do. When Ben Waldman, the lead developer, didn't want to do something I had speced out, he just didn't do it. When the testers complained that something I had speced was impossible to test completely, I had to simplify it. If any of these people had reported to me, the product wouldn't have been as good. Some of 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 them to do it my way, out of conceit or nearsightedness. As it was, I had no choice but to build consensus. This form of decision making was the best way to get the right thingdone.
  • 不要让程序员汇报给程序经理。 这是个细微的错误。作为微软的程序经理, 我设计了Excel VisualBasic(VBA)策略,完整的规范了所有最小细节,VBA在Excel里应该如何实现。 我的规范大概有500多页。 在Excel5.0开发的时候,我预计每天早上,250个人来上班,都在实现那个大规范里的东西。 我完全不知道这些人是谁,不过光VisualBasic团队就有几十个人在负责为这个东西文档(更不要说为Excel那边写文档的团队了,或者是负责为帮助文件创建超链接的那些人了)奇怪的是,我处于汇报链的底端。这是对的。没人汇报给我。如果我想要人们做点儿什么,我必须说服他们这是正确的要做的事情。当开发领导Ben Waldman不想要做我规范里的东西的时候,他就不做;当测试人员抱怨说我规范里的东西无法完整测试的时候,我就要去简化它。如果这些人汇报给我,产品就不会像现在这样好用。 他们中的某些人认为不应该猜测上级。其他时候,实际上是的,处于短见和虚荣,我就会把腿放下命令他们以我的方式来做。 这种形式的决策过程是正确地做好事情的最佳方式。

The final article in my series on specs talks about how to write good specs that people want to read.

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