这时候你的站位就很重要了！ 如果你化身成用户想想这个功能是不是真的很方便很实用那么你就会坚定地支持它哪怕研发小伙伴觉得这是苦活累活。 但如果你站在研发的角度想着“打工的何必为难打工的那你可能就会被研发小伙伴说服然后妥协下调整需求。
个优秀的产品经理定是代表用户来发声站在用户的角度去设计产品的。 面临研发人员找你沟通需求调整的时候个万能的回答方式是“用户说要这么做的。不要“你觉得也不要“我觉得只要“用户说的。 坚信点技术问题都有办法解决 当研发人员告诉你某个需求从技术上搞不定别慌！咱们来分情况聊聊 现有技术可以实现只是方法没有找到 有时候研发人员觉得某个功能难搞可能是因为他们还没找到正确的技术路径。
这时候咱们产品经理就要发挥“指路明灯的作用啦！让研发说说他们的想法咱们起找找逻辑上有没有问题。 要知道解决问题的方法从来都不是“华山条路不定要在条道上走到黑此路不通就换个角度换条道路去试试。
现有技术实现不了需要用新技术解决 要是现有技术真的搞 西班牙 whatspp 数据 定那就得考虑引入新技术了。 比如我们要做个地图没第方接口就做不了。这时候就得去找找外部资源让他们来帮个忙。虽然多了道工序但总比放弃强吧！ 需求实现改动太大得改现有技术框架 有时候为了满足某个需求可能需要改动现有的技术框架。
比如在个用框架开发的中台系统里分离的框架。这时候就得和研发起商量下怎么调整需求才能尽可能少地改动框架。 当然要判断个功能到底技术上能不能实现产品经理也得懂点技术知识。
要不自己也是两眼抹黑脑子团浆糊那怎么去和研发沟通技术上如何实现。 时间问题多半是分工或能力问题 时间问题导致的研发希望需求调整主要涉及到两个方面 本身有别的项目在身新需求上线时间撞车了 这种情况咱们在产品需求评审前就得摸清底细看看研发人员手头是不是已经有大堆事儿了。
如果这项目非得这哥们儿参与不可那咱们就得调整项目排期或者重新排序功能优先级而不是简单地调整需求。 需求要求的时间太短个人技术能力上做不到 咱们在做项目时间评估时通常就是按人天来粗算的但往往没考虑到每个人的能力水平。