上个月我复盘了一个做砸了的项目，原本计划45天交付，结果用了112天，延期67天。客户那边从天天催变成了不催，我一度以为他们忘了，实际上人家已经找了下家。那阵子我每天加班到凌晨，觉得自己像个救火队员，什么难题都接，什么需求都改。后来才明白，真正卡住我的不是技术，也不是人手，而是我从来不拒绝任何“紧急需求”。
对比一下我们组另外两个同事，一个老周，遇事就往上抛，另一个小陈，遇事就自己扛。小陈连续三个月评优，但年底体检甲功三项全高，老周看着懒散，季度绩效反而一直稳定。我当时嘲笑老周踢皮球，后来发现他之所以不背锅，是因为他在每次接到任务时先问——这个难题的“边界”在哪？谁定义它是个难题？需要什么资源？他有一套自己的追问清单，比如成本、时间、收益是否对等，超了就当场谈条件，而不是闷头开干。说实话，这个清单我现在还贴在工位上，但真正执行起来比我想象中难得多，因为你会担心拒绝后的人际关系。
我学到的一个转变是，工作难题分两种，一种是“真难题”，比如算法没现成方案，要自己研究，有明确终点。另一种是“伪难题”，其实是别人不想决策、不想承担责任，把问题包装成“需要你搞定”。我统计了一下，去年我处理的38件所谓“突发难题”里，有31件属于伪难题，真正需要我深度研发的只有7件。也就是说我80%的精力都耗在了帮别人排雷上，还搭进去口碑。你可能觉得这个统计很粗，但当时我见到一个难题就记一下来源，一个月后回看，发现规律极其稳定。
后来我给自己定了规矩：任何非计划内的需求，先拒绝一次再说。不是真的拒绝，而是给自己留出评估的时间。我会说“我现在手上只有一个固化的迭代版本和两个修复任务，如果进入这个需求，原定哪些可以延后？”通常对方就会自己重新排序了。我还记录每次说“不”后的结果，发现大约有四成需求会消失或缩水，三成会被别人接走，只有三成真正需要我参与。这个比例让我彻底看清了工作难题的真相，也让我从“加班狂魔”变成了能按时下班的人。
说这些不是劝你躺平，而是想表达，工作难题永远解决不完，靠个人硬扛只会让难题越来越喜欢找你。你需要给“难题”本身设置门槛，用边界去过滤那些不属于你的部分。我现在的做法是每周五写一份下周的“拒绝清单”，先计划好我要推掉什么，反而比计划做什么更有效。这样至少当你又一次面对一个“紧急需求”时，你会有底气问一句：这真的需要我么？
