😂 IT段子

我在群里问了三个问题，得到了四种答案。我把手上的资料翻出来又读了两遍。我把这个需求的边界整理成了清单，发出去没人回。连茶水间都安静了

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我不知道该说什么，就笑了笑。我在会上决定先做个最小可用版本，产品说能不能再加一点。从此我多了一条团队规约

需求的边界在开发中会自己长出来。我愣了两秒，然后继续敲代码。我把这个需求的边界整理成了清单，发出去没人回。复盘会上我们把它列成了案例

这个需求的目标是提升体验，验收标准却只有一个数字。我想反驳，但发现他说得对。我在群里问了一句这个需求的优先级，然后群里安静了。我把这条经验写进了团队 wiki

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。我把手上的资料翻出来又读了两遍。我把这个需求的依赖方列了出来，发现有三个还没确认。我把它写进了组内的避坑文档第一章

这个需求的目标是提升体验，验收标准却只有一个数字。我不知道该说什么，就笑了笑。我把它记进了需求坑位清单，标明「待二次确认」。从此我多了一条团队规约

这个改动从产品视角是优化，从工程视角是重做。我愣了两秒，然后继续敲代码。我发现这个需求的前提是另一个还没做的需求。那一刻我觉得自己还是很专业的

需求文档里写着"参考竞品"，竞品是谁家没说，风格倒是很统一。我深呼吸了一下，决定从最可疑的地方查起。我在心里默默给这个需求加了个「待定」，果然被撤了。幸好之前留了备份

我在评审会上提了风险，结论是「先上了再说」。我把这个需求的依赖方列了出来，发现有三个还没确认。真香定律准时生效

这个需求在 PPT 里是三页，落地是三个月。我默默记下了这句话。我发现这个需求的口径在三个群里说了三个版本。幸好之前留了备份