如果你还不知道微软PM职业的历史，那么你可以先阅读Steven Sinofsky写的这篇文章。和Steven一样，几年前，我从SDE转变为PM，这是一段很有启发性的旅程。

　　首先，一个伟大的PM，360度无死角地了解他们工作的产品。当然，一开始的时候，你可能会想——“既然我的目标是这一个功能，那么我将重点放在这个功能上就好了”。是，也不是。你会发现自己正陷入一大堆的产品难题中，你的问题需要在更大范围内才能完美地解决。这意味着你需要知道产品的使命是什么，哪些关键部分构成了这个使命并推动了这个使命的发展。我们很容易给自己画一个范围——但请不要这样做。不要再有诸如“那个不是我负责的，我不管”的想法——可能这个不是你负责的，但是你得明白没有一个功能是独立的。

　　在你刚开始你的事业，或刚过渡到PM角色(也许是同一个团队，也许是不同的团队)的时候——在水平化的产品空间上构建工程和管理的密切关系。就像我在《my PM internship at Microsoft》这篇博客中提到的，关键是你要敢伸出手去学习，学习再学习你正在工作的产品，尤其是这个产品已经在市场上扩张过一段时间了的。谁是你的用户?他们有什么习惯?有哪些首要的交叉问题?你需要开阔自己的眼界去认识到，你发布一个看似封闭的组件会产生多大的影响。

　　另一个我认为伟大的PM需要具备的特点是应用软技能的能力。如果你还不知道软技能的意思(想要知道更多，可以看这篇文章)，那么我告诉你，软技能至关重要的是培养沟通技能，培养团队合作的能力，展示信心，耐心，演讲技巧，最重要的是——要对客户感同身受。项目经理往往是一整个项目的代言人——你表现自己的方式就是你表现产品的方式。此外，产品的目的是提供价值给最终的用户，所以你绝对必须紧密联系那些真正使用团队工作成果的人。

　　再谈一谈在一定程度上的多面手。这在不同的团队，组织，甚至公司之间可能都会有所不同，但我坚信，一个伟大的项目经理得能够在需要时快速地学习和转换环境。从我自己的经验来看，我常常需要写规格说明书，经常需要为团队编写代码和构建工具(如Hummingbird)。一个伟大的项目经理不会回避这些并非100%属于这个角色的事情。是的，当然——在面对这些其他事项的时候，你得确保将事情按优先顺序安排好，还有平衡责任，使得能对产品和公司产生最积极的影响，但这往往意味着需要跳出项目经理刻板的思考方式。

　　还有一点很有趣的是，之所以会创造PM这个角色，是因为工程师同时需要做太多的事情，有太多与产品相关的任务需要他们解决，白天的时间完全不够用。引用上述Steve帖子中的话：

　　项目经理一职起始于微软为Macintosh开发Excel的时候。当时公司面临的挑战是，我们不知道该如何推动技术的艺术状态(使用新的图形用户界面的概念开发一个标志性的新OS)，开发人员在努力开发新的电子表格和建模算法的同时，根本就挤不出时间去做打印、展示、显示图形等工作。

　　所以本质上，PM是负责看赛马，分析数据，并确保他的马(在这种情况下——指的是产品)具有最佳的品质，能够一直取得成功。为了做到这一点，一个很大的PM必须能够快速评估进程的不同方面，并在必要时作出调整。这在现在比10年前更为重要，因为现在如果产品开发或规划中出现失误的话就会耗资数百万，并且结果除了浪费时间之外，毫无裨益。

　　伟大的项目经理不是因为等级制度的利益而存在，而是为了带动产品的更大视野。大约是在去年的同一时间，Zach Watson发表了一篇名为《Are Project Managers Irrelevant》的文章(于是，我认识到Project Manager!= Program Manager)，文中的观点是：

　　我们现在越来越明显地看到千禧一代(1980年后出生、在优渥环境下长大的一代)——将成为今后几十年的主要劳动力，他们并不仅仅是因为等级制度带来的好处而喜欢等级制度。他们对技术的不断追求出自于内心对精英体制的渴望——即使某人有更高的头衔，千禧一代也并不会认为这个人的专业知识永远正确。

　　上面的例子说明了项目经理被定位为具有一定优越度的员工，统领他下面的一切事务。但是PM的情况又有所不同，PM沉湎于产品和公司文化，一种他们的团队有许多共生链接却没有必要堆叠在彼此的顶部的公司文化。期望工程师站出来对执行用户研究，驱动科研需求，分析产品情绪，分析传入的遥感数据等许多在实际构建产品时的职责负责，是不切实际的。上面那篇文章随后谈到了以下这个领域：

　　在这个意义上，项目经理不再履行其作为辅助人员的角色，而是成为了创新和生产力过程中的推动力。在敏捷性被等同于创新的领域中，压制团队成员的速度被视为不可饶恕。

　　不让项目经理担任辅助人员是一个组织问题，而非角色问题。如果你想要为组织找辅助人员——那可以通过严格的面试以及面试后工作来筛选。要充分认识到，项目经理并不是为了跟踪时间和微观管理产品的每个方面，恰恰相反的是，项目经理得能够让他们的工程团队在产品生产中实现100%的潜力，同时确保应用潜力到正确的事情上。

　　有一个蛮有趣的观点，一篇来自于《Harvard Business Review》的文章详细介绍了2002年谷歌如何决定精简他们的组织：

　　在Google创办的早期，整个公司的人都在纷纷质疑经理人的价值。这种怀疑源于一种高度的技术官僚文化。作为一个软件工程师，Eric Flatt这样说道，“We are a company built by engineers for engineers(我们是一家由工程师为工程师而创建的公司)”。并且大多数工程师，而不仅仅是那些谷歌的工程师，更希望把时间花在设计和调试上，而不是与老板沟通或监督其他工作人员的进展。在他们的心中，他们深信，管理弊大于利，会干扰具体的、以目标为导向的任务。

　　在公司设立了PM一职若干年之后，创始人Larry Page和Sergey Brin开始怀疑谷歌是否真的需要任何经理人。因此2002年的时候，他们试行了一个完全扁平化的组织结构，摒弃了工程管理人员，目的是为了打破壁垒，加快思想开发，复制他们在研究所自由的共治氛围。此次实验仅持续了几个月：他们后悔了，因为有太多的人直接去找Page报告有关费用，人际冲突，以及其它具体细节性的问题。随着公司的成长，创始人很快意识到，经理在许多其他重要的方面作出了贡献——例如，通过沟通策略，帮助员工优先安排项目，促进合作，支持职业发展，确保进程和系统与公司的目标一致。

　　无论正在开发什么样的产品，总需要比工程面对更多的面孔。而这正是真正伟大的项目经理大放异彩的地方。现实的情况很简单——PM，在默认情况下，授予了足够的灵活性，但在同一时间——有其职责，定义了他或她的角色。

　　伟大的项目经理是可以培养的——我正在努力成长为一个最好的PM——这里有一个学习曲线，该曲线可以让你尽快进入PM这个角色。从长远来看，这将帮助你提升团队的价值，并爱上这种驾驭团队的感觉。

　　最后但并非最不重要的一点是，一个伟大的PM总能找方法来实现目标。底线是——要有交付成果，否则你发多少封电子邮件，安排了多少次会议，和多少人交谈都毫无建树。在这种情况下，你应该了解周围环境，制定相应的计划——你需要联系谁，什么时候需要一些额外的帮助，以及什么时候终止功能和组件的业务?

　　上面该说的也已经说完了，我尽可能长话短说，并侧重于在过去一年半时间里我注意到的帮助了我很多的关键环节。也许一年后，我会再想回来修改这篇帖子，添加更多的经验和教训。当然，各位如果有什么好的意见和建议，也请不吝指教。

　　文章译者：小峰 来源：码农网

产品经理在广度和延伸性上，要求会更高一些。
广度：不仅需要对各阶段的项目进行把控，还可能在前期策划和后期销售环节参与，涉及到产品的整个周期。
延伸性：在相同产品上的管理和经验，更容易迁移。