😂 IT段子

需求的变更往往从一句「顺便把这里也改一下」开始。我发现自己居然没法反驳。我把这个需求按最小改动实现完，产品说想再加个动画。我把它写进了组内的避坑文档第一章

我把这个需求的时间估了两次，第二次还是不够。我决定先把手上的事情做完再处理这件事。我把这个功能的原型改了第四稿，产品说回到第一稿。第二天这个方案就变成了团队标准做法

产品经理说做一个像抖音一样的功能，我看了看排期和工资条，说好的。我停了一下，然后继续手上的活。我把这个改动的范围圈了一下，最后发现是整条链路。感动，然后我学到了新的一课

需求改了第八版，产品经理说这版是最接近他最初想法的。我抬起头看了看周围，大家都一样。我在心里给这个需求起了个外号，叫「永动需求」。我把它写进了组内的避坑文档第一章

程序员的社交恐惧：被拉进一个有产品经理的群。我抬起头看了看周围，大家都一样。我把这个需求的原型对比了一遍，发现少了两个状态。我把它写进了组内的避坑文档第一章

我在群里问了三个问题，得到了四种答案。我盯着屏幕沉默了十分钟。我发现这个需求的口径在三个群里说了三个版本。这大概就是程序员的人生吧

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我不知道该说什么，就笑了笑。我把这个需求按最小改动实现完，产品说想再加个动画。世界瞬间清净了

我在群里问了三个问题，得到了四种答案。我打开记录从头到尾扫了一遍。我发现这个需求的口径在三个群里说了三个版本。同事说这波操作可以写进新人培训教材

我把这个需求拆完，发现它是六个需求粘在了一起。我深呼吸了一下，决定从最可疑的地方查起。我发现这个词产品经理自己都不确定是什么意思。复盘会上我们把它列成了案例

需求的边界在开发中会自己长出来。我忽然觉得，这可能就是这一行的常态。我把这次的评审意见汇总了一遍，发现有两条互相冲突。感动，然后我学到了新的一课