想像这样一种场景，PM安排一个任务给你，但Scope比较广，涵盖到一些你不了解的技术和从没打过交道的Team。那么完成这个任务就要驱动其他Team的同事，但你的级别又不是那么高，说的话不一定有人愿意鸟你。那怎么办，和PM的时间都说定了，难道要动用上级资源来协调？这里总结几种我自己的方法，如果大家觉得有用就不枉此写！
1. 用PM驱动你的方法驱动你的同事
PM怎么驱动你的呢，看看这个谈话：
PM: lake, 有个任务比较急(老大交代任务多数说比较急)，你最擅长这方面的东西，所以我们决定让你完成，这里是需求文档，你看多长时间能搞定？
lake: 公司大概能给多长时间？
PM: 20个工作日，你先看看文档估个时间，如果时间太紧我来协调。
lake: 好的，我先看看，今天下班前给你回复。
于是，看文档，定时间：
1）讨论涉及好几个Team，这个花的时间比较多，定5天；
2）开始Design，如果第一步讨论没问题，2天搞定；
3）Design的文档和所有Team开会Review，包括QA Team。一般两小时，考虑到还有人会提些需要找PM才能解决的问题，加上和PM的确认时间，1.5天；
4）Coding花5天；
5）Unit Test花2天，Integrated Test花1天；
6）QA测试改BUG可能要5天；
这样算算21.5天，还好不算超过太久，看来PM对时间也是评估过的。可是还不能把这个时间预算发给PM，如果发了，其他Team说这个时间不够，到时候就是自己对PM的承诺过头了。应该给PM回信说明客观情况: 有些Team的时间自己估计不出来，需要开会讨论，让各Team的任务负责人自己估时间。下班前给PM一个最迟的答复期限。
PM在和lake定开发计划的前期，是让lake自己估时间，如果项目中发生一些延期之类的事情，只有硬着头皮，牺牲这20天中的双休来加班了。但如果时间是没有商量的PM自己定的20天，最后不能按期交付，lake也只能把估计错误的责任丢给PM了。其实就是用了一个人性的优点，遵守诺言。
2. 不要所有的事情都反映到PM那里，要先弄清楚情况
这是风险控制的一个策略，做的过程中有些是可以通过沟通来控制的。比如合作的Team安排是新手做这个，做的质量和进度落后计划，这个就要自己去和合作的Team协调了，让他们腾出资源来保障。PM不喜欢动不动就去找他解决问题的人，PM这个时候就是老板的心态：只要结果，过程中他参与的越少越好。但有些不可控的事情是一定要尽早找PM解决的，比如说有人跑路了。
3. 记得感谢别人
当任务按时完成后，做的好的PM会发信给所有参与的人感谢大家的努力。但我们国内的公司好像很少有这种氛围的，感谢别人的话好像总是难说出口。老板都一个观点，给你钱你就应该做事情，天经地义，难道还要我感谢你？
但很多外企的文化就有这一部分，我还记得第一次因为一个小的功能添加，不到十行代码搞定的事情，做完后PM发信感谢我的努力时的感觉。所以有机会就感谢帮助过你的人，当面说也许有时候不太好意思，发个邮件总是可以的。QQ聊天的时候对MM需要厚脸皮才能说出来的话都一溜打出来了，发个邮件应该是非常Easy的事情。
知道这些方法的人是很多的，就算以前不知道看过这个也知道了，如果被别人用这种方式驱动，那就积极配合，毕竟解决问题才是最好的结果，助人为快乐之本嘛！