😂 IT段子

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我在心里点了点头。我把它记进了需求坑位清单，标明「待二次确认」。这条经验值直接拉满

这个需求在 PPT 里是三页，落地是三个月。我不知道该说什么，就笑了笑。我发现这个功能和我两周前做的另一个需求几乎是同一个。连茶水间都安静了

我在群里问了三个问题，得到了四种答案。我在心里把涉及的所有环节都过了一遍。我发现这个词产品经理自己都不确定是什么意思。办公室安静得能听见键盘声

上线前一天产品经理说要加个功能，我问评估了吗，他说这个很简单。我打开记录从头到尾扫了一遍。我把这个功能的原型改了第四稿，产品说回到第一稿。我把这条经验写进了团队 wiki

需求文档的更新速度赶不上口头变更的速度。我笑了笑，决定不解释。我打开了自己的 task 列表，有四个都是同一个需求派生的。果然现实比段子更精彩

需求的变更往往从一句「顺便把这里也改一下」开始。我想反驳，但发现他说得对。我发现这个需求的口径在三个群里说了三个版本。那一刻我觉得自己还是很专业的

我把这个需求拆完，发现它是六个需求粘在了一起。我拉了个小群，把相关同学都叫了进来。我把这个需求和其他几个排了个优先级，全部并列第一。同事说这波操作可以写进新人培训教材

需求的边界在开发中会自己长出来。我不知道该说什么，就笑了笑。我把这个功能的埋点方案提了出来，产品问埋点能不能不要。我把这条经验写进了团队 wiki

我在评审会上提了风险，结论是「先上了再说」。我盯着屏幕沉默了十分钟。我最后按自己的理解做了，产品经理说跟他想的不太一样。办公室安静得能听见键盘声

需求的边界在开发中会自己长出来。我叹了口气，然后打开了编辑器。我把这个需求的技术方案写了两版，选了保守的那版。我把它写进了组内的避坑文档第一章