为什么项目总是延期？——进度管理的核心认知
PMP职场实战108问 · 第21问
为什么项目总是延期？——进度管理的核心认知
你有没有发现一个现象：99%的项目，在启动时都觉得“时间够用”，但最终70%以上都会延期。
我做了十几年项目，从几十万的小项目到上亿的大型系统，没见过哪个项目团队是故意想把项目做延期的。但现实就是这么残酷——计划的截止日，往往只是“理论上可行的那一天”，而不是“实际能完成的那一天”。
为什么？因为大多数人对进度的认知，从一开始就错了。
每周一次"范围偏差记录"该记什么？
PMP职场实战108问 · 第20问
每周一次”范围偏差记录”该记什么？
你有没有经历过这种场景：项目做到一半，老板突然问你“这周进度怎么样”，你翻着Jira上的任务列表，发现明明按计划该交付的功能，开发组还在改需求，测试组还在等环境，而客户那边已经催了三次demo。
你心里清楚——范围正在悄悄膨胀。但你说不出具体膨胀了多少，也说不出是什么时候开始的。
这就是典型的“范围蔓延”后遗症：没有记录，就没有回溯；没有回溯，就永远被动。
很多项目经理觉得范围偏差记录就是“把变更单汇总一下”。但真正的问题在于：你记录的不是偏差，而是结果。 等偏差积累到肉眼可见的程度，往往已经晚了。
为什么你的“记录”总是不管用？
我见过三种最典型的错误做法：
❌ 只记变更单编号。 结果就是每周开会时翻出一堆CR，大家争论“这个到底算不算变更”。
❌ 只记坏的不记好的。 范围缩小、需求删减从不记，导致项目团队永远觉得“只有坏事才值得记”。
❌ 记了但不关联。 偏差记录成了独立文档，跟WBS、进度计划、成本账完全不挂钩，最后就是记了白记。
核心原因只有一个：你不知道该记录哪些维度，才能让数据“开口说话”。
单人单任务、权责清晰——如何分配工作才合理？
PMP职场实战108问 · 第19问
单人单任务、权责清晰——如何分配工作才合理？
你有没有遇到过这种情况：项目启动会上你激情澎湃地分完任务，结果一周后有人跑来说“我以为这是他的活”，或者两个人同时在做同一件事，还有人理直气壮地说“这事没人跟我说啊”。更糟的是，出问题时大家都在推，功劳却谁都要抢。
核心问题其实很简单：你的任务分配，没有做到“单人单任务、权责清晰”。
这不是员工不配合，而是你分配工作的方法有漏洞。
为什么“清晰分配”这么难？
很多人觉得分配工作就是“把活扔下去”，怕说多了显得啰嗦，怕管太细影响积极性。结果呢？模糊地带成了团队内耗的重灾区。
根据我在多个项目中的观察，工作分配不清通常有三个原因：
- 你以为说清楚了，对方其实没听懂 —— 你说了“优化流程”，他理解成了“改文档排版”
- 任务重叠或真空 —— 一件事两个人都能做，或者谁都不想碰的那块没人管
- 责任与权力不匹配 —— 让他管这事，却没给他拍板的权力，最后变成“传话筒”
这些不是态度问题，是分配机制的问题。
WBS拆到"最小可执行单元"是什么标准？
PMP职场实战108问 · 第18问
WBS拆到“最小可执行单元”是什么标准？
你有没有遇到过这种场景：项目启动会上，你激情澎湃地展示了WBS，团队也很配合。但两周后的进度会上，有人突然说：“这个‘用户注册模块开发’还没做完。”你问：“具体卡在哪？”对方挠头：“呃……就是还没写完代码。”——你心头一紧，因为你知道，这个任务已经挂了整整两周，但没人能说清“差多少”。
这不是个例。WBS拆得不够细，项目经理就等于蒙着眼睛开车。但反过来，如果拆成“写出第3行第7个字符”，团队又会觉得你疯了。那到底什么叫“最小可执行单元”？标准是什么？
「做白工」的根源到底在哪里？
PMP职场实战108问 · 第17问
为什么你总在做“白工”？这3个根源，项目经理必须认清楚
你有没有过这种经历：加班加点熬出的方案，领导看了一眼说“方向不对”，直接毙掉；花了两周搞的需求文档，开发说“需求变了，重写吧”；项目做完复盘，发现一半的工作量对最终结果毫无贡献……
做白工，是项目经理最憋屈的事。 辛苦付出，颗粒无收，连个“辛苦了”都换不来。
但真相是：大多数“白工”，其实是你自己允许发生的。
我见过太多PM，把“做白工”归咎于“甲方太SB”“领导太善变”“需求太模糊”。这些因素确实存在，但说句扎心的话——真正成熟的PM，不是想办法消灭所有不确定性，而是在不确定性中提前识别“做白工”的陷阱。
今天我们就来挖一挖：“做白工”的根源到底是什么？
什么是范围基准？怎么建立和维护它？
PMP职场实战108问 · 第16问
什么是范围基准？怎么建立和维护它？
你有没有经历过这种场景：项目做着做着，需求方突然说“再加个报表功能吧，很简单”，你不好意思拒绝，硬着头皮接下了。结果一周后，功能上线了，但原定的核心功能延期了，团队怨声载道，老板问你怎么搞的。
问题出在哪？不是你不努力，而是你手里没有范围基准这把剑。
范围基准，简单说就是项目范围的“法律文本”。 它记录了项目到底要交付什么、不交付什么，并且是经过正式批准、不可随意变更的底线。
为什么很多项目根本没有范围基准？
我见过太多“口头项目”了。需求在微信群里发来发去，会议纪要没人签字，PM自己靠记忆记需求。项目做到一半，谁也说不清当初到底承诺了什么。
三个根本原因：
- 怕麻烦 —— 觉得写文档浪费时间，不如直接开干
- 怕冲突 —— 一写清楚就得拒绝需求，怕得罪客户或老板
- 懒 —— 觉得“大家都懂”，懒得走正式流程
结果就是：谁嗓门大，谁就能加需求。 团队疲于奔命，项目永远做不完。
进度偏差分析怎么写？（附框架）
PMP职场实战108问 · 第28问
进度偏差分析，你写对了吗？
上周，一个项目经理拿进度报告找我：“李哥，我这项目PV是100万，EV是85万，SV=-15万，进度滞后15%。但客户觉得我们干得挺快啊，到底哪个对？”
我看了眼他的WBS，笑了。他所谓的“进度”，全是按花钱速度算的，根本没看关键路径上的交付物是否到位。
这就是大多数进度偏差分析的死穴——用财务数据替代工程实情。
杜绝"攒到月底爆雷"的周同步机制
PMP职场实战108问 · 第29问
为什么你的周报总是“岁月静好”，月底却一地鸡毛？
上周三，技术总监老张在项目例会上拍着桌子问：“这个功能不是说上周就开发完成了吗？怎么今天测试告诉我还有12个Bug没修？”
项目经理小王脸都白了。翻开他的周报，连续三周都写着“开发进度100%”，而实际上，开发团队为了赶节点，把所有Bug都攒着没报。等到月底集成测试，问题像多米诺骨牌一样倒下——延期、返工、客户投诉，一条龙服务。
你是不是也经历过这种“每周都OK，月末炸雷”的循环？
这背后不是某个人的错，而是周同步机制出了问题。大多数团队的周会=流水账汇报：每个人讲“我做了什么、明天做什么”，然后项目经理听完点点头说“大家辛苦了”。这种周会像在集体表演“岁月静好”，而真正的问题——风险、冲突、依赖、延期——被有意无意地藏了起来。
问题的根源只有一个：大家害怕暴露坏消息。
开发怕被说效率低，测试怕被认为没能力，产品怕被质疑需求不清晰。于是所有人默契地选择“报喜不报忧”，等到问题捂不住了，才以“爆炸”的形式出现。
想要杜绝“攒到月底爆雷”，你需要的不是更精细的表格，而是一套让坏消息自动浮出水面的同步机制。
被动加班和盲目赶工的根本解决方案
PMP职场实战108问 · 第30问
为什么你越加班，项目越延期？
你有没有发现一个诡异的规律：越加班，活儿越干不完。
项目进入冲刺阶段，老板说“辛苦一下，顶过这周就好”，你咬牙加班到凌晨。结果呢？第二周又来了新需求，第三周发现前期代码要重构，第四周客户临时改方案……加班成了“常态”，项目却像无底洞。
更扎心的是：加班往往不是“活儿多”，而是“活儿错”。
作为项目经理，如果你只盯着“工时”解决问题，那你就永远在解决“工时不足”的问题。今天这第30问，我们就来扒一扒：被动加班和盲目赶工，到底病根在哪？怎么根治？
不交数据就删号？三星健康事件的背后是AI训练的底线之争
「如果您不同意将健康数据用于 AI 训练，我们将删除您的数据。」
这不是段子，不是钓鱼邮件，而是三星 Health 用户在 7 月 13 日收到的真实通知。
消息一出，迅速冲上 Hacker News 热搜（283 分），评论区炸开了锅。
一个健康类 App，要拿你几十年累积的体重、心率、睡眠数据去训练 AI，你不答应？那好，这些数据你别想要了。
这不是产品设计问题，这是伦理问题。