项目经理最重要的三个能力是什么？硬要回答这个问题，不太好说，因为「能力」这个词太抽象了，聊起来容易变成正确的废话。
换个方式来回答可能更有用：项目经理最该注意哪些事？
搞清楚老板对项目的预期
很多项目经理拿到项目之后，埋头就开始排计划、分任务。这一步其实跳过了一个更重要的事：老板到底想要什么？
同一个项目，老板的预期可能完全不同。有的老板要快，下个月必须上线，质量差一点可以后面补。有的老板要质量，不急着上，但上了不能出事故。还有的老板要功能完整，一次到位，不想分批上线。
这三种预期对应的做法完全不一样。要快，就砍需求、走最短路径。要质量，就留足测试时间，提前跟老板说清楚周期会长一些。要功能完整，就把需求列表锁死，严格控制变更。
很多事情不是你自己能擅自决定的，不是你一个人能拍板的。你必须知道老板的预期，才知道该怎么做取舍。 这句话超级超级重要，就是取舍的问题。当你遇到难题一直不知道如何决策时，老板的预期就很有用，且必要的时候，老板也会支持的。
如果自己默默定了个目标，埋头干了两个月，交付的时候老板一脸困惑：这不是我想要的。不是东西做得不好，是方向跑偏了。这种情况只要在项目启动时花半小时跟老板当面聊清楚，完全可以避免。
一个实操建议：项目启动时，当面确认三个问题。这个项目最优先保证的是什么？有没有不能让步的截止时间？质量标准到什么程度算可接受？把答案记下来，后面所有决策都拿这个当依据。
区分出哪些可以先交付
就算老板说要一个完整的东西，你也不该闷头做三个月然后一次性交付。一个大项目里，总有一些功能是相对独立的，测试通过之后完全可以先上线，不用等所有东西都做完再一起发。
拿微服务架构的项目来说，涉及好几个服务，有些服务的功能边界很清楚，跟其他服务没有强依赖。这部分做完、测完，就可以先上线。没必要等到所有服务都开发完才统一部署。
这样做的好处是，已经上线的部分开始接受真实流量的验证，有问题早暴露。同时剩下还没上线的部分，团队可以集中精力做，压力也更可控。老板那边也能看到项目在持续推进，不是憋到最后才突然冒出来一个大东西。
有些项目经理觉得自己不懂业务，分不清楚哪些能先上、哪些必须等。这不是问题，找懂业务的人帮你梳理就行，产品经理、技术负责人、业务方，都可以。关键是你自己得有这个意识：拿到一个大需求，先想想哪些部分是可以独立交付的，而不是默认所有东西必须一起上。
管住第三方
项目里凡是依赖第三方的环节，大概率会出问题。不是第三方不靠谱，是大家对同一件事的优先级不一样。你的项目是你最重要的事，对第三方来说可能排第三第四。
我的做法是，涉及第三方的部分，单独列一份计划。写清楚每个节点第三方需要做什么、需要提前准备什么、预计交付什么。然后把这份计划同步给第三方，让对方确认。
这样做有两个好处。一是让第三方清楚你的时间线，他能提前安排资源。二是万一某个节点延期了，你有据可查，可以及时把问题上升，而不是等到最后才发现来不及。
跟第三方的沟通，一定要在项目早期启动，不要等到你这边开发到需要对接的时候才去找人。那时候第三方可能还没排期，你就只能干等。早期把计划同步出去，该准备的环境、该开通的权限、该提供的接口文档，第三方都有时间提前准备。
小结
与其讨论项目经理需要什么能力，不如盯住他在项目中实际该做好哪些事。能力是抽象的，做事是具体的。我带过的几个项目回头看，真正让项目稳住的不是什么高深的管理方法论，是这三件具体的事做到位了。很多人花精力去学PMP、敏捷、SAFe这些框架，框架有框架的价值，但实际工作中，项目能不能成，更多取决于你有没有在几个关键节点上做对了动作。项目管理不需要什么神秘的方法论，做对几件关键的事，比学一堆框架有用得多。
希望这篇内容可以帮到你。
最近在知乎出了秒杀专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：
老码头的技术浮生录
它是一个能实际帮你解决难题的星球。