尹昉最近把过去几年在工作方式、项目管理、同事交往、技术栈学习这些事上的零散经验整理了一遍。起因很简单，越来越多同事来问我：“为什么自己每天忙得不行，但产出总不明显？”“为什么项目明明按计划走，最后还是会延期？”“为什么新框架学了一堆，真到项目里一个都用不上？”这些问题看着不相关，其实根子都落在一处——你心里有没有一套稳定的做事方法。
我从刚毕业那会儿“接到需求就开写”，到后来自己带模块、跟跨团队项目、再到现在能根据业务反推该补什么技术栈，中间踩过的坑不算少。这篇文章不打算讲大道理，更像是一份“踩坑记录加排查手册”。刚工作一到三年的朋友可以当参考，带新人的技术负责人也可以直接转给组里的同学看。
1. 工作方式：先解决“为什么”，再谈“怎么做”
1.1 拿到需求后第一件事，不是打开编辑器
我见过不少新人，接到任务后特别兴奋，需求文档还没翻完就急吼吼地准备动手。有一说一，我自己刚入行时也这样，觉得马上写代码就是高效。真正让我改掉这个习惯的，是一次被产品经理连着追问三次的经历。
当时的需求是给后台加一个“订单导出”功能。我二话不说，把列表筛选、导出字段、文件格式都实现了。演示的时候，对方问了一句我到现在都记得的话：“这个导出是给谁用的？他拿到之后要做什么决定？”我当场愣住了。后来才知道，这个功能真正服务的是运营主管，他关心的是不同渠道的退货原因分布，用来决定下个月售后策略往哪边倾斜。我要做的根本不是通用导出，而是一张按渠道聚合、带异常标识的统计表。
这件事给我的启发是：任何需求背后都至少有三层信息。
- 第一层，字面诉求，对方嘴上说要什么。
- 第二层，使用场景，谁在什么时间、什么频率下使用。
- 第三层，业务目标，做完这件事要支撑什么决策或动作。
大多数人只接住了第一层，能做到第二层的已经算细心，而真正能让需求少返工的关键，是主动往第三层走。实操中不需要每次都做很重的访谈，问三个问题就够：这个改动是给谁用的？他在什么场景下会打开它？如果达不到预期效果，会带来什么影响？这三个问题能帮你把模糊的期望变成可判断的边界。
1.2 把任务拆成“可交付状态”，而不是“活动清单”
还有一个很隐形的效率杀手，是把任务描述成活动。比如“搭一个登录模块”“了解消息队列”“跟运营对齐需求”，这类描述看起来脚踏实地，实际上没法验收，因为你永远不知道“搭好了”和“了解得差不多了”到底是个什么状态。
我现在习惯把每项任务都改写成“可交付状态”的描述方式。
| 活动型描述 | 可交付状态描述 |
|---|---|
| 搭一个登录模块 | 完成账号密码登录、验证码登录、连续输错锁定功能，附接口文档和主要用例 |
| 学习消息队列 | 输出一份 RabbitMQ 与 Kafka 的对比笔记，并给出当前项目的选型建议 |
| 和运营对齐需求 | 把对齐结果整理成演示版本说明，补充字段口径，并@运营同学做最终确认 |
不要小看这个改写动作。它逼着你在开始前就想清楚“做完到底长什么样”，这比任何进度管理工具都管用。真正把任务做完的定义，不是代码写完了，而是别人拿到你的输出物能直接用、能看懂、能继续往下走。
1.3 估时别太乐观，给不确定性留足缓冲
估时这件事，我一开始也吃过不少亏。不是因为我懒，而是因为我永远按“纯写代码时间”来估。后来发现，一段代码从开始写到最后能上线，中间至少隔着三件事：需求理解偏差、联调等待、以及人总会遇到状态不好的时候。
我知道有人担心报多了会被领导觉得效率低。但根据我的实际经验，领导最怕的不是你说“要三天”，而是你拍胸脯说“一天就够”，结果