文/Joel Spolsky 译/罗小平
指派一名优秀的程序经理，是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人，其实绝大多数团队都没有。
Charles Simonyi，这位曾与MarthaStewart（译者注：美国女富豪，作家）拍拖15年、WYSIWYG字处理技术发明人之一、从微软股票赚得10亿美元（译者注：CharlesSimonyi曾是微软Office产品团队的负责人）、到过太空的天才程序员，是试图解决大型软件团队遇到的“人月神话”问题之第一人。他的方法是创立一个新的岗位，由超级天才程序员担任，负责系统中最重要功能的实现，而其他次要部分则交给一个由低级程序员组成的杂牌团队。他把这个岗位命名为程序经理（program manager）。Simonyi本人是天才级的，但他的这个想法可不怎么出彩，我想没人愿意做一个被人轻视的低级程序员吧。
若需详细了解这段历史，可以阅读William Poundstone的《How Would You Move Mount Fuji?》（http://www.amazon.com/gp/product/0316778494?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=9325&creativeASIN=0316778494）。
Jabe Blumenthal，是上世纪80年代后期在MacExcel团队工作过的一名程序员。他捡起了这个头衔，但赋予了不同的含义。Blumenthal发现软件开发已经变得日益复杂，以至没有哪个程序员有时间去关心如何真正保证软件的可用性和实用性。而市场人员又在一旁大谈客户需求，抱怨没人听他们的话，没人将他们MBA式的天才想法转化为软件中可用的功能。产品设计方面不少的工作都需要花费大量时间，比如用户沟通、可用性测试、竞争对手产品的分析评估、将复杂问题化繁为简等等。但绝大多数程序员恰恰没有时间做这些事情（实际上也往往也不是他们的强项）。于是，Blumenthal重拾“程序经理”，不过完全重新定义了这个职位。
程序经理需要做什么工作？
自此以后，一名程序经理的工作包括：
- UI设计
- 编写功能规格
- 团队协调
- 充当用户代言人
- 还有，穿Banana Republic牌子的休闲Chino裤
在小项目中，你有一个程序经理就够了，但对于大型项目，很可能需配置多名，每个人负责全部功能特性的一个子集。从很多项目总结出来了一个经验法则：每四名程序员配置一个程序经理。那么如何划分功能集呢，如果你遇到困难，我向你推荐我从Mike Conte那学到的方法：根据用户活动划分产品功能（http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html）。比如：twitter.com可划分为四类用户活动：
1. 注册与登录
2. 发表帖子、阅读回复
3. 配置个人账户
4. 搜索新闻
我的第一份程序经理工作是在微软的Excel团队，负责一个叫做“用户化”的用户活动（比如编写脚本、宏）。我首先要做的事情是搞清楚用户的需求。于是我与很多用户交流，直到我长满茧子的耳朵总是只能听到相同的需求、让人厌烦为止。接下来，我要需花很多时间与开发团队沟通，弄清在18个月的新版本开发周期中，哪些需求是合理的、可以实现的。我和VisualBasic团队沟通，确定他们是否可提供编译器、代码编辑器、对话框编辑器，否则用户就不能在Excel中使用宏语言。我必须跑去与Apple沟通，他们当时正在自己搞一门叫做AppleScript的通用宏语言。此外，我还要和微软内部的其他应用团队，主要包括Word、Access、Project和Mail等打交道，因为他们也在做和Excel团队差不多的事情。这个过程的绝大部分工作，都是沟通讨论——会议、邮件、电话……几乎无休无止。我被那段生活搞怕了，直到现在，在办公室的时候还怕听到电话铃响。
第二步是写愿景规划。这是一个内容相当宽泛的文档，比如VisualBasic如何在Excel中工作，用户可能编写的宏是什么样子，需要技术团队构建哪些模块，以及它们如何解决用户的问题。然后在此基础上讨论修改，直到没有太多分歧。至此，我可以开始编写详细规格书，要描述清楚每个不可再分的细节呈现在用户面前时的样子。
这是一份功能而不是技术规格书。也就是说，它的全部内容都用于描述用户所见所为，而不是程序如何实现。若需进一步了解功能规格，请阅读http://www.joelonsoftware.com/articles/fog0000000036.html。程序经理不关心开发团队的内部实现细节。当我将这份功能规格发给开发团队的头头BenWaldman后，他和他的团队再坐下来详细讨论实现工作。最后，他们很聪明地弄出一份精悍的表格，将我定义的面向对象的接口一一映射到Excel内部功能。当然这的确不是我的事情，我对Excel内部知之甚少，也真的不知道那些需求应该怎么实现。
老实说，我那时候对什么都是一窍不通。刚从学校出来，对代码开发、程序测试、文档撰写、产品推广以及可用性测试等等，我完全没有经验。幸运的是，微软在每个岗位都有经验丰富的导师，他们教给了我迄今知道的全部知识，也是他们真正承担了这么大的产品的全部实际工作。举个我知道的例子说吧，用户可能需要在宏程序里将电子表格中单元格的值复制给一个变量：
x = [A1]
问题是单元格的值可能是数字，也可能是字符串；而Basic语言是早期绑定的，你必须首先用DIM将x定义为Integer、Float或String等确定类型，然后才能使用。
要解决这个问题，Basic必须支持某种动态类型，但我没那么聪明，想不出什么解决办法。不要紧，Visual Basic团队的程序员Tom Corbett想出来了（http://www.patentstorm.us/patents/5689709/description.html）。Variants和IDispatch由此诞生了，借助“鸭式类型识别”（ducktyping。“如果一只鸟，走起来像鸭子，叫起来像鸭子，那我们就可以管它叫鸭子。”），Basic摇身一变，成了动态语言。这个事情说明，我的工作不是自己去解决问题，而是找到用户需要解决的问题，并保证程序员找出解决这些问题的办法。
一旦功能规格完成、技术团队开始工作后，我的职责就有了变化：（1）解决设计方面出现的问题；（2）负责与所有其他团队的沟通，以便节省开发人员的时间。例如，我要向测试人员说明全部功能是如何运转的，帮助他们设计测试计划；确保文档团队明白如何为ExcelBasic编写一份高质量的教程和参考手册；和本地化专家确定本地化策略；向市场人员解释VBA在市场上的优势；和可用性专家设计可用性测试方案等。
程序经理需参加大量的会议，但其产出基本不超出规格文档这个范围，因此我一个刚毕业的无用之人也能胜任这份工作。完全没必要让一个有14年经验的资深程序员担当程序经理。实际上，有14年的开发经验，你反而可能因为知道太多，而无法扮演好用户代言人这个角色。
冲突
如果没有程序经理，聪明的程序员们在一起，可能设计出让用户难以理解的界面，也许只有Vulcan人（《Star Trek /星际迷航》中逻辑思维能力超强的外星种族）才会表示“正合吾意”。最好的程序员会聪明到不能理解用户为何不能记住16个单字母的命令行参数。这些程序员往往难以割舍他们的最初想法，尤其是已经将自己的想法变成了代码之后。
程序经理给软件设计流程带来的最大益处，是可以引入程序员之外的第二种观点。而这种观点恰恰更接近用户的想法——这些用户往往既不想阅读使用手册，更不想写什么emacs-lisp函数，至于在他们大脑里将十进制数字转化为八进制，那就更不可能了。
一个好的程序经理对于UI的工作方式有他自己的想法，和开发人员的相比，可能更好，也可能更坏，因此需要双方讨论。通常，程序经理是站在用户角度，希望凡事尽可能简单易懂，诸如有心灵感应力的用户界面、大到30″而又能放进口袋的屏幕之类；而开发人员想的是处处尽可能减少要编写的代码，支持命令行界面（他们会说“这怎么就不好用了呢？”）和Python绑定。
我记得Excel 5项目中最为经典的争论发生在一个开发人员和程序经理之间。开发人员希望数据透视表（pivottable）悬浮在电子表格的绘画层上，而程序经理坚持认为数据透视表应位于单元格的右侧。这个争论持续了很长很长时间，最后程序经理胜出。但最终的设计比当初任何一方的单独设计都好出很多。
为确保这种争论完全以事实为基础、在参与方间平等地展开，程序经理和开发人员地位对等是绝对必要的。如果开发人员负责向程序经理汇报，那么在争论过程的任何时刻，程序经理只要略感厌倦，就可以说“好了，讨论得够了，现在就按我说的办”。如果他们是对等的，这种事情就不会发生。就好比在法庭，我们不能允许任何一方的律师同时是法官。只有建立在这个理论之上，真理才最可能通过对等双方间的争论而被发现。只有任何参与方都不具有不公平优势时，争论本身才可能是公平的。
这点很关键，如果你刚才还在梦里探究11年级的Sally现在哪儿，赶紧醒醒吧。她在Scottsdale做生物医学家，还入了共和党。我们必须明白，程序员不能是程序经理的下属，换句话说，开发团队的头头、CTO或CEO，都不应是负责撰写规格书的人。
大多数公司犯的头号错误，就是让程序员的上级编写规格书、设计产品。这样出来的设计，不能得到真正平等的审查，不能引出冲突与争议，自然就不会好到哪里去。
我真正弄懂这个道理，并不容易。在Fog Creek软件公司，我自己曾承担了该程序经理做的大量工作，为此我费劲口水，时刻提醒在我说错的时候，程序员要指出、争辩。我们不是大公司，但也已经到了需要真正的程序经理的时候了——Dan和Jason，程序员喜欢和他们吵。
当然，程序员和程序经理地位对等的时候，程序员会略占优势。这样的事曾发生过几次：程序员让我介入他和程序经理间发生的争议。
“谁写代码？”我问。
“是我……”
“那好，谁负责将程序签入版本控制库呢？”
“我想还是我……”
“既然这样，那你还有什么问题呢？”我问，“你对最终产品的每个比特都有绝对控制权，你还需要什么呢，一顶皇冠？”
可见，这种体制将担子压在了程序经理肩上，要求程序经理能说服程序员，因为在某些时候，程序经理会面临程序员不理会争议而直接按自己想法行事的风险。因此，要成为一名优秀、有影响力的程序经理，要求你：（1）正确；（2）赢得程序员的尊重，唯此他们才可能承认你的正确。
如何赢得这种尊重？
若已是编程高手，当然对你担任程序经理很有帮助。但这个要求并不公平。我也不建议程序经理去写代码。不过，程序员通常首先尊重的是同是程序员的人，而不是非程序员，无论他们多聪明。不会写程序而要成为一个受人尊重的程序经理是可能的，但往往要付出更多努力才行。
赢得开发人员尊重的另一个方法，是能在出现争议的时候充分展示你的才华、开明和正直。如果程序经理净说傻话办蠢事，程序员就会在心里给他们打上笨蛋标记。程序经理武断、情绪化地固执己见，不可理喻，也会大丢信誉分。所以双方，特别是程序经理，一定要避免在争论中带入个人情绪，事实已证明自己犯错时，要乐于、勇于改变老观点，考虑新问题。最后要说的一点是，如果程序经理被发现玩弄权术、向老板打小报告，或试图依靠分而治之的阴谋手段而不是事实在分歧中胜出，都会在程序员那里大失信任。
一个失去了程序开发团队信任的程序经理，将寸步难行。程序员会无视程序经理的存在，直接按照自己意愿行事。其结果是出现大量错误、浪费大量时间，你不但要付给低效率的程序经理薪水，他们还要召集会议、占用其他很多人的时间，而程序质量又没有因此得到提高。
规格化是否是不敏捷的代名词？
在很多开发团队中，规格文档变成了无思想、无灵气、满篇官僚词句的一堆废纸，因此要求革除规格文档的呼声很高。其实这些人被误导了。功能规格书的编写，恰恰是敏捷开发中的灵魂，因为它可以让你在写代码前将大量可能的设计方案快速过一遍。和代码的变更相比，规格文档编写所耗费的工作量实在微不足道。编写规格书会强迫你对大脑中已有的设计方案深思熟虑，帮你快速找到其中的缺陷，充分考虑各种替代方案。有效利用了功能规格书的团队，产品质量更好，因为他们有机会快速探究大量可能的解决方案。而且，他们写代码也更快，因为他们对整个流程的理解更为清晰。功能规格如此重要，以至于在我们FogCreek公司，不多的硬性规定之一就是“无规格，则无代码”。
当然，功能规格书的具体格式，可依情况而定。但其必须遵守一条原则：它是用来说明程序在用户面前如何运行的。它无需解释程序内部代码如何工作。具体来说，你应首先从顶层开始：愿景描述（visionstatement），用不超过一页纸的篇幅，说明新特性、新功能的要点。这步工作完成，就可以开发情景图（storyboard）——用户在应用程序中行进的各种场景图，并详细说明每个场景中，程序如何工作。对于很多类型的功能而言，尤其是UI级的功能，一旦你完成了这些情境图，也就可以描述清楚了。这就是你的功能规格。Jason Fried，现在该你发言了（http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php）。
若要学习如何编写高质量功能规格书，可阅读我的文章《功能规格四部曲》（http://www.joelonsoftware.com/articles/fog0000000036.html）。若需要我编写规格书范本，可从http://www.joelonsoftware.com/articles/AardvarkSpec.html下载。
在一些复杂的功能中，可能还包含着不在UI展示的隐藏行为，这时候你也应该写清楚这些细节。无论如何，编写规格书本身就有助于在写下第一行代码前发现问题、冲突和设计漏洞，这样在你真正写代码的时候，可能导致设计混乱、质量低下、甚至重新设计这类不可预知问题的出现概率要低很多。
如何学做程序经理？
要成为一名合格的程序经理，主要就是学习：学习技术、学习做人、学习如何在组织中产生影响力。一个好的程序经理，要同时具备工程师的技术设计方法、政治家构建共识、团结民众的能力。这方面可读的书不多，若你从事这项工作，我还是尽我所知推荐几本：
Scott Berkun的《Making Things Happen》（http://www.amazon.com/gp/product/0596517718?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596517718），这是唯一一本非常准确说明了程序经理必须做哪些事情的书，就从它开始吧。Scott曾长期在Internet Explorer团队担任程序经理。
Another big part of the program manager’s job is user interfacedesign. Read Steve Krug’s Don’t Make Me Think, then my own book UserInterface Design for Programmers.
程序经理的另一大块工作是用户界面设计。这方面可阅读Steve Krug的《Don’t Make Me Think》（http://www.amazon.com/gp/product/0321344758?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321344758）和我自己的《User Interface Design for Programmers》（http://www.amazon.com/gp/product/1893115941?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=1893115941）。
最后，我知道听起来可能有点老套，但Dale Carnegie在1937年出版的《How to Win Friends & Influence People》（http://www.amazon.com/gp/product/0671027034?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0671027034）确实是一本讲人际交往技巧的好书。它是我要求Fog Creek所有初级管理人员阅读的第一本书。我每次告诉他们阅读这本书时，他们都会窃笑；等到读完，他们都会爱上这本书。
作者简介：
Joel Spolsky：Fog Creek 软件公司（http://www.fogcreek.com/）创始人，曾在微软Excel团队工作。FogCreek位于纽约，这是一家以实践证明可以很好对待程序员，而又能获得不错利润的公司。程序员有私人办公室、免费午餐，每周工作40个小时。用户满意后才需为软件支付费用。公司主要产品包括：FogBugz，帮助大型团队开发高水平软件的项目管理系统；Fog CreekCopilot，让远程桌面变得轻而易举。
