我在一家做企业服务软件的 SaaS 公司当项目经理，2023 年春天接了一个客户改造需求。对方要求在三十天内上线一个他们内部专用的审批流。功能不算特别复杂，但涉及权限、消息推送、数据导出，和原本的架构有不少冲突。第一天我就拉了十个人的会，产品说客户合同里写过“积极配合”，技术组长说前端加后端至少四十五天，测试说回归来不及。运营一直盯着我，说这个月 KPI 里包含客户满意度。会议室越讲越安静，最后所有人都看着我。那晚我写了十几版排期，删了又写，最后凌晨一点发了个朋友圈，配了个崩溃的表情。
后来我才慢慢想明白，这道题的难点不在技术，而在于每个部门都在等别人先开口说“可以压缩工期”。技术怕背锅，产品怕客户不满意，运营怕绩效不好看。每个人都想保住自己的那块责任田，于是“难题”就成了一面最好用的挡箭牌。公司制度奖励的是“不出错”，而不是“解决问题”，所以你会看到很多人不是不会做，而是不想做。
我用了差不多一周时间，把需求拆成四十多条字段，画了一张影响关系图。拿这张图找到各个接口的负责人，问他们哪些是硬性依赖，哪些可以绕过，为什么原来要四十五天。最后发现技术时间主要花在等待一个老系统的文档上，那个文档消失了半年。我托关系找到前同事，从旧备份里把文档翻了出来。又把可能的风险列成一个表，每条后面写了“如果推迟，谁会先受影响”。没有讲大道理，也没有催人加班，就是把这个表发给了相关部门，请他们确认。结果两周后功能上线了，虽然还是比客户要求晚了三天，但客户反而说我们靠谱。
这件事让我改变了一个想法。工作难题不是用来“解”的，而是用来“看”的。每个难题背后都有一堆人和一堆利益，你说它是技术问题，它其实是风险分配的问题；你说它是资源问题，它其实是话语权的问题。你越是急着找一个标准答案，越容易掉进别人设好的循环里。我后来给自己画了个坐标系，横轴是某类问题出现的频率，纵轴是牵涉的人数。凡是两个都高的，基本不是技术问题，是组织问题。这种问题靠加班、靠工具、靠流程都治标不治本，只能通过摆利益、画边界、找同盟来疏导。
我在大厂和创业公司都待过，感受最深的是：大厂的难题像一座山，你只能摸到一小块；小公司的难题像一团乱麻，老板拍脑袋的时候，你就是那把剪刀——只是你经常剪到自己。现在再遇到“工作难题”四个字，我不那么怕了。我会先问一句：这真的是难题吗？还是说，只是大家都不想动，于是把它供成难题？如果是后者，那我就不急着解，先陪它坐一会儿，看看周围人的表情，慢慢就看出路来了。这不是鸡汤，是被坑出来的直觉。当然，如果你问我有没有一次失败过，那太多了，只是有些失败，我连提都不想提。
