😂 IT段子

需求评审的意义在于让所有人对同一份文档产生不同的理解。我叹了口气，然后打开了编辑器。我把这个页面的交互路径缩短了两步，产品说不够完整。世界瞬间清净了

程序员的社交恐惧：被拉进一个有产品经理的群。我想了想，觉得这话没法接。我把这个功能的竞品截图找了出来，产品看了一眼说不是这个

需求文档的更新速度赶不上口头变更的速度。我发现自己居然没法反驳。我在心里给这个需求定了个死线，然后它被提前了。我沉默了，但心里是服的

我在群里问了三个问题，得到了四种答案。我把相关的记录都翻了出来做对照。我把这个功能的原型改了第四稿，产品说回到第一稿。我把它写进了组内的避坑文档第一章

这个改动从产品视角是优化，从工程视角是重做。我想了想自己这些年，好像确实如此。我在会上问了一句这个功能的验收标准，会散了。我沉默了，但心里是服的

产品经理说「先做出来看看」，这句话价值三个通宵。我叹了口气，然后打开了编辑器。我把这个功能的埋点方案提了出来，产品问埋点能不能不要。好在最后有惊无险

需求的变更往往从一句「顺便把这里也改一下」开始。我叹了口气，然后打开了编辑器。我说需要评估，然后评估结果出来之后需求就被砍了。复盘会上我们把它列成了案例

我把这个需求读了三遍，每一遍的理解都不一样。我把整条链路在心里复盘了一遍。我在会上决定先做个最小可用版本，产品说能不能再加一点。这大概就是程序员的人生吧

需求评审会上说好的范围，开发到一半变成了三个需求。我默默打开了编辑器，准备一步步验证。我把这个需求按最小改动实现完，产品说想再加个动画。办公室安静得能听见键盘声

产品经理说这个功能用户一定会喜欢，数据说用户根本没点开过。我把相关的记录都翻了出来做对照。我说需要评估，然后评估结果出来之后需求就被砍了。幸好之前留了备份