作为一名产品经理,你一定遇到过与开发意见不和的情况,例如:这个需求究竟合不合理,能不能赶一赶排期等等。天天问小伙伴则遇到了“研发觉得影响不大的样式差异不算 Bug ”的这个问题,一起来看看大家提供了什么好的解决方法吧~
程序员,作为产品经理打交道最多的对象之一,在工作上遇到摩擦,那可再正常不过了,比如一产品哥们就遇到了“开发觉得影响不大的样式差异不算Bug”,双方僵持不下的问题。
还在气头上时,产品经理也许想的是:“如果开发在这个问题上能说了算,那岂不是既当裁判又当选手了?”
等冷静下来就会发现,还是解决问题要紧。当下之急,是要知道程序员为什么会这样想,再对症下药。
这篇文章,我们就和各位伙伴们来探讨探讨,开发不配合做调整时,产品经理应该如何应对?
天天问每周精选第203期:研发觉得影响不大的样式差异不算Bug,怎么破?文章内容部分来源于@rkqzzz @非思不可 @林林 @冰雨幻天 @小君毛 @Jarvan156 的精彩回答。
一、为什么开发觉得样式差异不算Bug?
为什么开发觉得影响不大的样式差异不算 Bug 这个问题,可能是以下三个原因造成了摩擦。
(一)双方对 Bug 的理解不同
对于开发人员来说,只要不是写的代码逻辑有误,报错走不通,都不算 Bug 。而对于非开发人员来说,只要是与需求不符合就算 Bug ,不管是逻辑方面还是界面样式方面,只要不符合需求就是 Bug 。
如同水龙头坏了,开发觉得换个不漏水的水龙头就行,而产品经理坚持要换黑色磨砂质感的水龙头是一个道理。产品经理和开发两个角色各自对 Bug 的定义不同,这是长久以来大家经常争论的一个点,至今没有定论。
(二)“好看”不一定“好用”
产品设计重在体验,而体验的第一道门槛便是交互设计,而非外观设计。
好的设计大家都想追求,不过“好”是有代价的,要人力,要预算,要时间。再者,好看的产品很多,但是好用的产品不多,比如在设计网站上,我们常能看到很多好看的设计,但如果直接做成完整的产品,也许会发现很多操作很空洞、界面很虚无,这是想象和实际的差距。
于是,“好看”不一定“好用”,外观设计就不是首要考虑的因素了。
(三)100%还原设计稿的难度极高
根据一位做前端开发的伙伴所言,样式差异在他眼中的确不能算什么BUG。
为什么这么说呢?他表示,高精度设计稿一般是还原8成以上算合格,9成以上就是精细还原了。设计稿是静态图,而设计稿很多的效果,在手机上是无法实现或者实现代价很大,比如磨砂、透明度、自适应排版等等。平台的硬件性能决定了渲染一张 jpg 很简单,渲染一个等质量的 gif 则要困难得多,更别说有很多交互事件要做。
100%还原设计稿?这大概是一场美好的想象。
二、如何与开发协调解决?
如果要呈现最好的产品,少不了两方操刀手——产品、技术协同沟通,在大方向不偏离的情况下,做好本职工作,可以沟通协商的点尽量协商完成,在我们都无法成为下一位乔布斯的时候,还是好好为产品本身负责,毕竟这份作品是团队实实在在花时间和精力去做的,需要自己的荣誉和责任感。
OK!鸡汤灌到这里,下面奉上不同原因对应的解决方法。不仅仅是上面提到的样式差异需要调整的问题,其他开发不愿意配合的情况也可以代入以供参考。
(一)需求原因
开发对需求不认可,觉得需求不合理,这是最关键的问题。
1. 需求本身有问题
任何需求方案都不会是100%完美的,被开发质疑也算正常,莫慌,再思考思考这个点,将最合理的需求方案再次过会评审,以达成一致。
2. 需求本身没问题
产品经理可以发挥你的口才了,业务场景、用户、价值等全部跟开发讲下,开发不像产品,很多时候他们对业务的了解没那么强,角度不一致,咱们多解释下就好。
(二)技术原因
如果开发表态:“我技术实现不了哦。”,这时候我们可以进一步了解“实现不了”的具体含义:
1. 现有技术实现不了
这可能是由于开发本身能力不够导致的,产品经理可以考虑是否存在替代方案。
2. 现有技术可以实现,比较难
这需要产品把需求梳理清楚,让开发更好地理解,然后如果再复杂一些,可以把这个需求进行拆解和细分,划分为更小的颗粒。
3. 需要更改系统现有技术框架
比如一个中台系统,用了FastAdmin的集成框架开发,产品经理的需求是想要在里面加个视频效果、动画效果啥的,这可能就需要换框架了,采用一个前后端分离的来处理,这个就不好搞了。应该考虑时间、成本是否值得。
(三)时间原因
时间原因有两个:
开发本身有其他需求在身,需求调整会导致其他需求延期需求调整要求花费较多的时间,最终影响上线时间两者其实都好沟通,了解后可以根据实际情况进行协调,这里有3个建议:
需求评审前,跟开发负责人先简单过一下需求的开发工时,有个大致的了解,在后面评审或调整时会更有余地。如果产品经理懂技术,在开发的工时评估上能够占据更多主动性,也会更合理。如果样式差异不会有太大的问题影响(如一些偏后台或工具类的产品),就可以先记录,后续单独做版本优化的时候再提出。开发一般情况下还是比较遵循规则的,不同意修改可能是之前在需求中没有定义好设计样式,现在让他改会比较容易有逆反心理。所以如果影响不大,不如先放一放,后续通过规划迭代统一解决。(四)成本原因
这是个投入产出比的问题,如果开发说:“我要花这么长的时间,实现的价值又不高啊,为什么要做?”产品经理该怎么回答?
1. 价值确实不高
一些比较初级的产品经理,有时候确实会忽略了开发的时间成本,当开发这样说了,我们应该重新评估有没有必要去做,重新评估理时间成本与需求的价值,不要觉得被开发反驳就失了面子或失了自信,互相理解、勇于承认错误也是一种成长。
2. 价值很高
还是跟前面一样,是由于开发没有理解透彻导致的。看起来不起眼的调整,对业务方来说可能会节省很大一笔人力物力,对用户体验来说可能会带来质的飞升,产品经理需要让开发正确认识到需求的重要程度。
(五)其他原因
如果看完前面四种,还没能够对号入座,那就思考是不是开发人员故意找茬了。针对这个问题,我们平时需要和开发、测试、UI等搞好关系,平时一起吃吃饭、打打球,关键时刻点一杯奶茶,顺便捏捏肩,说说好话。平时关系处理好,需求推进的时候,自然省时省力,效率很快。
三、结语
大部分情况下,没有什么实现不了的需求,无非就是排期的问题、开发成本的问题、人的问题。
因此,以上方法用一句话简单概括完,似乎是老生常谈的道理:采用MVP方案,先用最小的成本尝试完成需求,只做这个需求中性价比最高的部分,剩下的按优先级顺延。
害,人们就是这样,即便提前学习很多道理以面对未来可能会遇到的难题,但真的遇上了,还是会45°角仰望天空,长叹一句“栓Q!”
但看过这篇文章的你就不一样了,还可以从积灰的收藏夹里翻出此文,看看大家总结的小伎俩能不能用上,到那时候,说的大概就是:“栓Q,我真的会谢!”
参考资料:
[天天问] 当你需求评审时,遇到开发人员说需求实现落地不了,你会如何解决?
素材来源:天天问话题精选
「天天问」为人人都是产品经理社区旗下的互助问答模块,致力产品、运营、营销等领域知识的学习交流。
本栏目由 @Ella 整理编辑发布,欢迎大家踊跃提问,一起交流。
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

GET NEWSLETTER

Advertisement