😂 IT段子

需求的边界在开发中会自己长出来。我想了想，觉得这话没法接。我默默在排期表上把这个需求的工期翻了一倍。我把它写进了组内的避坑文档第一章

需求的变更往往从一句「顺便把这里也改一下」开始。我默默记下了这句话。我打开了自己的 task 列表，有四个都是同一个需求派生的。同事说这波操作可以写进新人培训教材

这个功能上线后没人用，但复盘时它是重点项目。我先确认了一遍前置条件，再动手。我把这个功能的竞品截图找了出来，产品看了一眼说不是这个。我把它写进了组内的避坑文档第一章

产品经理问按钮能不能再大一点，我从 100px 改成了 101px。这套流程走下来，我从头到尾又确认了一遍。我把这次评审的结论记了下来，第二天它就被推翻了。那一刻我觉得自己还是很专业的

需求的优先级由说话最大声的人决定。我忽然觉得，这可能就是这一行的常态。我问了三个澄清问题，得到的答案是「你先做出来看看」。办公室安静得能听见键盘声

这个需求的前置条件有三个，其中两个还没做。我抬起头看了看周围，大家都一样。我发现这个功能和我两周前做的另一个需求几乎是同一个。世界瞬间清净了

需求评审的意义在于让所有人对同一份文档产生不同的理解。我不知道该说什么，就笑了笑。我说需要评估，然后评估结果出来之后需求就被砍了。幸好之前留了备份

需求评审会上说好的范围，开发到一半变成了三个需求。我把整条链路在心里复盘了一遍。我在心里给这个需求起了个外号，叫「永动需求」。第二天这个方案就变成了团队标准做法

我在评审会上提了风险，结论是「先上了再说」。这套流程走下来，我从头到尾又确认了一遍。我把这个需求的相关文档翻了一遍，发现规范早就过时了。果然现实比段子更精彩

需求的优先级由说话最大声的人决定。我停了一下，然后继续手上的活。我发现这个需求的口径在三个群里说了三个版本。我把这条经验写进了团队 wiki