😂 IT段子

产品经理：这个交互能不能再自然一点？我：什么叫自然？产品经理：就是那种，你懂的。我把整条链路在心里复盘了一遍。我把这个需求和其他几个排了个优先级，全部并列第一。复盘会上我们把它列成了案例

这个需求的目标是提升体验，验收标准却只有一个数字。我停了一下，然后继续手上的活。我把这个需求按最小改动实现完，产品说想再加个动画。同事说这波操作可以写进新人培训教材

这个功能的灵感来自一个已经不存在的竞品。我不知道该说什么，就笑了笑。我发现产品经理的排期里没有测试和联调的时间。感动，然后我学到了新的一课

这个需求的前置条件有三个，其中两个还没做。我笑了笑，决定不解释。我在心里给这个需求起了个外号，叫「永动需求」。这条经验值直接拉满

这个需求的目标是提升体验，验收标准却只有一个数字。我发现自己居然没法反驳。我把这次的评审意见汇总了一遍，发现有两条互相冲突。从此我多了一条团队规约

需求的边界在开发中会自己长出来。我忽然觉得，这可能就是这一行的常态。我问了三个澄清问题，得到的答案是「你先做出来看看」。第二天这个方案就变成了团队标准做法

这个功能上线后没人用，但复盘时它是重点项目。我深呼吸了一下，决定从最可疑的地方查起。我把这个需求的技术方案写了两版，选了保守的那版。好在最后有惊无险

这个改动从产品视角是优化，从工程视角是重做。我默默记下了这句话。我发现这个功能和我两周前做的另一个需求几乎是同一个。办公室安静得能听见键盘声

需求评审的意义在于让所有人对同一份文档产生不同的理解。我愣了两秒，然后继续敲代码。我把这个需求按最小改动实现完，产品说想再加个动画。世界瞬间清净了

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我把它记在心里，没跟任何人说。我问了三个澄清问题，得到的答案是「你先做出来看看」。我沉默了，但心里是服的