【翻译】如何做一个项目经理？

原文地址： http://www.joelonsoftware.com/items/2009/03/09.html

以下为译文：

有一个好的项目经理是开发真正伟大的软件的秘方之一。可能你的团队现在还没有好的项目经理，因为大多数团队都没有。

Charles Simonyi，一个杰出的程序员，WYSIWYG文字处理的共同发明者，曾经通过微软股票赚了上十亿美金并到过太空，第一次尝试解决管理项目团队的难题时，使用的方法是：由一个资深的程序员来写上层接口，而将其具体的实现交给一些初级的程序员来完成，他将这个资深程序员称为项目经理。Simonyi是杰出的，但是这种项目管理方法值得商榷，我想没有人愿意成为一个繁琐的初级程序员。

同样的例子，请阅读William Poundstone的《你如何移动富士山》？

Jabe Blumenthal，80年代末MAC Excel开发团队中一名程序员，现在使用了一个不同的头衔。他注意到，软件开发变得如此复杂，以至于程序员都没有时间去搞清楚如何使软件可用。营销团队抱怨客户需求以及没有人有时间和他们交谈并将其转化为实际的产品功能。有一些产品设计元素，花了很多时间和用户交谈，运行可用性测试用例，检视竞争性的产品，并思考如何使事情变得更容易，但大多数程序员没有时间去做。Blumenthal现在的头衔是项目经理，但是做的是和以前一样的工作。

那么项目经理应该做什么呢？
今后，项目经理应该：
设计用户界面
写功能规格
协调团队
像真正的客户一样提供服务

在小的产品开发中，可能只是一个项目经理，但对于较大的产品，可能需要多个项目经理。每个项目经理负责其中的一部分功能。一个好的经验法则是，每四个程序员需要一个项目经理 。如果你划分功能的时候遇到困难，有一个方法是根据用户活动来划分。例如，Twitter可以分为4个用户活动 ：
注册和入门
发布信息和阅读回复
配置您的帐户
搜索新闻

我在微软的第一份项目管理工作是在Excel上实现定制功能，即定制脚本和宏。我第一步要做的事情是了解用户需求，方法是和尽量多的客户交流直到厌烦，因为同样的东西听了太多遍，而那些就是真正的用户需求。然后我花了很多时间和开发团队交流，并指出哪些应该在18个月内实现，同时也花了很多时间和VB团队交流，看他们是否可以提供一个编译器，代码编辑器以及对话框编辑器，可以在Excel中供宏语言使用。除此之外，还要和Apple以及微软的其他应用团队交流。大多数的交流工作包含了交谈，会议，邮件以及电话交流等方式。

我第二步做的事情是写一个愿景：通过排序来说明，VB是如何工作在Excel中的，一些示例宏看起来是什么样，我们需要构建哪些主要部分以及是如何解决客户问题的。当没有太多的反对意见时，我就开始编写详细的规格，这是功能性的规格，而不是技术规格，也就是说，描述用户看到的，而不是具体如何去实现。一个项目经理不需要关心具体内部是如何实现的。

说实话，我经验并不丰富。大学毕业后，我并没有足够的经验来开发代码，测试代码，写文档，营销产品或做可用性测试。幸运的是，微软在这些职位上都有经验丰富的大师，他们教会了我这一切而且他们在做真正很棒的产品。

例如，我知道，用户希望电子表格单元格的值复制到一个变量：可以用X = [A1]，但麻烦的是，一个单元可以容纳一个数字或字符串，但BASIC语言是早期绑定的... ...也就是说，你在使用x前，必须使用DIM X将其声明为一个整数，浮点数或字符串。

BASIC必须要获取一些动态类型，可我不知道如何处理。不过不要紧，Tom Corbett，VB团队的程序员，给出了解决方法。于是，Variants和IDispatch诞生了，而且Basic也变成了一个动态语言。我的工作不是必须解决问题，而是要弄清楚客户的需求，并确保程序员想出了如何解决这些问题。

一旦规范编写完成并且开发团队开始工作，我还有两个职责：解决任何设计上的问题，同时还要代替开发人员和所有的团队进行沟通。我要和测试人员解释应该如何工作，并帮助他们做测试计划。我会和文档团队交流，确保他们了解如何写一个好的用户手册。我会和本地化专家一起制定本地化战略。我还要和营销团队解释VBA的好处并和可用性专家一起建立可用性测试。

项目经理会参加很多会议，但不会有比书面规范更多的产出，这也就是为什么作为一个刚走出学校的我仍然能够胜任工作。作为一个项目经理，你不必是一个拥有14年经验的程序员（事实上，有14年的编程经验的程序员，你可能知道了太多细节而不适合做一个好的用户支持者。）

冲突

缺乏一个项目经理，这些聪明的程序员会开发出完全令人费解的用户界面。最好的程序员都非常聪明，但有时候会遇到一些麻烦，想象
一下当不能记住16个命令行参数时会是什么场景。这些程序员通常会倾向于他们的第一想法，特别是当他们已经编写了代码。

项目经理可以添加到软件设计过程中最好的事情之一是，提供第二个关于该如何设计的意见，去考虑那些弱智的用户，他们要求不需要用户手册，不需要定制Emacs-Lisp函数或不需要在脑海中转化八进制就可以使用应用程序。

一个好的项目经理对于UI应该如何工作会有自己的想法，这可能是比开发人员更好或更差的想法，然后需要经过一个长期的讨论。通常情况下，项目经理想要一些简单，易于用户理解的界面，而开发者想要的是实现的简单，提供命令行界面或Python绑定。

在Excel 5开发中，我记得的最具历史意义的争论是关于一个开发人员和项目经理之间的。这个开发人员想要数据透视表浮在电子表格之上的绘图层，而项目经理坚持数据透视表应该在电子表格中。这次争论持续了很长的一段时间，最后，项目经理赢了，而且最终的设计远比一个单独的设计要好。

为了确保争论发生在一个合理的事实基础上，关键的一点是项目经理和开发人员需要结对。如果开发人员报告给项目经理，在某些时候，在争论的某些点上，项目经理有意见时但只是说，“OK，讨论很充分了，现在可以各自行动了。”当他们在结对的工作时，这种情况可能不会发生。这有点像法院：我们不容许任何一方的律师是法官，而且真相最有可能通过公平的辩论而发现。这一点非常重要，开发人员不需要向项目经理报告，除其他事项外，意味着，项目领导者，CTO或CEO都不应该是写规格的人。

大多数公司的一个错误是由项目经理来写规格和设计文档。这是错误的，因为设计没有得到公平评审，不是从争论中得来的，所以并没有想象中那么好。

我很艰难才了解到这些。在Fog Creek软件公司，我做了很多项目管理工作，这是一个持续的工作，需要不断的提醒开发人员，当我说错了的时候要和我争论。这不是一家大公司，但因为有了真正的项目经理最后也变得足够强大，而且程序员喜欢和他们争论。

当然，当程序员和项目经理结对时，程序员往往占据上风。这样的事情发生了好几次：程序员问我关于他和项目经理的一些争论。

“谁去写代码呢？”我问。
“我... ...”
“好，谁去合代码呢？”
“我想还是我... ...”
我问：“那么，到底问题是什么呢？”。“你已经拥有了到最终产品的绝对控制权。你还要求什么呢？“

你看，事实证明，项目经理的负担更大，他需要去说服程序员，因为在某些时候，项目经理会冒些风险，程序员可能会放弃或者自己做自己的而不管项目经理怎么想。因此，要成为高效的项目经理，意味着你有（A）是正确的，和（b）获得程序员的尊重，使他们承认你说得对。

那么如何获得程序员的尊重呢？

作为项目经理，自己编码是能帮助自己赢得尊重的。这是不公平的，项目经理不应该写代码。但是，相对于非程序员来说，程序员往往要更尊重程序员一些，而不管那些非程序员有多么聪明。非程序员也可以作为一个高效的程序员，但是要赢得程序员的尊重需要付出更多的努力。

赢得尊重的另外一种方式是在争论中证明自己的才智，开放的胸襟以及公平的态度。如果一个项目经理做了愚蠢的事，程序员可能认为项目经理是个笨蛋。如果项目经理在做事的过程中掺杂了太多的感情的因素，将会被认为不可靠。最后，如果项目经理玩弄政治，通过与老板的私人会议或者试图分而治之而去赢得一场争论，那么他们会失去程序员的信任。

而当一个项目经理失去开发团队的信任，就意味着游戏结束。程序员们将不再高效，而且按照自己的想法去做。这样会导致更糟糕的代码和时间的浪费，因为除了要付给无效的项目经理薪水外，这些项目经理还会浪费开发人员的时间。

规格文档？这是不灵活的，真的是这样吗？
在很多开发团队中，规范是形式化的产物，整个团队会弥漫着不写规范的想法。这些人是错误的，写功能规格是敏捷开发的核心，因为它可以让你在编码前在可能的设计上进行快速迭代。相较于代码，书面的规范是很少会改变的。写规范的过程会使你思考整个设计过程，而且会帮助你找到设计中的缺陷并尝试其他解决方案。使用功能规格的团队，其产品会设计的更好，因为他们有机会快速探索更多可能的解决方案。同时，他们编码会更快，因为他们有一个清晰的架构。功能规格是如此重要，在Fog Creek的硬性规则之一就是“没有规格就没有代码。”

功能规格所需要的确切形式可能会有所不同。功能规格所要做的是描述程序应该如何运行，而不是说代码在内部应该如何工作。你开始写规格时工作在最高层，用不超过1页纸来描述特性的要点，一旦明确了，就可以开发故事板(story boards)-在屏幕上显示进展以及详细解释它们是如何工作的。对于许多类型的功能，尤其是沉重的UI功能，一旦你有这些故事板，你就大功告成了，这就是你的规格。

要学习如何编写良好的功能规格，请阅读我写的由四个部分组成的系列文章。如果你想看到我写的一个典型规格，你可以下载完整的Fog Creek Copilot规范。
对于更复杂的功能，其中一些故事板有隐藏的行为而且并不表示UI中，这种情况你需要写下更多的细节。在任何情况下，写功能规格会帮助你发现冲突和设计问题，所以当你写代码时，就只会遇到很少的非预期的问题，而这些问题可能会导致重写，或者更糟糕的是，一个不理想的设计。

你需要学习什么来成为一个项目经理呢？
大多数情况下，成为一个项目经理需要：学习技术，学习与程序员交流，并学习如何在一个组织中高效工作。一个好的项目经理结合了工程师的设计能力以及政治家的能力，同时还需要将人们团结在一起。如果你正在学习做好项目经理，这里推荐几本书可以阅读：

我可以告诉大家的是，Scott Berkun的书《Making Things Happen》是唯一一本几乎涵盖所有一个项目经理应该做的事情，所以从这本书开始吧。Scott是一个多年的IE团队的项目经理。

项目经理的工作的另一个重要组成部分，是用户界面设计。可以阅读Steve Krug的《Don't Make Me Think》以及我自己的书《User Interface Design for Programmers》。

最后，我知道这听起来很俗气，但Dale Carnegie在1937年的《How to Win Friends & Influence People》是一个梦幻般的教你如何提升人际关系的书。在Fog Creek，这是我让所有学员在做任何事之前阅读的第一本书，当我告诉他们去读时，他们总是窃笑，但是当他们读完后就都喜欢上这本书了。