软件随想录(local.joelonsoftware.com/wiki)-2009年03月09日 如何扮演程序经理的角色？ - How to be a program manager

From The Joel on Software Translation Project

制作伟大软件的秘方之一是：有个好的程序经理。你的团队里应该没有这号人物，因为大部分的团队都没有。

Charles Simonyi，那位发明了「所见即所得」(WYSIWYG) 文字处理软件、跟 Martha Stewart 约会、赚进价值亿万的微软股票而且上了太空的天才程序设计师，是首位尝试著组织超大开发团队来解决人月神话的人。他创造了这样的制度：由一位超强工程师来设计系统里最高阶、最上层的函式，然后一群菜鸟工程师就根据这些设计来实现较低阶的函式与其中的细节。这「超强工程师」的职位就是本文所说的程序经理。虽然 Simonyi 如此的聪明，但是这个方法确不是很高明。我猜，原因是没有人想当菜鸟工程师。

八零年代后期，微软 Mac Excel 团队的 Jabe Blumenthal 回收「程序经理」这个职称并拿来作为其它用途。他注意到软件规模日趋复杂，几乎没有工程师有时间搞清楚怎么做出好用且有用的软件。但是工程单位却没有人有时间和高举顾客需求的大旗的市场单位做沟通，或是把这些 MBA 专用语言转换成真正有意义的功能。设计一个产品要做的事真的好多：跟使用者沟通、可用性测试、检视竞争产品还有努力的让产品变得更简单易用。但是大部分的工程师真的没有时间做这些事情（或是不适合做这些事情）。Blumenthal 重新定义了「程序经理」这个职位的工作内容。

程序经理做些什么？

此后，程序经理的工作变成：

• 1. 设计使用者操作介面
• 2. 撰写功能规格书
• 3. 协调开发团队
• 4. 作为使用者的代言人
• 5. 穿破 Banana Republic 衬衫

小型产品或许只需要一个程序经理，不过在大一些的产品则可能有好几个，其中每个人都负责一部分的功能。实用的规则是：一个程序经理搭配四个程序设计师。有个我从 Mike Conte 那里学到的方法可以解决切分系统功能时遇上的困难：依照使用者的活动来拆解系统。比如说，我们可以把 Twitter 拆解成四种使用者活动：

• 1. 注册与启用
• 2. 发文、读取回应
• 3. 设定帐号
• 4. 找新闻

我初次担任程序经理是在微软 Excel 产品中负责「自订」这个使用者活动，例如撰写脚本或是宏指令。我要做的第一件事是去厘清使用者需要什么，所以我尽可能的多做客户访谈，直到我发觉客户给的都是一样的回馈而觉得无聊为止。为了想知道一年半开发周期能做到哪些事，我花了很多时间跟开发团队沟通。也用了许多时间询问 Visual Basic 团队是否能够提供编译器、程序编辑器与对话盒编辑器给 Excel 里的宏语言功能。我曾经去过当时正在开发 AppleScript 这个通用宏语言的苹果电脑。还有微软里的许多与 Excel 产品类似的团队诸如 Word，Access，Project 与 Mail。大多数时候，这个过程大多是由交谈、开会、email 与电话所组成。因为被这样的生活吓到了，我是缩在办公室里害怕电话铃声响起。

接下来则是写下一份愿景声明：这是种概略的高阶文件，说明了诸如 VisualBasic 如何在 Excel 里运作、一些宏程序的例子、待开发的主要功能以及这些东西解决了什么问题等。当其他人对这份文件不再有太多异议时，我便开始制作更详细的规格，连最不起眼的细节都做出解释、使用者看到的每个东西长什么样子等。

这是一份功能规格，不是技术文件。意思是这整份文件都在阐述使用者看到什么，而不是怎么实现这些功能（这里可以找到一切关于功能规格的资讯）；程序经理不关心工程师怎么实现这些东西。接下来当我把一些章节拿给研发主任 Ben Waldman 时，他和他的团队坐下来讨论并说明将会如何实做这些功能。他们最后得出了相当高明又简洁的表格，把我当时定义的面向对象使用者介面套进 Excel 的内部实现。不过这不是我的工作，我不太了解 Excel 内部细节也不知道怎么实现这些功能。

老实说，我不是万能的天神。身为一个刚毕业的新鲜人，我没有太充分的程序、测试、文件、行销或可用性测试的经验。幸运的，微软在前述每个领域都有经验极丰富的大师级人物；而这些人成就了今天的我，而且真正动手作出产品正是这些人。例如，当使用者在 Excel 里想把格子里的数值复制到某个变量里：

　　　x = [A1]

问题是这格子的内容可能是数值或字串，但是在Basic里，数组的资料型态必须在变量被使用之前就完成声明。

看来要 Basic 可以动态处理类型才行，但是我没聪明到晓得该怎么做。没关系，Visual Basic 的 Tom Corbett 解决了这个问题。因此，Variants 和 IDispatch 问世了，而且 Basic 变成你们这些小朋友现在所说 "duck typing" 程序语言。不过，重点是我的工作并不需要解决这些问题。我的工作是搞清楚客户需要什么，并确定工程师知道怎么解决这些问题。

当规格底定且开发团队开工之后，我的职责变成：解决开发过程中出现的规格问题、与其他开发团队沟通以便让工程师专心工作。我也向测试人员解释这些功能该怎么运作并协助他们作测试计画。我也确认了文件编辑人员真的了解怎么写出好的 Excel Basic 教学与参考文件。我还跟 localization 专家研究出 localization 策略。也和行销部门深入解释 VBA 能对产品销售带来什么好处。还跟软件可用性专家安排了一些可用性测试。

好的程序经理一定要开很多的会，但是除了文件之外不会产出太多东西。这就是为甚么一个菜鸟如我都可以接下这份工作的原因。你不会因为没写过十四年的程序而当不成程序经理（事实上，十四年的程序经验可能会使你因为懂得太多而不适合成为使用者的代言人）。

冲突

如果没有程序经理，那些天才程序设计师会做出让你五体投地的操作介面，不过前提是：如果你是瓦肯星人的话。我们都知道，最优秀的程序设计师通常无法想像竟然有人记不住十六种命令列参数。这些程序设计师也倾向在写完程序以后就坚守已经做好的结果。

程序经理为软件设计过程所能做的最棒的事情是「对于该怎么设计一个功能提出不同的意见」，希冀能让人们用同理心来看待使用者：那些令人讨厌的傻瓜。他们要求在不阅读说明书之前就能顺利使用软件、用 lisp 自订 emacs 函式、或是转换为八进位的心算。

好的程序经理会提出她觉得使用者介面该怎么运作的想法，可能比开发人员想到的要好、甚至较差，然后就是冗长的争论了。通常程序经理的方向是让使用者容易上手的设计，像是能感知使用者意向的操作介面、一个能塞进口袋的三十英寸屏幕。而工程师想做的则是整合 Python 的文字操作介面（哪里不好用了？）。

在我的记忆中，Excel 5 项目里最重要的一次辩论是关于枢纽分析表的显示。程序设计师想让枢纽分析表浮在试算表上方的绘图层，而他的程序经理则坚持要让分析表显示试算表中的格子里。这个争论真的持续了非常久。终于，程序经理占了上风。不过最后的设计比两人各自主张的都好上了许多。

让程序经理和工程师处于相等地位绝对是确保辩论过程相互尊重并持续以理性、事实为基础的重点。如果工程师归程序经理管辖，则在争得昏头的程序经理很容易就会丢下一句：「好了，讨论得够多了，就照我说的作吧。」，这样的事情在双方地位平等时则不会发生。这有点像是法院法里的：「我们不允许某方律师变成法官，所以我们致力于『当双方地位平等之时的辩论最能够揭发真相』的理论」。一场辩论只有在没有一方具有不公平优势的状况下才可能公平。

这一点很重要，如果你刚作了想知道就读十一年级时的莎莉现在在哪的白日梦，醒醒吧。她现在是个住在 Scottsdale 的生物学家兼共和党员。注意了：程序设计师不能是程序经理的下属。此外，开发主任，技术长或是执行长都不该是决定规格的人。

大部分公司最大的错误是让程序设计师的经理来写规格与设计产品。为甚么这是个错误呢？因为这样的设计过程里没有公平的审视，也没有经过冲突与辩论，所以结果不会像它该有的那么好。

我之前是那样一路跌跌撞撞走过来的。而我自己在 Fog Creek 公司也作很多程序管理的工作，我必须不断地提醒同事必须在我说错事情的时候跟我争论。Fog Creek 不是个大公司，但是现在也大到需要有程序经理了，他们是 Dan 与 Jason，程序设计师很爱跟他们辩论。

当然，当程序设计师跟程序经理处于平等状况下，常常是程序设计师占上风。曾经有好几次，程序设计师要我干预他们跟程序经理之间的辩论：

　　「这个程序是谁要实做的？」，我问道

　　「我…」

　　「好吧，然后是谁把程序代码commit进版本管理呢？」

　　「我猜，是我吧…」

　　「那到底有什么问题？」，我问道：「产品任何一个 bit 的长相你都有绝对的控制权，你还需要什么？让你当教宗吗？」

明白了吧，这个系统把压力摆到程序经理身上，让他们设法去说服工程师。因为一个绝望的程序设计师可能会凭自己的感觉做事，这样的结果对程序经理是有风险的。因此，要成为有效率的程序经理，你必须要 1)正确，2)赢得工程师的尊敬，然后他们才会认同你的看法。

怎么得到工程师的尊敬？

无论对方有多聪明，程序设计师通常更尊重会写程序的人。所以有个方法是：程序经理本身很能写程序。但是这并不公平，因为程序经理并不被期待是个程序设计师。所以能干的程序经理可以不会写程序，但是这样要赢得程序设计师的尊重会难上一些。

另一种让程序设计师尊敬你的方法是展现你的智慧、开放的心胸与公平处理每次的争论。当程序经理讲了傻话，程序设计师就会把他标示成「傻瓜」。如果程序经理一意孤行，作了不合理的事情，就会失去他人的信任。程序经理特别需要在争论中屏除个人情绪，并乐于将证据纳入考量，根据事实改变看法。最后，如果程序经理为了赢得争论而去搞政治手段，例如私底下找老板、搞各个击破等，则他们终将失去程序设计师的信任。

程序经理若失去程序设计师的信任，那一切就完了。这团队将不再是有效率的团队。程序设计师开始不把程序经理当一回事，并且搞他们自己想要的东西。结果就是浪费时间又产出一堆烂程序代码而已。这时候你除了支付薪水给这个没用的程序经理之外，这个人还会把大家拉去开会并耗光大家的时间，但是结果终究不会变得更好。

规格？这样实在很不Agile

「不写文件」的想法正在许多撰写规格书形同具文的研发单位里如雨后春笋般的冒出来。其实，这些人都被误导了。撰写功能规格是敏捷软件开发的核心之一，因为它让我们在动手写程序之前有机会迅速的审视多种设计的可行性。跟修改写好的程序比起来，修改一份文件实在是容易多了。认真撰写规格文件强迫我们仔细去思考自己脑袋里的设计并迅速发现其中的问题，所以我们可以尝试更多的设计。采用功能性规格设计的团队能产出设计较好的软件，因为他们有机会发掘更多可行的方案。而这样子写起程序来也快了许多，因为工程师在开始写程序的时候已经很清楚接下来需要做什么。「没规格就不写程序」是 Fog Creek 公司的一个不能妥协的原则。

功能规格书并没有一定的形式。所有规格必须做的是去解释程序的行为而非程序如何运作之类的事情。我们从最高阶的「愿景描述」开始，使用少于一页的篇幅来描述这个新功能的重点。愿景确定之后就开始作分镜，也就是仿制使用过程的画面原型，并详细标示这些东西如何运作。对于许多功能，尤其是与使用者操作介面高度相关的功能，这些分镜完成就大致代表工作完成了，这就是你的规格。Jason Fried，滚吧。

你必须为分镜里没有提到的复杂功能所伴随的隐藏行为写下更多的细节。无论如何，写文件能让你在开始写程序之前就发现问题、冲突与设计上的缺陷。所以当你真正开始写程序的时候，遭遇未曾思考过的问题而导致程序重写的机会就比较低了；更惨的则是，较差的设计。

怎么学习当个程序经理？

大多时候，作为程序经理是一种学习：学习技术、了解人性、搞懂怎么在组织政治里有效率的做事。好的程序经理能把工程师的想法整合到设计里，并像政治家一样把人聚在一起并建立共识。当你在做这些事情的时候，可以读一读这些书：

就我所知，Scott Berkun 的「Making Things Happen」是唯一一本内容涵盖了程序经理所要做的事情的书。所以从这一本开始吧。Scott 曾经在 Internet Explorer 团队担任多年的程序经理。

程序经理的一大部分工作是设计使用者操作介面。首先可以读 Steve Krug 的「Don’t Make Me Think」，然后是我写的「User Interface Design for Programmers」。

最后，我知道这听起来很俗气，不过 Dale Carnegie 在 1937 年写的「How to Win Friends & Influence People」真的是的超棒的人际关系入门书。这是我所指定的在 Fog Creek 里受训的经理人要阅读的第一本书。这些人一开始总是在私底下窃笑，不过大家在读完之后都会爱上这本书。