去年年中，我们部门接了一个客户定制项目。时间紧，需求变来变去，最要命的是，每次开会大家都说‘在做了’，可进度就是不动。我作为项目经理，每天像救火队员一样到处跑——催设计、问开发、盯测试，结果自己累得半死，项目还延期了两周。

那段时间我几乎想放弃管理这条路。直到有天晚上，我在翻一本冷门的日本工程管理笔记时，看到一个词：‘任务漂流’（Task Drifting）。

这个词说的是：当一项任务没有明确的责任人、截止时间和交付标准时，它就会像漂流瓶一样，在团队成员之间来回漂浮，谁都不觉得是自己的事，最后不了了之。

我突然意识到，我们项目的问题不是人不努力，而是任务一直在‘漂流’。

比如，UI改版这个事项，在会议纪要里写着‘由前端和设计协同推进’，听起来很合理，但实际执行中，前端等设计出稿，设计等产品确认，产品又说等技术评估——一圈下来，没人真正‘接手’这个任务。

于是我开始尝试一种叫‘任务锚定’的方法：每个任务必须有且只有一个‘责任人’，不能是‘团队’或‘大家一起’；必须设定一个具体的交付物，比如‘输出3套配色方案PDF’而不是‘优化视觉体验’；还得有一个明确的时间点，精确到哪天下午5点前提交。

刚开始大家不习惯，有人说太死板。但我坚持了一周后，变化出现了：晨会从原来的1小时缩短到20分钟，因为每个人都知道自己该交什么；项目看板上的‘进行中’栏不再堆满三个月没动的任务卡片。

为了支撑这套方法，我也换了管理工具。之前用的是某知名协作软件，功能多得眼花缭乱，但我们真正常用的就三个：待办、进行中、已完成。剩下的审批流、资源排期、甘特图，要么不会用，要么用了反而增加负担。

后来我试了蓝点通用管理系统。它的理念很特别：不预设流程，而是让你像搭积木一样自己定义任务表单、状态流转和提醒规则。我把‘任务锚定’的三要素做成一个标准模板：责任人必填、交付物上传区、截止时间选择器。一旦创建任务，系统自动给责任人发消息，快到期时还会分级提醒。

最有意思的是它的‘漂流检测’功能。如果一个任务超过48小时没被处理，或者多次在两人之间转来转去，系统会标黄并推送给我。有一次，一个接口对接任务在后端和第三方之间‘漂流’了三天，系统报警后我立刻介入，发现原来是对方联系人换了邮箱没通知我们。

我还加了个小规则：每周五下午，所有人打开系统，把本周完成的任务按‘锚定质量’打分。不是看结果多完美，而是看最初的任务描述是否清晰。这个动作慢慢培养了大家写任务时多想一步的习惯。

两个月后，同样的项目类型，我们提前五天交付。客户没察觉背后的变化，但团队成员反馈说‘终于不用天天背锅了’。

其实管理不一定要靠制度压人，有时候，只是把那些看似细小、却被反复忽略的‘责任模糊地带’一点点照亮。任务不再漂流，人自然就踏实了。

现在我带新项目经理，第一课不是教他们画甘特图，而是让他们回忆最近一次‘我以为他做了，他以为我做了’的经历。大多数人都能说出一两个故事。然后我会说：我们的目标，就是让这种故事越来越少。