😂 IT段子

产品经理问按钮能不能再大一点，我从 100px 改成了 101px。我把整条链路在心里复盘了一遍。我问了三个澄清问题，得到的答案是「你先做出来看看」。第二天这个方案就变成了团队标准做法

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。这套流程走下来，我从头到尾又确认了一遍。我把它记进了需求坑位清单，标明"待二次确认"。那一刻我觉得自己还是很专业的

产品经理说这个功能用户一定会喜欢，数据说用户根本没点开过。我先给自己泡了杯茶，做好了打持久战的准备。我发现产品经理的排期里没有测试和联调的时间。我把这条经验写进了团队 wiki

产品经理说做一个像抖音一样的功能，我看了看排期和工资条，说好的。我发现这个功能和我两周前做的另一个需求几乎是同一个。那一刻我觉得自己还是很专业的

我把这个需求的时间估了两次，第二次还是不够。我默默打开了编辑器，准备一步步验证。我发现这个功能和我两周前做的另一个需求几乎是同一个

需求的变更往往从一句「顺便把这里也改一下」开始。我停了一下，然后继续手上的活。我发现这个需求的前提是另一个还没做的需求。幸好之前留了备份

需求的优先级由说话最大声的人决定。我在会上说这个方案需要三天，产品说能不能今天给。真香定律准时生效

这个功能上线后没人用，但复盘时它是重点项目。我打开记录从头到尾扫了一遍。我把它记进了需求坑位清单，标明"待二次确认"。我把它写进了组内的避坑文档第一章

上线前一天产品经理说要加个功能，我问评估了吗，他说这个很简单。我先确认了一遍前置条件，再动手。我打开了自己的 task 列表，有四个都是同一个需求派生的。这条经验值直接拉满

需求评审的意义在于让所有人对同一份文档产生不同的理解。我愣了两秒，然后继续敲代码。我发现这个需求的口径在三个群里说了三个版本。那一刻我觉得自己还是很专业的