虽然产品经理与研发团队之间的沟通和协作是项目成功的关键。然而，由于立场和视角的不同，双方在需求评审会上的冲突往往难以避免。
———— / BEGIN / ————
前天需求评审会上，跟研发同学又“小吵”了一架。原因很简单，我想解决问题，他们想“解决需求”；我想推进项目，他们想推掉项目。
咱们来还原一下这个场景。
当时评审的需求是：
场景1：夜班遇节假日，以0点为界限，自动拆分为工作时长（1倍工资）和节假日加班时长（3倍工资）。比如9月30日夜班20:00-次日8:00，期望结果是9月30日工作4小时，10月01日节假日加班8小时。
场景2：节假日夜班，遇工作日，以0点为界限，自动拆分为节假日加班时长（3倍工资）和工作日时长（1倍工资）。比如10月3日（法节）安排夜班加班20:00-次日8:00，期望结果是10月03日是节假日加班4小时，10月04日工作时长8小时。
第一轮“质疑”：干不了？
评审刚开始不久，研发同学就开始了第一轮的“质疑”。
研发说：“需求工作量太大了，计算量太大，我们做不了。尤其是安排夜班时，目前默认都是工作时长，我们的日报、月报等部分，如果要做就得强干。另外，我们需要处理的场景太多了，根本处理不了”。
客观而言，实现该需求确实成本高，预估至少56人日。涉及多种班次类型、日期类型、跨天方式、班次属性等，预计产生48个场景和64个分支。
产品经理（即产品）回复：“嗯，工作量确实不小，所以咱们只聚集解决关键场景。即只做固定班次、只考虑工作日跨法节跟法节跨工作日”。
又问：“日报、月报呢？我们现在的报表结果，都是基于班次的，如果9月30日夜班，只能全部归属于9月30日，不能拆分至10月01日”
PM回复：“咱们先看看工作量，期望还是最好可以拆分，否则用户看报表数据不一致，可能也不太行”
研发问：“做不了，都没有班次，工作时长是用应出勤时长-异常时长-请假时长，怎么生成日报？”
研发小组长在旁友插问：“竞品是怎么实现的？咱们可以看看。”
第二轮“质疑”：竞品实现了吗？
PM说：“主要竞品都实现了，每个系统在建设之初就存在较大差异，咱们即使知道竞品怎么做，参考价值也有限，何况很多细节并不能调研，比如日报是否有拆工作时长”
研发问：“肯定不会这么干，没人会这么处理。”
PM说：“目前没办法调研到这种程度，可能他们确实没这么处理，也可能是处理了咱们不清楚细节，可以再看看”
第三轮“质疑”：你的锅？
研发说：“咱们现在就是在开倒车，需要把去年做的日历功能，完全重做一遍，当时5-6个人干了1个多月，到现在压根就没用到，现在又需要再改回去。”
PM说：“嗯，当时确实考虑的是国际化，所以做了底层日历相关功能，但现在国际化战略不是很清晰，那个确实没办法放开，咱们只能看看怎么处理。比如在它的基础上，封装一个独立的逻辑，单独进行判断。”
研发说：“那你现在可以保证做了这期后，后续不会再做国际化时，又要改一遍吗？”
PM说：“我没办法保证，企业战略可能会发生变化，只能说目前确实没这个规划。”
第四轮“质疑”：不做是不是也可以？
研发说：“这个需求目前只有几家客户，现在也有解决方案，无非就是多创建几个班次，排班繁琐，咱们有必要做这个需求吗？”
PM说：“如果我们要主打制造业，尤其是合资/国际化背景的企业，合规就非常重要。每年大概有11天节假日，每次都需要手动处理的话，效率太低，用户体验也很差。第二，现有的解决方案，员工没办法连班打卡；第三，我们销售环节已经承诺了2家客户，所以做是一定要做。如果工作量大，我可以再调研下客户场景，咱们进一步聚焦场景解决问题。”
大结局
第一，PM又再调研了2家客户需求，明确了关键场景，收敛了需求场景。即从第一轮收敛48个场景到第二轮10个需求场景，最后一轮，收敛到只有3个关键场景。
第二，PM又再调研了2家竞品，通过对应产品手册，明确了它们的解决方案，有一定参考价值，却有限。
第三，PM和研发都进行了一些妥协。比如日报无法处理，但月报一定要处理；所有异常时长、请假时长等，不再100%按0点进行扣除，而是定义规则为“迟到优先扣除第一天时长；早退优先扣除第二天时长”；关键3个场景的改动，工作量大也必须做。
最后，在第二轮评审时，基于以上信息，很快就达成了共识。
反思
你需要深入理解用户场景和竞品研究。避免评审时陷入被动，确保能有效回应研发。
你需要懂得切换视角。评审时，你既需要站在用户视角，坚守底线，也需要站在研发视角，合理取舍。
你需要提前预研。评审前，你最好提前跟核心研发同学沟通，避免所有难题全放到评审会上。
经验：如何说服研发同学？
第一，功夫在平常。产品经理跟研发属于“合作与对立”并存的模式。合作是说属于同一个团队，需要协作解决用户问题；对立是说他们代表各自不同的立场，前者代表用户的理想立场，后者代表企业的现实立场。
因此，日常工作/生活中，产品经理应主动与研发同学建立良好关系，增进相互理解。例如，选择靠近研发团队的工位，参与日常交流；共进工作餐等。后续如果工作中有些“争执”，不至于弄得“老死不相往来”，毕竟合作才是你们的常态，而不是对立。
第二，信息与数据透明。你可能比研发同学掌握更多的信息、数据（比如企业的产品战略变化、用户信息、用户数据等），你应该把它们分享给所有的项目成员（即使有些成员觉得不需要）。
比如每次评审前，我一定会同步最近的信息（包含项目预告、项目背景、产品规划、规划逻辑、产品运营情况等），让他们享有信息权与确定感。
第三，数据胜于雄辩。应依靠数据而非主观观点来支撑论点。与研发讨论时，用数据说话，避免无谓的观点或逻辑冲突。比如客户量、需求数、用户频次、人效、收入等；
第四，讲好用户故事。如果无有效数据支撑，则一定要有一个好的用户故事。坚持代表用户把他们的故事讲好，在关键用户故事上，不能做妥协。比如跟研发同学沟通前，至少需要明确1-2个用户故事（或用户场景）。
第五，拥有一个好心态。应保持“对事不对人”的态度，理解研发同学同样如此。不同角色可能导致不同立场和观点，这是正常现象。将争执和质疑视为交流的一部分，避免人身攻击，保持平和心态，以推进项目进展。
最后，懂得有效取舍。不应固执己见，认为自己的观点绝对正确，不容挑战。在说服研发时，也要重新审视自己的方案和观点，并在用户价值和商业价值之间做出有效权衡和取舍。
作者：邢小作，人人都是产品经理专栏作家
来源微信公众号：产品方法论集散地
题图来自 Unsplash ，基于 CC0 协议
品牌推广｜ 内容撰写｜广告投放｜培训合作