😂 IT段子

这个需求的目标是提升体验，验收标准却只有一个数字。我抬起头看了看周围，大家都一样。我在心里给这个需求的实际工作量打了三倍。好在最后有惊无险

这个改动从产品视角是优化，从工程视角是重做。我在会上决定先做个最小可用版本，产品说能不能再加一点。这条经验值直接拉满

需求文档的更新速度赶不上口头变更的速度。我停了一下，然后继续手上的活。我发现这个字段在需求里叫法有三种，代码里有五种。同事说这波操作可以写进新人培训教材

这个需求的前置条件有三个，其中两个还没做。我愣了两秒，然后继续敲代码。我把这个需求和其他几个排了个优先级，全部并列第一。那一刻我觉得自己还是很专业的

需求评审的意义在于让所有人对同一份文档产生不同的理解。我叹了口气，然后打开了编辑器。我发现这个交互在移动端根本没法用，但需求里没提移动端。这大概就是程序员的人生吧

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我忽然觉得，这可能就是这一行的常态。我打开了历届需求文档，发现这个需求去年做过一次。幸好之前留了备份

我把这个需求拆完，发现它是六个需求粘在了一起。我拉了个小群，把相关同学都叫了进来。我在群里问了一句这个需求的优先级，然后群里安静了

产品经理：这个需求很简单，就是把页面颜色换一下。我想反驳，但发现他说得对。我打开了自己的 task 列表，有四个都是同一个需求派生的

我在评审会上提了风险，结论是「先上了再说」。我先确认了一遍前置条件，再动手。我把这个改动的范围圈了一下，最后发现是整条链路。我沉默了，但心里是服的

这个需求在 PPT 里是三页，落地是三个月。我不知道该说什么，就笑了笑。我把这个需求的技术方案写了两版，选了保守的那版