指派一名优秀的程序经理，是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人，其实绝大多数团队都没有。
■ 文 / Joel Spolsky ■ 译 / 罗小平
Charles Simonyi，这位曾与Martha Stewart（译者注：美国女富豪，作家）拍拖15 年、WYSIWYG字处理技术发明人之一、从微软股票赚得10 亿美元（译者注：Charles Simonyi 曾是微软Office产品团队的负责人）、到过太空的天才程序员，是试图解决大型软件团队遇到的“人月神话”问题之第一人。他的方法是创立一个新的岗位，由超级天才程序员担任，负责系统中最重要功能的实现，而其他次要部分则交给一个由低级程序员组成的杂牌团队。他把这个岗位命名为程序经理（program manager）。虽然Simonyi 本人是天才级的，但他的这个想法却不怎么出彩，我想没人愿意做一个被人轻视的低级程序员吧。
若需详细了解这段历史， 可以阅读William Poundstone的《How Would You Move Mount Fuji?》
Jabe Blumenthal，是20世纪80年代后期在Mac Excel团队工作过的一名程序员。他捡起了这个头衔，却赋予了不同的含义。Blumenthal 发现软件开发已经变得日益复杂，以致没有哪个程序员有时间去关心如何真正保证软件的可用性和实用性。而市场人员又在一旁大谈客户需求，抱怨没人听他们的 话，没人将他们MBA式的天才想法转化为软件中可用的功能。产品设计方面不少的工作都需要花费大量时间，比如用户沟通、可用性测试、竞争对手产品的分析评 估、将复杂问题化繁为简等等。但绝大多数程序员恰恰没有时间做这些事情（实际上这些往往也不是他们的强项）。于是，Blumenthal 重拾“程序经理”，不过完全重新定义了这个职位。
程序经理需要做什么工作？
自此以后，一名程序经理的工作包括：
1. UI 设计
2. 编写功能规格
3. 团队协调
4. 充当用户代言人
5. 还有，穿Banana Republic 牌子的休闲Chino裤
在 小项目中，你有一个程序经理就够了，但对于大型项目，就可能需要配置多位了，每个人负责全部功能特性的一个子集。从众多项目中总结出来了一个经验法则：每 四名程序员配置一个程序经理。那么如何划分功能集呢，如果你遇到困难，我向你推荐我从Mike Conte那学到的方法：根据用户活动划分产品功能（http://www.joelonsoftware.com/uibook/chapters /fog0000000065.html）。比如：twitter.com可划分为四类用户活动：
1. 注册与登录
2. 发表帖子、阅读回复
3. 配置个人账户
4. 搜索新闻
我的第一份程序经理工作是在微软的Excel 团队，负责一个叫做“用户化”的用户活动（比如编写脚本、宏）。首先要做的事情是搞清楚用户的需求。于是我与很多用户交流，直到我长满茧子的耳朵只能听到相同的需求、让人厌烦为止。接下来，需要花很多时间与开发团队沟通，弄清在18个月的新版本开发周期中，些需求是合理的、可以实现的。并和Visual Basic 团队沟通，确定他们是否可提供编译器、代码编辑器、对话框编辑器，否则用户就不能在Excel 中使用宏语言。同时还必须跑去与Apple沟通，他们当时正在自己搞一门叫做AppleScript 的通用宏语言。此外，我还要和微软内部的其他应用团队，主要包括Word、Access、Project和Mail等打交道，因为他们也在做和Excel 团队差不多的事情。这个过程的绝大部分工作，都是沟通讨论——会议、邮件、电话……几乎无休无止。我被那段生活搞怕了，直到现在，在办公室的时候还怕听到 电话铃响。
第二步是写愿景规划。这是一个内容相当宽泛的文档，比如Visual Basic如何在Excel中工作，用户可能编写的宏是什么样子，需要技术团队构建哪些模块，以及它们如何解决用户的问题。然后在此基础上讨论修改，直到 没有太多分歧。至此，便可以开始编写详细规格书，要描述清楚每个不可再分的细节呈现在用户面前时的样子。
这是一份功能而不是技术规格书。也就是 说，它的全部内容都用于描述用户所见所为，而不是程序如何实现。若需进一步了解功能规格，请阅读 http://www.joelonsoftware.com/articles/fog0000000036.html。程序经理不关心开发团队的内部 实现细节。当我将这份功能规格发给开发团队的头头Ben Waldman后，他和他的团队再坐下来详细讨论实现工作。最后，他们很聪明地弄出一份精悍的表格，将我定义的面向对象的接口一一映射到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由此诞生了，借助“鸭式类型识别”（duck typing。“如果一只鸟，走起来像鸭子，叫起来像鸭子，那我们就可以管它叫鸭子。”），于是Basic 摇身一变，成了动态语言。这个事情说明，我的工作不是自己去解决问题，而是找到用户需要解决的问题，并保证程序员找出解决这些问题的办法。
一旦功能规格完成、技术团队开始工作后，我的职责就有了变化：（1）解决设计方面出现的问题；（2）负责与所有其他团队的沟通，以便节省开发人员的时间。例如，我要向测试人员说明全部功能是如何运转的，并帮助他们设计测试计划；确保文档团队明白如何为Excel Basic 编写一份高质量的教程和参考手册；和本地化专家确定本地化策略；向市场人员解释VBA在市场上的优势；和可用性专家设计可用性测试方案等。
程序经理需参加大量的会议，但其产出基本不超出规格文档这个范围，因此我一个刚毕业的无用之人也能胜任这份工作。完全没必要让一个有14年经验的资深程序员担当程序经理。实际上，有14年的开发经验，你反而可能因为知道太多，而无法扮演好用户代言人这个角色。
冲突
如果没有程序经理，聪明的程序员们在一起，可能设计出让用户难以理解的界面，也许只有Vulcan 人（《Star Trek / 星际迷航》中逻辑思维能力超强的外星种族）才会表示“正合吾意”。最好的程序员会聪明到不能理解用户为何不能记住16 个单字母的命令行参数。这些程序员往往难以割舍他们的最初想法，尤其是已经将自己的想法变成了代码之后。
程序经理给软件设计流程带来的最大益处，是可以引入程序员之外的第二种观点。而这种观点恰恰更接近用户的想法——这些用户往往既不想阅读使用手册，更不想写什么emacs-lisp函数，至于在他们大脑里将十进制数字转化为八进制，那就更不可能了。
一个好的程序经理对于UI 的工作方式有他自己的想法，和开发人员的相比，可能更好，也可能更坏，因此需要双方进行讨论。通常，程序经理是站在用户角度，希望凡事都尽可能简单易懂， 诸如有心灵感应力的用户界面、大到30″ 而又能放进口袋的屏幕之类；而开发人员想的是处处尽可能减少要编写的代码，支持命令行界面（他们会说“这怎么就不好用了呢？”）和Python绑定。
我记得Excel 5项目中最为经典的争论发生在一个开发人员和程序经理之间。开发人员希望数据透视表（pivot table）悬浮在电子表格的绘画层上，而程序经理坚持认为数据透视表应位于单元格的右侧。这个争论持续了很长时间，最后由程序经理胜出。而最终的设计比 当初任何一方的单独设计都好出很多。
为确保这种争论完全以事实为基础、在参与方间平等地展开，程序经理和开发人员地位对等是必要的。如果开发人员 负责向程序经理汇报，那么在争论过程的任何时刻，程序经理只要略感厌倦，就可以说“好了，讨论得够了，现在就按我说的办”。但如果他们是对等的，这种事情 就不会发生。就好比在法庭，我们不能允许任何一方的律师同时是法官。只有建立在这个理论之上，真理才最可能通过对等双方间的争论而被发现。只有任何参与方 都不具有不公平优势时，争论本身才可能是公平的。
这点很关键，如果你刚才还在梦里探究11年级的Sally 现在在哪儿，赶紧醒醒吧。她在Scottsdale做生物医学家，还入了共和党。我们必须明白，程序员不能是程序经理的下属，换句话说，开发团队的头头、CTO或CEO，都不应是负责撰写规格书的人。
大多数公司犯的头号错误，就是让程序员的上级编写规格书、设计产品。这样出来的设计，不能得到真正平等的审查，不能引出冲突与争议，自然就不会好到哪里去。
要我真正弄懂这个道理，其实并不容易。在Fog Creek 软件公司，我自己曾承担了该程序经理做的大量工作，为此我费劲口水，时刻提醒在我说错的时候，程序员要指出、争辩。我们不是大公司，但也已经到了需要真正 的程序经理的时候了——Dan和Jason，程序员喜欢和他们吵。
当然，程序员和程序经理地位对等的时候，程序员会略占优势。这样的事曾发生过几次：程序员让我介入他和程序经理间发生的争议。
“谁写代码？”我问。
“是我……”
“那好，谁负责将程序签入版本控制库呢？”
“我想还是我……”
“既然这样，那你还有什么问题呢？”我问，“你对最终产品的每个比特都有绝对控制权，你还需要什么呢，一顶皇冠？”
可见，这种体制将担子压在了程序经理肩上，要求程序经理能说服程序员，因为在某些时候，程序经理会面临程序员不理会争议而直接按自己想法行事的风险。因此，要成为一名优秀、有影响力的程序经理，要求你：（1）正确；（2）赢得程序员的尊重，唯此他们才可能承认你的正确。
注：本文节选自Joel Spolsky的博客文章，全文请参考杂志官方Blog：http://blog.csdn.net/programmer_editor
作者简介
Joel Spolsky，Fog Creek 软件公司（http://www.fogcreek.com/）创始人，曾在微软Excel 团队工作。他的网络日志“Joel谈软件”一度是最知名的IT博客之一。作者博客：www.joelonsoftware.com/。
（本文来自0902期《CTO》专刊）