如果你对这些产品都不熟，没关系。重点是每个项目的时间表都不同、合作的团队不同、团队的开发/测试人员不同、甚至流程也不尽相同，更棘手的是，所有的产品对我来说都是全新的!和我之前在上海做的产品基本没有任何关系。所以跌跌撞撞地，我就这么上手了。

　　我的第一个改变是把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的核心价值，总结起来应该是：推动项目进程，汇集团队智慧来设计出最好的产品!