之前我在一家中厂干了三年，每天就是接需求、写代码、提测、上线。周而复始。
领导对我的评价永远是"靠谱"，但升职加薪永远轮不到我。因为我只负责执行，从不问"为什么要做这个"。
改变发生在一次项目延期。
当时产品经理提了个功能，我按需求文档做完，上线后数据惨不忍睹。复盘会上，产品经理说"用户可能不需要这个"，我当场懵了——那我这三周白干了？
会后我盯着需求文档看了很久，突然意识到一个问题：我从来没想过这个需求背后的真实目的是什么。
产品经理要的是"提升留存"，但给我的方案是"加个签到功能"。这两者之间隔着十万八千里，我却直接开始写代码了。
从那天起，我改了一个习惯：接到任何任务，先问三句话。
第一，这个需求要解决什么问题？
不是"做什么功能"，是"解决什么业务问题"。用户流失？付费率低？还是竞品压力？问题不同，解法完全不同。
第二，有没有更简单的验证方式？
很多需求一上来就是要做个完整功能。但有时候，一个手动后台操作、一个临时页面、甚至一个问卷，就能验证假设。没必要一上来就搞大工程。
第三，如果我是负责人，我会怎么排优先级？
把自己从"执行者"切换到"负责人"视角。这个需求真的紧急吗？投入产出比如何？有没有更重要的事被忽略了？
这三句话，让我从一个"写代码的"变成了一个"解决问题的人"。
半年后，我开始参与需求评审，不是去听安排，是去挑战不合理的地方。一年后，我成了小组长，带两个人。
不是因为我技术变强了——我的React还是那样，Vue也没多精通——而是因为我开始对结果负责，而不是对代码负责。
说点扎心的
很多程序员觉得自己是"螺丝钉"，是因为公司把你当螺丝钉用。但真相是，你自己先把自己当成了螺丝钉。
你只关心代码写得漂不漂亮，不关心这个功能能不能帮公司赚钱。你只关心技术栈新不新，不关心业务痛点是什么。
技术很重要，但技术只是手段。手段再漂亮，方向错了也是白搭。
这个习惯难吗？
不难。就是多问几句，多想一层。
难的是，你得放下"我只管写代码"的舒适区。因为一旦你开始问"为什么"，你就得面对一堆你不熟悉的东西——业务逻辑、用户心理、商业考量。
这些东西没有标准答案，没有文档可查，会让你不安。
但正是这份不安，让你从"可替代"变成了"不可替代"。
最后：
下次接需求的时候，别急着打开IDE。先花十分钟，把这三个问题想清楚。写不写代码，等想清楚了再说。
你会发现，有些需求根本不值得做。👇👇👇而有些需求，你能做出十倍的价值。
