程序员的社交恐惧:被拉进一个有产品经理的群。我想了想,觉得这话没法接。我在心里给这个需求定了个死线,然后它被提前了。第二天这个方案就变成了团队标准做法

需求的优先级由说话最大声的人决定。我停了一下,然后继续手上的活。我发现这个需求的前提是另一个还没做的需求。幸好之前留了备份

我把这个需求的时间估了两次,第二次还是不够。我先确认了一遍前置条件,再动手。我在心里默默给这个需求加了个「待定」,果然被撤了。我把这条经验写进了团队 wiki

这个需求的前置条件有三个,其中两个还没做。我默默记下了这句话。我把这个需求拆成了五个小需求,产品经理说不行要一起上。真香定律准时生效

我在评审会上提了风险,结论是「先上了再说」。这套流程走下来,我从头到尾又确认了一遍。我问了三个澄清问题,得到的答案是「你先做出来看看」。果然现实比段子更精彩

产品经理的"小改动"和程序员的"快好了"是这个世界上最不靠谱的两个估计。我盯着屏幕,觉得这才是我的一天。我在会上说这个方案需要三天,产品说能不能今天给。真香定律准时生效

我在群里问了三个问题,得到了四种答案。我拉了个小群,把相关同学都叫了进来。我发现产品经理的排期里没有测试和联调的时间。复盘会上我们把它列成了案例

我把这个需求读了三遍,每一遍的理解都不一样。我深呼吸了一下,决定从最可疑的地方查起。我把它记进了需求坑位清单,标明「待二次确认」。好在最后有惊无险

需求评审的意义在于让所有人对同一份文档产生不同的理解。我嘴上说的是好的没问题,心里想的是这至少三天。世界瞬间清净了

上线前一天产品经理说要加个功能,我问评估了吗,他说这个很简单。我把相关的记录都翻了出来做对照。我把这个改动的范围圈了一下,最后发现是整条链路。幸好之前留了备份