要说程序员最痛恨产品经理的原因，改需求想必是排第一的。程序员总是说：“能不能我们先定好，然后就不改了？”，将心比心我们也理解程序员改需求的痛苦，但真的能定好就不改吗？还真不能。
且不说市场瞬息万变这种话，毕竟都听腻了，还有一个微观一些的原因：未来的你一定比现在的你牛逼，所以用过去没那么牛逼的你定下的策略去指导未来更牛逼的你，这种想法从逻辑上就是错的。
既然必须改，那就讨论一些有意义的问题的，怎么改？
要考虑时间
这个修改是否紧急？能否放到下个版本？这是改需求前必须考虑的事，应该尽量避免开发到一半改需求而且上线时间不变这种事。
每个版本都应该有一个需求冻结的时间，冻结后原则上就不再改需求，即使后面想到一些优化的点，也放到下个版本
要考虑投产
投产即改了这个需求能带来什么？
产品经理必须用任何人都能听懂的大白话解释清楚，这本身就是一个考验，如果改这个需求的原因你只能用产品的术语表达，要么是你没想清楚，要么是这是只有产品经理才会在乎的“细节”
充分调研
产品层面的试错成本是最低的，可以做出高保真的原型来给用户测试，确定真的是用户喜欢的才改，在原型层面迭代几个版本，确认达到理想效果了再开发可以让开发事半功倍
反馈结果
任何人都希望自己的付出能够得到回报，这个需求改了用户是什么反馈，市场是什么反馈应该告诉开发，如果每次改需求都能带来正面的反馈，自然就能建立起开发对产品的信任，后面再改需求也心甘情愿的多；如果反馈不好，也应该告诉开发，并复盘整个过程，检讨是哪里做错了
网友评论