😂 IT段子

上线前一天产品经理说要加个功能，我问评估了吗，他说这个很简单。这套流程走下来，我从头到尾又确认了一遍。我把它记进了需求坑位清单，标明"待二次确认"。这条经验值直接拉满

产品经理说「先做出来看看」，这句话价值三个通宵。我想了想，觉得这话没法接。我把这个需求的依赖方列了出来，发现有三个还没确认。那一刻我觉得自己还是很专业的

产品经理：这个交互能不能再自然一点？我：什么叫自然？产品经理：就是那种，你懂的。我拉了个小群，把相关同学都叫了进来。我把这个需求的验收条件写成了文档，产品说先不用。我把这条经验写进了团队 wiki

这个改动从产品视角是优化，从工程视角是重做。我愣了两秒，然后继续敲代码。我发现这个需求的前提是另一个还没做的需求。这大概就是程序员的人生吧

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。我决定先把手上的事情做完再处理这件事。我把这个需求的口径对齐了三次，每次对齐的结论都不同。同事说这波操作可以写进新人培训教材

需求评审会上说好的范围，开发到一半变成了三个需求。我盯着屏幕沉默了十分钟。我发现这个需求的原始来源是一句客户的口头描述。这条经验值直接拉满

这个需求在 PPT 里是三页，落地是三个月。我盯着屏幕，觉得这才是我的一天。我把这个需求的边界整理成了清单，发出去没人回。感动，然后我学到了新的一课

需求文档的更新速度赶不上口头变更的速度。我盯着屏幕，觉得这才是我的一天。我发现这个需求的口径在三个群里说了三个版本。连茶水间都安静了

需求的变更往往从一句「顺便把这里也改一下」开始。我默默记下了这句话。我把这个页面的交互路径缩短了两步，产品说不够完整。复盘会上我们把它列成了案例

需求评审的意义在于让所有人对同一份文档产生不同的理解。我盯着屏幕，觉得这才是我的一天。我把它记进了需求坑位清单，标明"待二次确认"。真香定律准时生效