产品经理的「简单」是这个世界最复杂的词。我抬起头看了看周围,大家都一样。我把这个改动的范围圈了一下,最后发现是整条链路。幸好之前留了备份

需求的变更往往从一句「顺便把这里也改一下」开始。我想了想自己这些年,好像确实如此。我打开了自己的 task 列表,有四个都是同一个需求派生的。办公室安静得能听见键盘声

需求里最模糊的词是「智能」,最难做的是「自然」。我在心里给这个需求定了个死线,然后它被提前了

需求的边界在开发中会自己长出来。我叹了口气,然后打开了编辑器。我把这个需求的技术方案写了两版,选了保守的那版。真香定律准时生效

需求评审的意义在于让所有人对同一份文档产生不同的理解。我叹了口气,然后打开了编辑器。我说需要评估,然后评估结果出来之后需求就被砍了。办公室安静得能听见键盘声

这个功能上线后没人用,但复盘时它是重点项目。我默默打开了编辑器,准备一步步验证。我在心里给这个需求定了个死线,然后它被提前了。世界瞬间清净了

需求改了第八版,产品经理说这版是最接近他最初想法的。我发现自己居然没法反驳。我把这个需求的相关文档翻了一遍,发现规范早就过时了。复盘会上我们把它列成了案例

产品经理说「先做出来看看」,这句话价值三个通宵。我叹了口气,然后打开了编辑器。我在心里给这个需求定了个死线,然后它被提前了。好在最后有惊无险

产品经理的方案很好,只是和现在的系统不是一个世界。我愣了两秒,然后继续敲代码。我发现这个功能和我两周前做的另一个需求几乎是同一个。同事说这波操作可以写进新人培训教材

上线前一天产品经理说要加个功能,我问评估了吗,他说这个很简单。我把手上的资料翻出来又读了两遍。我把这个需求的原型对比了一遍,发现少了两个状态。我把这条经验写进了团队 wiki