😂 IT段子

需求的边界在开发中会自己长出来。我叹了口气，然后打开了编辑器。我打开了自己的 task 列表，有四个都是同一个需求派生的。那一刻我觉得自己还是很专业的

产品经理说这个功能用户一定会喜欢，数据说用户根本没点开过。我默默打开了编辑器，准备一步步验证。我打开了自己的 task 列表，有四个都是同一个需求派生的。我把它写进了组内的避坑文档第一章

上线前一天产品经理说要加个功能，我问评估了吗，他说这个很简单。我重新看了一遍手上的计划，把风险项标了出来。我把这个功能的埋点方案提了出来，产品问埋点能不能不要。感动，然后我学到了新的一课

产品经理：这个交互能不能再自然一点？我：什么叫自然？产品经理：就是那种，你懂的。我先确认了一遍前置条件，再动手。我打开了自己的 task 列表，有四个都是同一个需求派生的。那一刻我觉得自己还是很专业的

需求评审的意义在于让所有人对同一份文档产生不同的理解。我听完沉默了，因为太真实了。我在会上问了一句这个功能的验收标准，会散了。连茶水间都安静了

这个功能上线后没人用，但复盘时它是重点项目。这套流程走下来，我从头到尾又确认了一遍。我在会上提了一个技术风险，会后没人记得。幸好之前留了备份

需求的变更往往从一句「顺便把这里也改一下」开始。我愣了两秒，然后继续敲代码。我把这个页面按产品说的改完了，他说还是原来那版好。感动，然后我学到了新的一课

产品经理：能不能让用户看到更多内容？我：能，把首页砍了都放列表。我先给自己泡了杯茶，做好了打持久战的准备。我问了三个澄清问题，得到的答案是「你先做出来看看」。复盘会上我们把它列成了案例

产品经理说这个功能用户一定会喜欢，数据说用户根本没点开过。我把相关的记录都翻了出来做对照。我发现产品经理的排期里没有测试和联调的时间。第二天这个方案就变成了团队标准做法

产品经理：能不能让用户看到更多内容？我：能，把首页砍了都放列表。我把相关的记录都翻了出来做对照。我打开了自己的 task 列表，有四个都是同一个需求派生的。第二天这个方案就变成了团队标准做法