如何面对研发人员找你改需求?教你四招巧妙应对!
各位小伙伴们!你们有没有碰到过这种情况?
产品研发过程中,那些聪明的研发或测试小伙伴总是来找你聊需求,哪怕你已经把需求写得跟字典一样清楚,他们还是会“孜孜不倦”地试图说服你改一改。
这时候呢,我发现有些产品经理特别“硬气”,他们会说:“我就按这需求来,出了问题我扛着谁叫我是产品经理。
有些产品经理就稍显弱势,只要研发能安心把活干完,你说怎么改就怎么改。
说到这,大家可能都有点儿迷茫了,这改还是不改,到底应该怎么办呢?
是硬刚到底,还是随他去吧?
其实啊,这两种方式都不太对。
单纯以产品经理的身份去拒绝,或者为了讨好研发而随意改动需求,都不是解决问题的最佳途径。
接下来,我就给大家来分享下关于这个问题的应对策略。
一、研发为什么会找你改需求?
1. 需求设计不合理,存在逻辑实现上的漏洞
对于研发人员而言,一个需求写的好不好,不是去评判对于用户好不好用,而是去研究你写的产品需求文档逻辑上是否严谨。
只要你的原型在逻辑上把该考虑到的都设计出来了,把可能存在的情况都写的清楚了,那研发人员可就挑不出毛病来了,只能乖乖按照你的需求来。
研发人员经常喜欢diss产品经理的是,你设计的这个功能不合理,存在哪些方面的情况没有考虑到。
导致他们写代码的时候,就碰到了一些“坑”,不知道咋处理,逻辑上有点漏洞,代码就写不下去了,写出来也跑不通。
有些测试人员就更喜欢去做这种从需求中“找bug”的游戏了,一旦发现你的需求文档有啥遗漏,,那就得揪着你说道一通。
甚至得把你喊到他坐位边上去,训仔似的教你怎么“写需求”。
然后,把你列入需求文档不严谨的重点关注对象之一,逮着机会就喊你过去,这滋味,真是“酸爽‘啊!(产品经理咋个牛逼,还不是被老子呼来唤去)。
同时,他已经处理占据了有利的位置,会盯着、催着、吵着你赶紧把需求文档完善掉。
催人改东西,和从东西里面找问题,这是测试人员最擅长的两项基本功。
所以,一旦你写的需求文档逻辑上存在问题,就等着被研发和测试来回diss!
2. 功能设计太复杂,实现起来技术难度太大
我们在进行需求评审的时候,研发人员可不是在欣赏你的产品设计设计的多牛逼,他们可是拿着放大镜在找“坑”。
心里盘算嘀咕着:这个功能要弄起来,得新建多少张表格啊?数据要从哪里来?要不要单独跑个任务?跟现有的功能会不会打架?还有哪里没考虑到?逻辑上能不能通?
一通分析下来,大概就知道接下来的一段时间的“砖”好不好搬,烫不烫手。
要是你是一个还算比较好说话,或者经验尚浅容易被说服的产品经理,大概率研发会来找你沟通一下,建议你需求不要这样做设计,可以简单一点,整那么复杂干什么,研发起来多费劲。
我在刚开始做产品经理的那几年,每次设计的需求逻辑规则复杂一点,就会听到研发总监的那句经典语录:“这样设计做不了,要这样做的话,我的整个架构都要改。”
一开始我是迫于人家是总监的岗位不好顶嘴,在评审结束之后立马就去调整需求,但在心里还是会鄙视一番“不就是技术水平不行,瞎逼逼那么多干嘛!”。
后来工作经验多了,和研发也打了几百回交道了。才明白过来,只要稍微复杂一点的功能,“改动太大,做不了”这句话就会伴随着出现。
不是做不了,而是不想做。
当然啦,还有一种情况,研发小伙伴的能力确实不足,把自己的毕生所学都用上了,还是没有办法解决。怎么办,只能两手一摊,凉拌。
告诉产品经理:“我尽力了,但真的做不了。”然后让产品经理想办法,调整需求了。
3. 项目工时太紧张,找产品改需求碰碰运气
每一个项目都有上线的时间要求,就像有个“小闹钟”在耳边嘀嗒嘀嗒地响,项目经理很多时候都是把“赶工”两个字时刻挂在嘴边,鞭策大家抓紧时间干活。
这样带来的一个问题就是,在限定的时间内,研发人员有时候真的是没有思路,如何去实现这个产品功能?
如果想技术实现方式花了一天的时间,那周末可得加一天的班把进度补回来啊!
这种情况下,能不加班那是铁定不加班,人本能的会想着能不能找产品经理这个“甲方”商量下,毕竟是为产品经理做产品(99%的研发都是这种想法,除了不写代码的研发经理)。
只要产品经理同意,自己不就不用加班,何必去绞尽脑汁想解决办法呢?费那个脑子干嘛!
4. 需求性价比太低,做出来没啥价值不划算
研发人员可不是那种“你说啥我做啥”的“机械工人”哦!他们也有自己的工作热情、成就感和小骄傲。
有些功能在他们看来,如果做起来觉得没有什么价值,就会产生抵触心理。
本着为自己工作贴金和为公司节省资源的角度考虑,和你沟通需求的价值问题,这是一种非常合理的心态。
特别是有些功能做起来实现的技术难度太大,需要投入的时间比较多,并且还有一定的风险做不出来。
在他看来做这个功能价值就不大,就会盘算做出来划不划算的问题,也得考虑下保住个人工作饭碗的问题。
二、应对需求改动的四个妙招
1. 化身用户去思考这个需求要不要
往往很多对用户比较友好,产品使用起来比较简单、便捷、智能的功能,其背后实现的逻辑都会比较复杂。
这时候,你的站位就很重要了!
如果你化身成用户,想想这个功能是不是真的很方便、很实用,那么你就会坚定地支持它,哪怕研发小伙伴觉得这是苦活累活。
但如果你站在研发的角度,想着“打工的何必为难打工的”,那你可能就会被研发小伙伴说服,然后妥协一下,调整需求。
一个优秀的产品经理,一定是代表用户来发声,站在用户的角度去设计产品的。
面临研发人员找你沟通需求调整的时候,一个万能的回答方式是“用户说要这么做的”。不要“你觉得”,也不要“我觉得”,只要“用户说的”。
2.坚信一点:99%技术问题都有办法解决
当研发人员告诉你某个需求从技术上搞不定,别慌!咱们来分情况聊聊:
1)现有技术可以实现,只是方法没有找到
有时候,研发人员觉得某个功能难搞,可能是因为他们还没找到正确的技术路径。
这时候,咱们产品经理就要发挥“指路明灯”的作用啦!让研发说说他们的想法,咱们一起找找逻辑上有没有问题。
要知道,解决问题的方法从来都不是“华山一条路”,不一定要在一条道上走到黑,此路不通就换一个角度,换一条道路去试试。
2)现有技术实现不了,需要用新技术解决
要是现有技术真的搞不定,那就得考虑引入新技术了。
比如我们要做一个3D地图,没第三方接口就做不了。这时候就得去找找外部资源,让他们来帮个忙。虽然多了一道工序,但总比放弃强吧!
3)需求实现改动太大,得改现有技术框架
有时候,为了满足某个需求,可能需要改动现有的技术框架。
比如,在一个用FastAdmin框架开发的中台系统里加视频和动画效果,可能就得换个前后端分离的框架。这时候,就得和研发一起商量下,怎么调整需求才能尽可能少地改动框架。
当然,要判断一个功能到底技术上能不能实现,产品经理也得懂点技术知识。要不自己也是两眼一抹黑,脑子一团浆糊,那怎么去和研发沟通技术上如何实现。
3. 时间问题多半是分工或能力问题
时间问题导致的研发希望需求调整,主要涉及到两个方面:
1)本身有别的项目在身,新需求上线时间撞车了
这种情况,咱们在产品需求评审前就得摸清底细,看看研发人员手头是不是已经有一大堆事儿了。
如果这项目非得这哥们儿参与不可,那咱们就得调整项目排期或者重新排序功能优先级,而不是简单地调整需求。
2)需求要求的时间太短,个人技术能力上做不到
咱们在做项目时间评估时,通常就是按人天来粗略算的,但往往没考虑到每个人的能力水平。同样是做一个功能,高手可能两小时就搞定了,而新手可能得花上两天时间。
所以,这种情况下,就需要合理分配项目的人员,进行研发能力的均衡搭配。
有些产品经理可能会觉得,这些问题都是研发总监和产品总监该操心的,跟自己没关系。
千万别这么想!产品经理对产品可是负有“终极责任”的,从研发、销售到交付,每一个环节都跟你有关。产品就像你的孩子一样,怎么能做这么不负责任的爸爸呢?
4. 有没有说出需求价值背后的故事
产品经理对于需求的收集大多是直面客户的,可以通过客户的言谈举止感受到该需求的强烈程度。
可研发的小伙伴们,他们就只能看你们写的需求文档,想象你们描述的“战场画面”,这可就容易产生误会和偏差了。
有时候,你觉得对客户超有价值的功能,可能在文档里没写清楚,研发就一头雾水,完全get不到点。
这时候,产品经理们,你们那口才可得派上用场了!从业务场景、用户、价值等方面,给研发小伙伴们好好讲讲。
他们不像产品经理,接触不到客户,不需要调研市场,很多时候他们也不了解业务,理解能力也稍弱一丢丢,角度跟你不一致,需要多解释几遍才行。
实在不行,那就在调研阶段,直接把研发人员拉过来,让他们一起听听客户怎么说。这样一来,他们就能“身临其境”,更容易“感同身受”了。
当然,要是这个功能背后的客户故事你自己都讲不出来,需求是自己意淫出来的,自认为对客户有价值。
这种情况下,还是趁早改掉吧,研发的资源也很宝贵,经不起大家去实践一些不着边际的想法。
三、最后的话
在产品制作的过程中,难免会有各种声音,有人夸,有人骂,有人给你出主意。
但别忘了,你是产品的“亲爹”,你代表了“客户”的心声。
所以,当各种声音纷至沓来时,你得坚定信念,保持清醒的头脑,做出最明智的决策。
毕竟,你是这个产品小宝贝的“守护神”,得让他茁壮成长,不是吗?
作者:武林,公众号:肖武林
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!