大家好，我是陈哥。
产品经理为什么不能一次性确定好需求？
这个问题在知乎一直有着很高的讨论度和关注度。
相信做研发的小伙伴或多或少都遇到过这种情况：明明跟产品经理都对接好需求了，一旦开始写代码，对方就突然说需求要调整。
在实际工作中，一次性确定需求这件事，本身就不符合产品研发的逻辑，更违背了我们实际工作的常态。
就像我们平时做一件没做过的事，不可能一开始就把每一步都想得天衣无缝，总要在推进过程中不断修正，产品需求的确定，也是同样的道理。
首先，需求的源头就自带不确定性，产品经理一开始拿到的，从来都不是标准答案。很多人以为，产品需求是产品经理拍脑袋想出来的，其实不然。
需求的来源特别杂，可能是用户反馈、业务方诉求，也可能是市场竞品的动作、公司的战略调整。而这些来源，本身就充满了模糊性和变数。
比如用户反馈，大多时候都是“我觉得不好用”“希望能更方便一点”等，很少有人能精准说出“我需要一个XX功能，点击后出现XX效果”；
业务方今天说要重点做获客，明天看到数据不好，又说要转向留存，诉求随时可能变；
甚至有时候，竞品突然上线一个新功能，原本定好的需求，就必须跟着调整，否则产品就会失去竞争力。
产品经理一开始只能基于这些碎片化、不确定的信息，梳理出一个大致方向，根本没法一次性敲定所有细节。
其次，需求的落地需要多方配合， 不同角色的认知差异，注定了需求要在磨合中完善。
产品经理眼中的好用，是流程顺畅、体验完整；技术负责人关注的可行，是架构稳定、风险可控；而开发与测试关心的 能实现，是逻辑清晰、边界明确。
同一个需求，在不同角色心里往往是不一样的模样，只有坐在一起对齐、碰撞、修正，才能把模糊的想法，变成大家共识、可落地的方案。
这也是我们团队开迭代计划会需要产品经理、技术负责人、开发、测试多方参与的原因。
迭代计划会具体如何开，大家可以参考 《禅道研发流程规范3.0》 ，备注3.0可领取。
还有一个容易被忽略的点：产品研发本质上就是一个从无到有的探索过程。
产品经理在最开始，能把握的只有产品的核心痛点和大致方向，就像我们去陌生的地方，一开始只知道目的地，却不知道路上会遇到什么。
所以，产品经理不可能在一开始就预判到所有可能性，只能边推进、边发现、边调整。
当然，这并不是说产品经理可以随意变更需求，更不是为反复改需求找借口。
真正专业的产品经理，会在一开始就梳理出核心需求和大致框架，尽量减少不必要的调整。同时，会建立规范的需求变更流程，提前和各团队沟通，让每一次调整都有依据、有通知，避免浪费研发资源。
产品研发是在推进中做对的。理解了这一点，研发、测试、产品之间的矛盾会少很多，整个团队的协作效率，也会大大提升。
毕竟，大家的目标都是一样的——做出一款好用、有价值的产品。
