业务要加需求，开发说没时间，产品经理夹在中间两头受气。这不是靠沟通技巧能解决的，而是项目管理的基本功问题。本文从范围管理、进度资源、变更管理、风险沟通四个维度，拆解产品经理如何用项目管理的底层逻辑，在现实约束下找到可执行的解决方案。

前几天带的一个新员工问我，有个项目最开始就跟业务定了范围，计划11月初上线。但是随着业务的发展，原先的方案已经无法实现完整的业务闭环，业务希望能在一期里面加入新的内容，但开发一口咬定说加不了，她现在夹在中间不知道怎么办了。

这是个非常典型的产品经理项目管理问题。做产品的应该多多少少都碰到过。

现实情况是，业务那边确实需要修改边界，开发这边也确实是没时间。

产品经理在中间两头为难。不管是尝试让业务松松口，还是让开发挤挤时间，双方都觉得你没理解人家的难处。

这时候，你再说什么沟通技巧，那就有点扯了。这不只是沟通的事儿，它还涉及项目范围、进度、资源，以及，决定权。

很多人跟我一样，考过软考，考过PMP，这些都会系统地讲项目管理知识。

但考试过了，不代表现实情况你就能解决，不代表教材理论就能处理实际需求。

我在之前的备考文章里提醒过，很多公司的项目管理并不规范，不能觉得自己工作当中一直是这么干的，考试里就一定这么答。

反过来也一样，回到工作里，也不能指着一套流程，指望所有人都按流程按部就班地配合你。

有的公司连专职项目经理都没有，产品经理从需求一路跟到上线。真的要把每份计划、每张表、每个流程都走得一步不差，可能项目还没开始，人已经累死了。

所以在实际工作中，产品经理学项目管理，不是理论越多越好，而是要先理解，这些方法想解决什么问题，它怎么能用在自己的项目里。

下面聊几个我个人认为比较实用的部分。

一、范围管理：先弄清楚，这个项目到底要做到哪一步

1. 先问这次要解决什么问题，再讨论做多少功能

客户提需求的时候，总是希望把所有的问题一起解决掉，越快越好，越全越好。

审批太慢，要优化；数据不好查，要加报表；电脑上不方便，最好再做个移动端。

每次都是，我再加个小点，我再优化个小问题，但堆在一起，工作量就上去了。然后发现，预算不够了，排期跟不上了。

这时候，就需要回头确认，这个项目当前最重要的目标是什么。

假设一期主要解决的是申请在线提交、审批结果可以查询，那么移动端体验、统计报表能做到什么程度，就需要根据实际情况取舍。

但也不能为了缩小范围，把必要的环节删掉。

申请能提交，审批能通过，但支付没打通，整个流程还是完成不了，业务还是没跑通，还是不能算完成。

范围要围着本期目标来定，至少得让使用的人能把一件事办完。

先做“雪中送炭”的事儿，再考虑“锦上添花”。

2. 把容易产生歧义的地方提前说清楚

我觉得范围管理最实用的地方，是让大家少一点想当然。

比如需求里写一个“数据导出”。

产品想的是导出当前列表，业务想的是按筛选条件导出全部历史数据，开发理解的是只能导出当前页。

评审的时候大家都点头，验收的时候才发现根本没说到一块去。

所以，关键功能不能只写个名字。支持什么场景，做到什么程度，有哪些限制，都得说清楚。

暂时不做的内容也要说明。历史数据迁不迁，其他部门接不接，特殊流程支不支持，你不能默认所有人都跟你心照不宣。

小项目未必需要单独写一份很厚的范围说明书，但这些边界得有地方记录，并且让相关的人明确确认。

二、进度和资源管理：排期要能执行，不能只是个花架子

1. 拆解任务，才能知道有什么遗漏

软考里会学到WBS，也就是工作分解结构。

实际用的时候，可以先理解成把一件大事拆开，拆到能够明确结果、分工和估算工作量。

比如“月底完成订单模块”，这个任务很泛。

订单规则谁确认，接口谁提供，前后端分别做什么，测试数据谁准备，旧数据要不要处理，这个任务都会涉及到。

尤其是一些不直接体现在页面上的工作，很容易漏掉。

账号权限、数据初始化、服务器申请、用户培训，平时看着不起眼，到了上线前，缺哪一个都可能卡住。

任务也没必要拆得特别碎。我更建议看一个实际标准：这项工作交给谁，他知不知道要交出什么东西，别人能不能判断他做完了没有。

能做到这一点，再根据项目复杂度细化。

2. 盯进度，重点看哪里在等人、等条件

跟项目的时候，只问完成了百分之多少，跟没问也差不多。

开发说差不多了，可能指自己那部分的代码写完了。接口还没联调，测试环境也没准备，离真正能用还有好几步。

所以可以问得具体一点：现在已经能跑通哪个流程，还卡在哪里，下一步需要谁配合什么。

项目管理里讲任务依赖、关键路径，落实到工作里面，就是要知道哪些事情必须先完成，哪些事情晚了，会把后面一连串的工作一起往后拖。

比如外部接口没给，主流程就没法联调。这个时候，反复催内部开发也没有用，得去解决接口的问题。

有些事情看起来只占半天一天的工作量，但要提前好几周开始跟进，因为中间的等待你控制不了。

同时，开发完成代码以后还要留出联调、测试、修复和业务确认的时间。不能把开发结束日期直接当成上线日期。

3. 看人实际有没有空，也要看成本去了哪里

排期的时候，还得确认安排给项目的人，到底能投入多少时间。

很多时候，一个开发不一定只做一个项目的事情。一个开发在这个项目名单里，不代表他这段时间就都能做你的需求。他可能还有线上问题要处理，同时还有其他两个项目的需求要做。

所以不能光数人头，还得看这个人的可支配时间。

成本也是一样。

比如如果排期紧张，某些功能先不做，让业务每天手工整理。这当然可以是一种过渡方案。但要算一下每天需要多长时间，业务有没有人接，出错以后怎么处理。

我觉得方案里面最容易被省略的，就是这部分。

研发少做了几天，业务却要长期多做一份工作，这笔账得算清楚。

三、变更管理：可以改，但改完以后要重新算账

1. 先判断必要性，别一听新增需求就下意识拒绝

回到开头那个问题。

业务说原来的方案无法闭环，需要先弄清楚，具体断在哪里。

是原来漏了关键环节，还是现在业务发展了，增加了新的场景？是没有它完全办不了，还是能办，只是要多做一些人工操作？

这几种情况，处理方式不一样。

如果原方案确实没法用，拿着最初确认过的文档坚持不改，也解决不了问题。就算你按原来的范围上线了，业务也没办法验收。

但如果原来的范围可以达到最小可行的闭环，业务只是希望把更多事情一次做完，他们效率能稍微高点儿，那就还有讨论的空间。

我的建议是，先和业务把真实流程走一遍。不要在一串功能名称上争优先级，看到底哪一步会停下来，停下来以后有什么影响，有没有可接受的临时办法。

这一步想清楚了，才知道后面该在哪里融合，该在哪里妥协。

2. 把影响和选择摆出来，再找能够做决定的人确认

理论上，需求变更有申请、评估、审批、执行等过程。实际工作中，有正式要求就按要求走；小团队内部的小改动，也可以用更简单的方式完成确认。

但有几件事不能省：为什么改、影响什么、谁同意改。

比如评估后发现，新内容必须做，按原排期又来不及，那么就要带着具体选择去讨论：

• 11月初必须上线，能不能把原计划里没那么紧急的内容挪出去，优先做新的必要内容。
• 内容都要保留，那需要延期多久，会影响哪些业务安排。
• 能不能简化实现、分批交付，或者协调资源，具体能缩短多少时间。

这些需要业务、研发、测试等实际执行的人参与评估。

加人也不是万能的。新人要熟悉业务，有些工作必须按顺序做，不能拿总工作量直接除以人数。

如果评估下来确实没有可行方案，就需要把这个结论及时讲清楚。

我不太赞成产品经理在这种时候，自己先把两边都答应下来，再回去抓耳挠腮。

业务需要什么，是一件事；项目当前能做到什么，是另一件需要确认的事。两边对不上，就要让有权调整目标、日期和资源的人作出取舍。

决定以后，把需求、排期和验收口径一起改掉。

记住，一定要留痕。

四、风险和沟通管理：早点说，也要找对人说

1. 风险没发生的时候，就要开始关注了

很多人觉得，项目还没出问题，提前说可能延期，会不会显得自己能力不行。

但等到真的来不及了再说，那就不是能力的问题了，可能直接就要问责了。

比如下周要联调，外部接口至今没有明确交付时间；月底要验收，业务负责人还没安排人参与测试。

这些都需要提前跟。

理论上可以做风险登记和分析，小项目用一张简单的清单也够。记清楚担心什么、影响什么、由谁跟、最晚什么时候必须有结果。

重点是后面有人继续看着。

如果约定的时间已经过去，接口还是没来，这就成了当前的问题。要推动处理，必要时调整计划，不能继续放在风险清单里当摆设。

汇报也要具体。比如哪个条件没满足，哪项工作因此无法开始，需要谁在什么时候给出什么决定。

单写一句项目存在延期风险，负责人也不知道该怎么帮你。

2. 先搞清楚谁有决策权，别只抓着一个熟悉的人薅

项目管理里有个词，叫干系人。就是那些会影响项目、或者受到项目影响的人。

做B端、G端产品，很容易碰到一种情况：天天跟你对接的人，并不是最后能确认的人。

操作人员很清楚哪里不好用，但可能没法决定业务规则；业务负责人想增加需求，也未必能决定研发资源。

如果找错了人，沟通再积极，也可能一直没有结果。

所以，项目开始时就要弄清楚，需求谁确认，资源谁协调，冲突找谁处理，验收谁说了算。

我觉得所谓沟通能力，有一部分就体现在这里：知道当前需要什么结论，应该找谁拿到这个结论。

当然，找对人也不一定马上解决。需要做的准备还是要做，把问题、影响、可选方案和自己的建议讲清楚，对方才有条件判断。

重要结论留下记录，后续继续跟。发过消息不代表已经解决了，万一人家说没看到呢。

五、质量和收尾管理：上线不代表结束

1. 产品自己先用真实场景走一遍

质量不能全部等测试来保证。

产品方案有没有漏掉关键规则，正常流程走完以后事情有没有结果，异常情况能不能处理，产品经理都需要参与确认。

假设做一个审批系统，提交、通过都没问题，但申请填错以后不能修改，审批人离职以后流程一直挂着。用户用起来，还是会觉得系统不行。

我的建议是，在验收前拿几组真实业务场景走一遍。条件允许的话，让实际操作的人参与。

他们可能第一步就会问出一个产品、开发和测试都没想到的问题。

同时，把上线标准说清楚。哪些bug必须修完，哪些可以后续处理，暂时不修会影响谁，由谁确认。

不能临近上线了，才发现大家对“可以用”的理解不一样。

2. 遗留问题要有人接，复盘要能改掉具体问题

系统发布成功以后，谁接收反馈，谁处理故障，业务怎么使用，遗留功能后面怎么安排，都需要交接。

尤其是为了赶进度留下的临时方案。

人工导数据，谁来导；线下补流程，谁负责；后面改成系统处理，什么时候再评估。

别把所有东西全部塞进二期三期，然后就没有下文了。

项目结束后，也可以简单回顾一下，哪些地方估错了，哪里反复返工，什么条件没有提前准备。

我觉得复盘最没必要的，就是最后又落到加强沟通、提高责任心。

这次因为业务规则迟迟没确认导致延期，下次就把确认人、确认期限和超期处理方式写到计划里面。改进具体一点，才有可能真的用上。

写到这里，其实这些知识大家多少都接触过，有些可能每天都在做，只是没把它和教材里的名词对应起来。

我考软考的时候压根没把所有输入输出、工具和技术都背全，东西太多，后面确实也没时间背了。工作的时候更不可能遇到一个问题，先在脑子里翻一遍标准流程，早忘得差不多了。

但实际在梳理的时候才会发现，其实理论和实际是相通的，先看什么、还缺什么条件、下一步需要推动谁做什么，这些好像多多少少都能对得上。

至于是用Excel，还是用一套完整流程，要看项目大小、公司的要求，以及真正能解决什么问题。

对开头那个新员工来说，接下来需要先把新增内容弄清楚，再和研发一起评估，把选择带给能够决定的人。

产品经理其实是个很杂的岗位，门槛很低，上限很高，什么都得懂点儿，你能做到什么程度，就能跟别人拉开多大差距，就是这样。