作为项目经理，我手上的项目常年保持在四五个，有的在推新产品，有的做客户定制，还有的在给老系统打补丁。三个项目同时要人，两位发起人都说自己的需求最急，变更通知半夜还在工作群里弹出
项目在变多，多项目统筹因此是成熟的项目经理绕不开的功课。
很长一段时间，我把多项目进行混乱归因于活多、人少，后来才看清，想把这些理顺，靠的不是更拼命，而是掌握全局的方法论，我在这篇文章中总结了多年的经验，希望能对你有所启发。
一、多项目统筹先盘点资源
接手多项目管理之后，我先做的不是排计划，而是把资源盘清楚。人员、设备、外部依赖和时间片逐项列成一张总账，盘点的关键对象是那些稀缺角色，比如资深测试、架构师和运维，他们的时间往往同时出现在三四个项目里。
资源盘点不是登记姓名，而是把争夺摆上台面。哪项联调在等同一个外部厂商，哪个测试环境被两个版本夹在中间，哪位工程师的投入已经明显超出负荷，都该在总账里一眼可见。这一步做扎实，多项目统筹才算有起点。
二、统筹先定项目优先级
资源摊开后，绕不开的问题是先保谁。多项目并行时，决策顺序要排在执行技巧前面，学会再多工具，不如先让发起人一起排出一个先后。
我把在建项目按战略贡献、商业收益、交付风险和客户影响四个维度，请相关发起人一起评估。
排好的清单每两到四周重看一次，市场和内部诉求都会变，旧顺序不一定还成立。
排完之后还要写明两件事：哪个项目占用关键资源的优先级最高，哪个项目可以往后放且不影响主线。敢于让一个项目慢下来，恰恰是统筹在起作用的地方。
三、统筹关键资源的调度
优先级定了，共享资源的安排就成为新的考验。
架构评审、测试、发布这类角色通常横跨多个项目，我把关键资源的占用收拢到一个资源日历里，谁借用、用多久、会不会挤压已有的承诺，都提前留痕。某段时间资源已经排满，就如实告诉后来者，而不是答应之后再推翻。团队成员也轻松一些，不用同时应付几套互相冲突的指令，手上正在做的事少被打断。
四、变更最容易打乱统筹
真正让计划作废的，往往不是估算偏差，而是需求变更。
多项目环境里，临时插进来一个请求，表面只动了项目A，实际会把测试资源从项目B抽走，项目C的联调跟着顺延，一连串影响都藏在暗处。
我的做法是在项目之间设一个统一的变更入口，客户诉求还是内部想法，都先过评审，评估它对每个在建项目的影响之后，再决定接不接、何时接。
紧急变更不是一律拒绝，但要讲清代价，比如明确哪一项会因此延期、哪个版本要调整范围。把选择还给决策者，而不是让变更在项目之间自由穿行。
五、透明是多项目统筹的前提
上面这些做法能不能持续，取决于信息是否对每个人都可见。
但项目数量和团队规模上来之后，手工表格会越拉越费劲，可以借助组织级研发管理平台承接。我把各项目的里程碑、依赖和风险放进禅道的项目集看板中，统览多个项目的整体进度和健康状态，例会只对着这张看板说话，谁在等待、谁已延期、风险到了什么级别，扫一眼就有数。
需要指出，工具只负责让规则稳定运行，多项目健康运行的前提仍然是优先级和变更规则先立住
六、多项目统筹问答
问：多项目统筹和项目集管理是一回事吗？
不完全是一回事。项目集管理把彼此关联的一组项目当作整体运作，目标是拿到单个项目独立实现不了的收益；多项目统筹更常指项目经理或资源负责人在多个项目之间分配资源、排定优先级的具体动作。实操里不必纠结名词，关键看谁在做决策、资源怎么分。
问：项目经理同时跟进几个项目比较合适？
没有统一数字，关键看共享资源的拉扯程度。同一位核心成员每周在几个项目之间反复切换，专注度和交付质量都会下降，这时就该减少并行数或补充人手。各项目之间共享的资源越少，一个负责人能稳定看住的项目通常越多。
问：没有PMO，个人能做好统筹吗？
可以，但范围有限。个人能把资源日历、优先级清单和变更入口管好，覆盖日常协调；当优先级争执反复消耗时间、资源占用长期看不清、多个项目目标互相矛盾时，就需要组织层面站出来裁决。
多项目统筹考验的不是做了多少事，而是能否持续把注意力放在最该推进的目标上。让该跑起来的先跑起来，暂时跑不快的，等一等并不丢人。
若你也在几个项目之间被来回拉扯，不妨从一张资源总账开始，把每个项目占用了谁、占到什么时候先列清楚。相信不久之后，你也能更从容地面对多个项目的统筹管理。
文章标题 ：项目经理谈多项目统筹，真实经验分享 ，发布者 ：项目管理研究院
