😂 IT段子

需求文档的更新速度赶不上口头变更的速度。我叹了口气，然后打开了编辑器。我发现这个需求的原始来源是一句客户的口头描述

产品经理的方案很好，只是和现在的系统不是一个世界。我笑了笑，决定不解释。我把这个交互的原型画了出来，产品说感觉还是不够惊艳

需求文档的更新速度赶不上口头变更的速度。我笑了笑，决定不解释。我把这个需求按最小改动实现完，产品说想再加个动画。第二天这个方案就变成了团队标准做法

产品经理说做一个像抖音一样的功能，我看了看排期和工资条，说好的。我想了想，觉得这话没法接。我打开了自己的 task 列表，有四个都是同一个需求派生的。复盘会上我们把它列成了案例

产品经理：这个需求很简单，就是把页面颜色换一下。我停了一下，然后继续手上的活。我把它记进了需求坑位清单，标明"待二次确认"。第二天这个方案就变成了团队标准做法

需求评审的意义在于让所有人对同一份文档产生不同的理解。我把它记在心里，没跟任何人说。我把这个需求的技术方案写了两版，选了保守的那版。我把它写进了组内的避坑文档第一章

产品经理说「先做出来看看」，这句话价值三个通宵。我愣了两秒，然后继续敲代码。我把这个需求的原型对比了一遍，发现少了两个状态。感动，然后我学到了新的一课

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。我把相关的记录都翻了出来做对照。我在心里给这次的沟通成本算了个数，比开发还高。第二天这个方案就变成了团队标准做法

需求评审的意义在于让所有人对同一份文档产生不同的理解。我默默记下了这句话。我问了三个澄清问题，得到的答案是"你先做出来看看"。第二天这个方案就变成了团队标准做法

需求改了第八版，产品经理说这版是最接近他最初想法的。我想了想自己这些年，好像确实如此。我把这个功能的实现画成了流程图，一看就知道做不完。幸好之前留了备份