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