拥有一个好的项目经理是制造优秀软件的秘密公式之一。而你的团队里可能就没有，因为大多数的团队都没有。
Charles Simonyi，这位参与发明了WYSIWYG文字处理、跟Martha Stewart约会、还在微软股票上整了成百万的美刀、甚至去过太空的牛掰程序员，他试图解决大型软件团队组织方面那个“人月神话”问题，于是创造了一个职位，由超级牛掰的顶级大神程序员担任，负责撰写顶层功能，而把底层实现交给手下一队打杂的初级程序员去干。这个职位就被称作“program manager”。Simonyi是个聪明人，可是这个点子却不怎么样。我想是没有人愿意去做打杂的初级程序员的。
80年代后期Mac Excel团队一位名叫Habe Blumenthal的程序员把这个称呼捡起来用在了完全不同的职位上。他注意到软件开发已经复杂到没有一个程序员能有时间去关注如何让软件更好用活更有用。而营销团队总是在大喊大叫客户的需求却没人能有时间去跟他们交流或者把他们的MBA语言翻译成实在的功能特性。产品设计方面有很多事情是需要大量工作的：与用户交谈、跑可用性测试、评测竞争产品、以及努力思考如何让事情更简单，大多数程序员既没有时间，也并不擅长干这些。Blumenthal使用了“程序经理”这个称呼，而完全重定义了这个职位。
程序经理做些什么事情？
从此，程序经理的工作就是：
1， 设计UI
2， 撰写功能规格
3， 协调团队
4， 做客户代言
5， 还有，穿Banana Republic的休闲卡其裤
小型产品也许只需要一个程序经理就够，更大些的产品就可能有很多个，每一个负责功能的一个子集。经验法则是大约没四个程序员对应一个项目经理。如果划分起工作来有点晕，我从Mike Conte那儿学到的一个好办法是依据用户活动来划分。比如说，Twitter也许可以被分为四个用户活动：
1， 注册以及熟悉环境
2， 发信息和阅读回复
3， 配置帐户
4， 搜索新闻
我的第一个程序经理工作实在微软的Excel团队，负责的用户活动叫做“定制”，也就是脚本和宏。我要做的第一件事就是找出客户需求，于是我去跟尽可能多的客户交谈直到我开始厌倦，因为总是听到一样的东西。我也花了很多时间去跟开发团队交谈，去搞清楚在一个18个月的发布周期里面有可能实现些什么。我还花了很多时间去跟Visual Basic团队交谈，看他们能不能够给Excel提供一套编译器、代码编辑器和对话框编辑器，作为我们的宏语言。我还去跟Apple沟通，他们正在开发自己的通用宏语言AppleScript。我也去找微软的其他应用团队，主要是Word、Access、Project和Mail，他们所做的事很多跟Excel是一样的。这整个流程主要由谈话构成。开会啦，电邮啦，电话啦。后来我一辈子都怕了这些，就像现在躲在办公室里，生怕电话又会响。
第二步就是写一个愿景规划，也就是个粗线条的文档，其中说到：这这这就是Visual Basic要在Excel里工作的样子，这这这是一些宏的例子，这些这些这些就是我们需要构建的主要部分，这个这个就是它们如何解决客户的问题。当这个文档没有受到太多反对以后，我就开始撰写一个详细得多的规格书，这个规格书在最小的细节程度上阐释了每一个东西对用户来说应该是什么样的。
这就是一份功能规格，它不是技术规格，也就是说，它完全讨论的是用户看到的东西，而不是这些东西如何实现。程序经理不关心开发团队如何实现的内部原理。我把这份规格的部分发给开发领队Ben Waldman，他和他的团队坐下来商讨他们在内部要干些什么才能让这份规格实现。他们弄出了一份非常聪明而紧凑的表格，把我所定义的对象接口对应到Excel内部功能上，当然这份东西其实不管我的是。我对Excel内部机制所知无几，也完全不知道功能应该怎么实现的。
实话说吧，我对什么事都完全不懂。我刚刚从学校毕业出来，没有足够的经验去开发代码、测试代码、撰写文档、推销产品、或者做可用性测试。幸运的是，微软在每个岗位上都有许多相当有经验的老手，他们教会了我今天所知道的一切，也是他们进行了真正的工作生产出了牛掰的产品。举例说吧，我知道的是，用户必须可以像这样的方式把一个表格单元的值拷贝进一个变量：
X = [A1]
可问题是单元格里可能是一个数字也可能是一个字符串，而Basic又是前期绑定的，你必须先用DIM把变量x定义成一个整型、浮点数或者字符串，然后才能用它。
Basic必须拥有某种动态类型，可我又没有聪明到能够了解怎么做到这一点。没有关系，Visual Basic团队一位叫Tom Corbett的程序员想出了办法。这就是Variant和IDispatch的起源，于是Basic成了一个动态语言，拥有今天小子们称之为“duck typing”的功能。这件事的要点在于，我的职位并不需要去解决问题，而是找出客户的需求，并且保证程序员们找出方法来解决这些需求。
当功能规格完成，开发团队开始干活儿的时候，我有两个责任：解决设计方面出现的任何问题，以及代替我得开发人员去跟其他团队沟通。我去找测试人员，解释功能理论上应该如何工作，以便他们能对此计划好测试方案。我去找文档团队，保证他们能够写出Excel Basic的优秀教程和参考。我去找本地化专家搞定本地化策略。我跟营销人员解释VBA对营销的好处。我跟可用性专家一起建立可用性测试。
程序经理确实要开很多会议，但是产出的主要就是规格书，所以象我这样一个刚毕业的小毛头也可以干这个活。要成为项目经理你不必是一个14年经验的编程老手，实际上，如果你真有14年编程经验，你可能就知道得太多了，以致没法做好用户代言。
冲突
缺少程序经理的话，你那些纯种土产的强力程序员会搞出来一个雷死人的用户界面，只有Vulcan星人才会用（参见git）。最好的程序员们都出了名的聪明，无法理解为什么有人无法记住16个单字母的命令行参数。这些程序员也会倾向于依赖他们的第一想法，尤其是当他们已经写了代码的时候。
程序经理带给软件设计流程的一个最好的因素就是对于设计的第二观点，而这观点应该会更能共鸣于那些既不想读手册，不想定制emacs-lisp函数或者八进制数，还期望程序能用的脑残用户。
一个好程序经理应该对UI的工作方式有自己的主见，比开发人员的意见可能要好也可能要烂。这上面有着长期的争论。典型情况是，程序经理想要对于用户更简单和易于理解，比如有心灵感应超能力的用户界面，或者30’’还要能放进衣袋的屏幕之类，而开发人员想的是代码实现起来简单，有命令行界面（“这有什么不好用啊？”）和Python绑定。
我在Excel 5项目里印象最深的里程碑式争吵是有一个开发人员，想让数据透视表格浮在表格之上的绘图层，而程序经理坚持表格应该直接存在于表格单元里面。这场争吵持续了非常之久，最后程序经理获胜，不过最终的设计方案比之前任何单方面的设计都要好上很多。
为了保证争论能够基于敬意和理性的事实，最关键的事程序经理和开发人员应该是平级的。如果开发人员归程序经理管辖，在争论中的某些点上程序经理就会对整件事感到厌倦，说出“好啦，说的够多了，现在就按我说的做！”的话。而如果他们是平级的，就不会这样了。这就类似于法庭，不能让某一边的律师担任法官，我们基于的理论是，真实只有在对等的辩论过程中才最有可能显现。只有当任何一方都没有不公平的优势的时候争论才会使公平的。
这里可是关键点啦，如果你刚才在发梦想知道11年级的Sally现在在哪儿，醒醒吧，她在Scottsdale当生物医学家，进了共和党。现在注意了。程序元不能隶属于程序经理，也就是说，开发领队、或者CTO、或者CEO，不能充当撰写规格书的人。
大多数公司犯下的头号错误就是让程序员的管理者来写规格设计产品。这是不对的，因为设计不能得到公正的裁判，不是诞生于冲突和争论，也就不会有应该成为的那么好。
我也是吃了亏才领会到这一点的。在Fog Creek公司，很多时候我自己做程序经理的工作，而我总是要很费力去让别人牢记他们应该在我说错的时候跟我争论。我们不是大公司，可是现在也终于大到需要真正的程序经理了，也就是Dan和Jason，程序员们很喜欢跟他们争吵。
当然，如果程序员跟程序经理是平级的，程序员就会有一些优势。比如说这样的事曾发生过多次：一个程序员请求我去调解他跟程序经理之间的争论。
我问他：“代码是谁来写呢？”
“我啊。”
“那好，谁把程序签入进版本管理器？”
“我想还是我……”
“所以啊，那你还有什么问题？”我问道，“是你对于最终产品的每一个比特拥有绝对的控制权。你还需要什么呢？一顶皇冠？”
你看，最终这个体制八责任归到了程序经理，他需要去说服程序员，因为在某些点上，程序经理会面临这样的风险，程序员会放弃争议而直接去做他想做的事。因此，一个得力的程序经理需要做到，第一，正确，第二，还要赢得程序员的尊重，他们才会承认你是正确的。
怎样才能赢得这样的尊重的？
作为程序经理，如果自己也是编程高手，会很有用。不过这是不公正的。程序经理不应该是些代码的。可是程序员总是倾向于尊重程序员，而不是非程序员，无论他们多么聪明。成为得力程序经理而不会编码是可能做到的，不过这样要赢得开发团队尊重的难度要高一些。
赢得开发团队尊重的另一个方法是，在争论中展示你的智慧、开明和公正。如果程序经理说了傻话，程序员就会在心里给他们设上笨蛋的标志位。如果程序经理开始个人化或者情绪化地坚持某种做事方式，以至于变得不可理喻，他们就会很快失去信誉，所以双方——但特别是程序经理这边——都需要避免情绪化地陷进争论，而要善于考虑新的论据并改变观点，如果事实的确如此的话。最后，如果一个程序经理被认为不尊重事实，而去玩弄政治，跟老板私下会见，或者试图用分而治之的阴谋来赢得辩论，他们就会失去程序员的信任。
当程序经理失去开发团队的信任，就玩儿完了。他们不能有效工作。程序员会忽略他们直接按自己意愿行事。这将导致差劲的代码而且浪费时间，因为你不但要给一个无效的程序经理付薪水，这个无效的程序经理还要召集会议，浪费所有其他人的时间，尽管他们也没有在生产更好的代码。
【本文翻译仅为外语学习及阅读目的，原文作者个人观点与译者及译言网无关】
