😂 IT段子

需求的边界在开发中会自己长出来。我停了一下，然后继续手上的活。我把这个需求的边界整理成了清单，发出去没人回。复盘会上我们把它列成了案例

需求改了第八版，产品经理说这版是最接近他最初想法的。我笑了笑，决定不解释。我把这个功能的竞品截图找了出来，产品看了一眼说不是这个。我把这条经验写进了团队 wiki

产品经理：这个交互能不能再自然一点？我：什么叫自然？产品经理：就是那种，你懂的。我深呼吸了一下，决定从最可疑的地方查起。我把这个需求拆成了五个小需求，产品经理说不行要一起上。我沉默了，但心里是服的

产品经理的「简单」是这个世界最复杂的词。我想反驳，但发现他说得对。我把它记进了需求坑位清单，标明"待二次确认"。世界瞬间清净了

这个需求的目标是提升体验，验收标准却只有一个数字。我想了想自己这些年，好像确实如此。我把这个需求的依赖方列了出来，发现有三个还没确认。我把它写进了组内的避坑文档第一章

需求文档的更新速度赶不上口头变更的速度。我听完沉默了，因为太真实了。我默默在排期表上把这个需求的工期翻了一倍。世界瞬间清净了

产品经理：这个交互能不能再自然一点？我：什么叫自然？产品经理：就是那种，你懂的。我把相关的记录都翻了出来做对照。我在心里给这次的沟通成本算了个数，比开发还高。我把它写进了组内的避坑文档第一章

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。我默默打开了编辑器，准备一步步验证。我把这个需求的依赖方列了出来，发现有三个还没确认

产品经理：这个需求很简单，就是把页面颜色换一下。我发现自己居然没法反驳。我在心里给这个需求起了个外号，叫「永动需求」。我把这条经验写进了团队 wiki

这个需求的目标是提升体验，验收标准却只有一个数字。我在心里点了点头。我把这个功能的入口位置改了三次，最后回到了最初的地方。从此我多了一条团队规约