产品一开始不想清楚，之后经常改需求
这要看需求的类型，是加需求，还是改需求。
加需求：如果缺失该部分需求会影响产品的闭环，那双方都有问题，需求讨论会最起码要让产品流程、逻辑无大问题，缺失必要功能的产品无法达到上线的标准，如果不影响，那就需要跟产品协商是当前版本完成还是延期到下一个版本。
改需求：如果当前改动直接颠覆原先逻辑，那就要问清楚，到底是怎么回事，最好有领导确认，再重新排期。
能这么问的一定是互联网公司，外包公司基本没这回事儿，规格说明书可不是说变就变的。
这事儿的本质不是需求改不改的问题，其实是定责的问题嘛。
需求改了，原本的计划时间表要不要推翻？由此产生的延误、Bug 等风险谁来承担？工期变长了要加班怎么办？其实绝大部分人在意的是这些，而不是需求真的改没改。
如果需求即使改了，工期变长就变长你还不加班、到点儿正常走，延误的锅产品自己背，对你的绩效、OKR 等等没有任何影响，那他爱咋改咋改呗，为啥要不爽？
都不想背锅，那就立好规矩。进入开发前，需求想咋改咋改；进入开发后，需求要改，可以，开发要参与评审，不能产品自己说三天改完就是三天；每次迭代小步快跑，周期定短，本周期一旦开始开发，需求锁死，想改，对不起，等下周期再评审吧。
要是一开始就立不下来规矩，要么他走，要么你走，还废话干啥？这都已经不是产品的问题了，是公司在管理层面就有大问题，再待下去只会有更糟心的事儿。
带块转头去上班
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
暂无简介
文章 0 评论 0
接受
发布评论
评论（3）
这要看需求的类型，是加需求，还是改需求。
加需求：如果缺失该部分需求会影响产品的闭环，那双方都有问题，需求讨论会最起码要让产品流程、逻辑无大问题，缺失必要功能的产品无法达到上线的标准，如果不影响，那就需要跟产品协商是当前版本完成还是延期到下一个版本。
改需求：如果当前改动直接颠覆原先逻辑，那就要问清楚，到底是怎么回事，最好有领导确认，再重新排期。
能这么问的一定是互联网公司，外包公司基本没这回事儿，规格说明书可不是说变就变的。
这事儿的本质不是需求改不改的问题，其实是定责的问题嘛。
需求改了，原本的计划时间表要不要推翻？由此产生的延误、Bug 等风险谁来承担？工期变长了要加班怎么办？其实绝大部分人在意的是这些，而不是需求真的改没改。
如果需求即使改了，工期变长就变长你还不加班、到点儿正常走，延误的锅产品自己背，对你的绩效、OKR 等等没有任何影响，那他爱咋改咋改呗，为啥要不爽？
都不想背锅，那就立好规矩。进入开发前，需求想咋改咋改；进入开发后，需求要改，可以，开发要参与评审，不能产品自己说三天改完就是三天；每次迭代小步快跑，周期定短，本周期一旦开始开发，需求锁死，想改，对不起，等下周期再评审吧。
要是一开始就立不下来规矩，要么他走，要么你走，还废话干啥？这都已经不是产品的问题了，是公司在管理层面就有大问题，再待下去只会有更糟心的事儿。
带块转头去上班