做开发以后会发现，很多事情拖着拖着，最后真的就过去了。
不是因为问题被解决了，而是因为提问题的人不再关注，催需求的人换了方向，群里又出现了新的事故。过了几天回头一看，原来那条消息还安静地躺在群聊里，没人再回复，也没人再追问。
刚开始工作的时候，我很容易把所有事情都当成急事。
产品说“这个今天要”，我马上停下手里的任务；测试说“线上有个问题”，我立刻开始查日志；领导在群里问了一句“这个进展怎么样”，我就觉得如果今晚不把代码写出来，明天整个项目都要停摆。
后来才知道，开发工作里最稀缺的东西，往往不是时间，而是持续的注意力。
一件事有没有人持续盯着，有没有人愿意反复确认，有没有人愿意在需求变动时继续承担责任，它才会真正往前走。很多需求在刚提出来的时候声音很大，只是因为当时有人焦虑；过两天焦虑消失了，需求自然也就失去了推动力。
先判断，这到底是不是一个真问题
开发里真正不能拖的事情，通常有几个特点：线上故障还在发生，用户还在报错，数据还在增长，发布流程被卡住，或者某个明确的业务节点马上就要到。
这类问题会自己变严重。你不处理，它也不会安静地待在那里。错误日志会继续增加，客户投诉会继续升级，数据问题会在下一次同步时被放大。它背后通常有明确的负责人，也有明确的损失。
但还有很多事情只是看起来很急。
产品上午说这个版本必须今天上线，下午接口字段还没确定；测试说必须马上修复，最后发现只是测试环境变量配错；有人说老板下午要看，于是你临时做了一套页面，结果下午会议取消，页面也没人再看；一个需求上周还说非常重要，到了这周排期一调整，连提需求的人都不记得它放在哪里。
这两类事情，不能用同一种方式处理。
开发最怕的，不是需求多，而是所有需求都插队
很多人把“马上”当成一种沟通方式，而不是一个经过确认的时间节点。
“先做个版本。”
“很简单，改一下就行。”
“这个不影响你现在的任务吧？”
“先上线，后面再优化。”
这些话听起来都像是在安排工作，实际却没有说明范围、验收标准、依赖关系和失败之后谁负责。
如果开发每次都直接开始写，最后通常会遇到同一套流程：需求没想清楚，先做一个版本；业务临时改口，再返工一次；接口字段发生变化，再改一轮；上线前发现权限和数据都没准备好，只能熬夜补洞。等事情终于结束，大家会觉得这个功能“也没多复杂”，只有写代码的人知道时间到底花在哪里。
所以接到临时需求时，先别急着打开编辑器。可以先问几句：
这个功能具体在哪个场景使用，是演示、灰度还是正式上线？
如果今天做这个，当前版本的哪个任务需要往后排？
这次只需要能跑通，还是要满足完整的异常处理和兼容性？
接口、设计和业务规则谁来确认，最后谁决定可以发布？
问题一旦被问具体，很多“很急”的需求就会开始变慢。不是你故意拖，而是需求终于从一句情绪，变成了一个需要有人负责的项目。
让任务保持可见，但不要立刻把自己交出去
等待不等于摆烂，拖延也不等于失联。
开发真正有用的等待，是让事情保持可见，但暂时停在一个不会失控的位置。你可以在 issue 里写清楚复现步骤，可以先提交一个最小修复，可以把阻塞点标出来，也可以把需要产品或项目负责人拍板的选项摆出来。
比如：
目前问题已经复现，初步判断和接口返回字段有关。我可以先处理前端兜底，但完整修复需要后端确认字段含义。如果今天确认不了，预计会影响周五提测，请先确认这个问题是否高于当前迭代任务。
这样做的好处是，大家都能看到事情没有被丢掉，但也不会默认开发可以无条件吞下所有不确定性。
很多开发的问题不是不会做，而是在需求还没有成形的时候就开始做了。代码写得越快，返工通常越快；接口没定时先接，业务口径没定时先写，最后只是用自己的时间替别人保存混乱。
谁在催，谁负责，谁承担代价
判断优先级的时候，我现在会先看三件事：
谁在催？
谁真正负责这个结果？
如果今天不做，代价会不会继续增加？
产品在群里催，不代表产品会为技术方案负责；测试说必须今天修，也不代表这个问题已经排进发布计划；领导问进展，不代表他已经确认了需求范围。
真正有责任的人，通常会愿意提供信息、确认优先级、协调资源，也愿意在关键节点做决定。只留下一句“先做了再说”的人，往往只是把不确定性转给了开发。
这也是为什么有经验的开发看起来没有那么容易着急。他们不是没有责任心，而是知道一件事情是否值得现在投入，不能只看群里的声音，还要看它后面有没有稳定的负责人和真实的代价。
不是所有问题都值得立刻写代码
开发如果什么都响应得特别快，很容易变成团队里的公共劳动力。
谁都可以往你的排期里插任务，谁都可以丢一个 Bug 过来，谁都可以说一句“先给我一个版本”。你看起来一直很忙，实际上自己的主线工作被切成了很多碎片，最后每件事都做了一点，没有一件真正完成。
但反过来，什么事情都拖，也会失去信任。线上故障、数据错误、发布阻塞、明确的客户问题，这些不能用“等它自己过去”来处理。
真正有用的不是快，也不是慢，而是知道什么时候必须快，什么时候应该等条件成熟。
上线事故要快，需求不清要慢；数据问题要快，临时演示要先确认；影响用户的 Bug 要快，没人验收的改动要先问清楚；流水线被卡住要快，新的“顺手改一下”可以排队。
很多事情过去了，不代表它们本来就重要
有些事情拖过去之后，大家会说：“看吧，最后不也没什么事。”
但这只能说明它原本没有稳定的推动力，不代表所有事情都值得拖。
真正重要的问题不会因为你认真确认两句就消失。线上故障会继续报警，发布阻塞会继续卡住流水线，用户问题会继续反馈。如果一个需求只要你不马上开始写，它就再也没人提了，那它很可能从一开始就没有进入真正的优先级。
开发做久了，慢慢会明白：不是每一条群消息都需要立刻回复，不是每一个“老板要看”都需要连夜开发，也不是每一个需求都值得用自己的休息时间去证明态度。
你要做的不是和每一阵催促赛跑，而是先看清楚这阵风后面有没有一个真实的问题、一个明确的负责人，以及一个不处理就会继续扩大的代价。
很多事情拖着拖着就过去了。
真正需要你处理的事情，不会只靠一句“很急”活着；它会有用户、有数据、有节点、有后果，也会有人持续回来找你。