穿越成长:我在微软总部的丝绸之路（一）
略过连绵的皑皑雪山，飞机徐徐停落在西雅图机场的那一刻，我知道我的生活将翻开崭新的一页。从未在上海以外的城市居住过的我，带着两个装满了生活用品的大箱子，我的兴奋和期待在西雅图潮湿的空气里蔓延开去。在这里，我为期六个月的丝绸之路即将展开。
我有很多师傅
尽管不是第一次来微软总部工作，却是第一次拥有挂有我铭牌的办公室。来之前，我师傅(Mentor)就为我安排好了办公室。和我同屋的是一个同组的PM，一个开朗的印度小伙子。有些人喜欢独享办公室的私密，我倒是很开心有人可以一起工作和聊天。一个人呆在屋子里未免有点孤单！
师傅的办公室里有一张特别宽敞舒适的大沙发。洒满阳光的午后，靠着柔软的沙发，每周在师傅的办公室里和他的一对一谈话都是我最享受的时光。我的师傅是一位资深项目经理（PM）主管，他参与过许多产品的设计开发，有强烈的客户至上的理念，对客户需求和市场情况都有深刻的洞察。可以说，他绝对是我的偶像(Role Model)！每次和他聊天， 我都能深深体会以用户需求为本的设计理念，以及他对于每个设计细节的关注。尽管我们不在同一个功能团队里，但他总能对我正在设计的功能提出好的建议和想法，并提醒我关注一些还没考虑到的情况，这也促使我对自己的每个设计都反复斟酌、精益求精。阳光、沙发、和师傅的谈话，这一场景已如同定格的影像留在我心里。如今我已回到上海，但每次设计功能或与客户交流时，我都会先问问自己，如果是师傅的话，他会怎么做、怎么说？
之前，我和师傅的谈话都通过电话沟通，有时候会错过许多表情和肢体的语言。到了美国之后，面对面交流的机会让我更加感受到沟通不仅是有益的，也应该是非常令人享受的！
除了师傅，我还与其他功能团队的许多资深和高级PM主管进行了交流，这都得益于我在上海的经理为我牵线搭桥，让我充分利用在美国的机会多学习、多交流。因为身处不同团队的关系，我常常跑到其他办公楼里去他们的办公室聊天，这也让我有机会顺便参观了其他团队的走廊“风景”。例如，在TFS团队的走廊里贴满了大大小小的图表和照片，有的是团队进度表，有的展示Team Foundation Server（TFS）使用情况，还有团队外出活动的有趣照片，更有记录着客户对TFS需求的列表！相信团队成员每次经过这个走廊都会提醒自己客户需要什么，也会为自己的工作而自豪！
和这些PM主管的聊天同样令我受益匪浅。我们大约每两到三周见一次面，聊的内容比较随意。有时我会给他们讲我正在做的产品/功能，而几乎每次我都能从中得到额外的收获。虽然我们在进行不同产品的设计开发，但他们往往结合以往经验或他们的产品角度给出全新的建议和看法！这一过程使我学习到如何从不同的角度来看问题，也令我再次感受到：对不熟悉的产品，也能提出设计的思路和想法，看来PM对产品的设计完全出自本能！
我需要三头六臂
到了美国之后，我有机会参与到多个产品项目中。合理安排好多个同时进行项目的工作，是我在上海工作中没有尝试过的。有时候，我真觉得自己需要三头六臂才能把事情做完！然而，多任务并行的能力恰恰是PM需要具备的关键素质，所以我很珍惜这难得的历练机会。
我当时（同时）参与的项目有这样几个 –
- Pro Tools 功能在Visual Studio 2010 Beta1里的 发布
- 一个Pro Tools的设计变更(Design Change Request, DCR) – 与SQL Server团队合作
- RIA Services工具 （实时提供智能标签功能） – 与RIA Services团队合作 (现已改名WCF Services)
- SharePoint 扩展开发工具 – 与SharePoint团队Developer Platform Evangelist合作
如果你对这些产品都不熟，没关系。重点是每个项目的时间表都不同、合作的团队不同、团队的开发/测试人员不同、甚至流程也不尽相同，更棘手的是，所有的产品对我来说都是全新的！和我之前在上海做的产品基本没有任何关系。所以跌跌撞撞地，我就这么上手了。
我的第一个改变是把Outlook日程表里的每个会议项用颜色区分开。每个项目的会议都用同一种颜色表示。这样做的好处是，首先我能大致了解每个项目花了我多少时间，另外每次会议前我能提醒自己迅速切换到相关项目中去。与此同时，我也要与上海团队继续保持沟通，下面的日程表里红色方框标识的就是我和上海的会议时间！
其次，我抓紧一切机会读文档、熟悉产品功能、穿梭于园区的不同办公楼之间以了解所合作的团队。当然，这其中我得到了许许多多同事的无私帮助，对于我这个来自上海的小PM，他们给予了无比的耐心为我答疑解惑，还花时间为我介绍这些产品的背景知识。
几周之后，我慢慢步入正轨，融入了团队也同时为每个团队设定了对我工作的合理预期，也就是我能为每个项目分别花上多少时间，以及我能为每个团队贡献什么。对于这一点我的感触很深，奔波在多个项目之间的PM很多，如果没有给团队正确的预期，可能会导致团队的不理解。比如项目A的团队正期待我两天内完成他们的Functional Spec（功能规划书），而实际情况是我还有50%的时间会花在项目B和C上，所以我得一周后才能完成这份文档。对我来说，这是很自然的事情，但是如果我的团队A不了解这一点，他们可能会抱怨我的效率太低！J
另一个让我感触良多的是，这个过程促使我再一次思考了PM对团队的核心价值。这其实是我从成为PM第一天起就一直思考的问题。曾经以为，PM一定是团队里最了解产品的那个人，PM将自己的想法编写功能规划书交给开发和测试人员实现。然而事实是，这并不是PM的全部意义。根据团队和项目的不同情况，对PM在团队所起作用的期待也是不同的。
就拿我参与的SharePoint扩展开发工具项目来说，参与者有多位来自Visual Studio团队的主管、来自SharePoint团队的资深DPE、对SharePoint有丰富开发经验的工程师，而我，是两周前还对SharePoint扩展开发一无所知的PM。尽管我努力学习，但依然注定不可能在短期内成为团队里对产品最熟悉的人。即便如此，团队仍然需要我。我定期将所有人召集到一起开会讨论功能设计、了解进度、讨论可能的问题，和其他的项目不同，这次我不能主导讨论，但我会仔细总结我所听到的和理解的，确保团队里的每个人理解一致。我还要保证会议上提出的每个问题都有人跟踪直到解决。我也完成了功能策划书，但并不是传统意义上PM对产品的设计，而更像是大家讨论的智慧结晶。
这个项目之后，当我反思这个团队为什么需要PM的时候，我忽然意识到困扰我的PM的核心价值问题似乎得到了解决。PM不见得是团队里决定一切的人，每个微软的工程师都很聪明，每个人也都渴望为产品贡献自己的力量，而PM要做的，不过是汇集所有人的智慧，设计出最好的产品 – 想法可以是PM的，更可以是每一个团队成员的 – 只要是对用户最有益的。而PM的核心价值，总结起来应该是：推动项目进程，汇集团队智慧来设计出最好的产品！
未完待续，敬请期待…