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