作为一名产品经理,你一定遇到过与开发意见不和的情况,例如:这个需求究竟合不合理,能不能赶一赶排期等等。天天问小伙伴则遇到了“研发觉得影响不大的样式差异不算 Bug ”的这个问题,一起来看看大家提供了什么好的解决方法吧~

让程序员抓狂的设计(影响不大的样式差异不算)(1)

程序员,作为产品经理打交道最多的对象之一,在工作上遇到摩擦,那可再正常不过了,比如一产品哥们就遇到了“开发觉得影响不大的样式差异不算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的集成框架开发,产品经理的需求是想要在里面加个视频效果、动画效果啥的,这可能就需要换框架了,采用一个前后端分离的来处理,这个就不好搞了。应该考虑时间、成本是否值得。

(三)时间原因

时间原因有两个:

  1. 开发本身有其他需求在身,需求调整会导致其他需求延期
  2. 需求调整要求花费较多的时间,最终影响上线时间

两者其实都好沟通,了解后可以根据实际情况进行协调,这里有3个建议:

  1. 需求评审前,跟开发负责人先简单过一下需求的开发工时,有个大致的了解,在后面评审或调整时会更有余地。
  2. 如果产品经理懂技术,在开发的工时评估上能够占据更多主动性,也会更合理。
  3. 如果样式差异不会有太大的问题影响(如一些偏后台或工具类的产品),就可以先记录,后续单独做版本优化的时候再提出。开发一般情况下还是比较遵循规则的,不同意修改可能是之前在需求中没有定义好设计样式,现在让他改会比较容易有逆反心理。所以如果影响不大,不如先放一放,后续通过规划迭代统一解决。

(四)成本原因

这是个投入产出比的问题,如果开发说:“我要花这么长的时间,实现的价值又不高啊,为什么要做?”产品经理该怎么回答?

1. 价值确实不高

一些比较初级的产品经理,有时候确实会忽略了开发的时间成本,当开发这样说了,我们应该重新评估有没有必要去做,重新评估理时间成本与需求的价值,不要觉得被开发反驳就失了面子或失了自信,互相理解、勇于承认错误也是一种成长。

2. 价值很高

还是跟前面一样,是由于开发没有理解透彻导致的。看起来不起眼的调整,对业务方来说可能会节省很大一笔人力物力,对用户体验来说可能会带来质的飞升,产品经理需要让开发正确认识到需求的重要程度。

(五)其他原因

如果看完前面四种,还没能够对号入座,那就思考是不是开发人员故意找茬了。针对这个问题,我们平时需要和开发、测试、UI等搞好关系,平时一起吃吃饭、打打球,关键时刻点一杯奶茶,顺便捏捏肩,说说好话。平时关系处理好,需求推进的时候,自然省时省力,效率很快。

三、结语

大部分情况下,没有什么实现不了的需求,无非就是排期的问题、开发成本的问题、人的问题。

因此,以上方法用一句话简单概括完,似乎是老生常谈的道理:采用MVP方案,先用最小的成本尝试完成需求,只做这个需求中性价比最高的部分,剩下的按优先级顺延。

害,人们就是这样,即便提前学习很多道理以面对未来可能会遇到的难题,但真的遇上了,还是会45°角仰望天空,长叹一句“栓Q!”

但看过这篇文章的你就不一样了,还可以从积灰的收藏夹里翻出此文,看看大家总结的小伎俩能不能用上,到那时候,说的大概就是:“栓Q,我真的会谢!”

参考资料:

关于“研发觉得影响不大的样式差异不算 Bug ,怎么破?”,你有什么看法?点击下面的链接,一起来聊聊吧~

让程序员抓狂的设计(影响不大的样式差异不算)(2)

#天天问神回复#

「天天神回复」栏目,致力于发现天天问小伙伴的精彩语录。抖机灵,大伙儿也是认真的!如果喜欢,记得点击问题链接,和TA一起互动吧,我们也在这里期待你的发言哟~

@Bboy小南:

从产品的角度,我会优先选择语音

从运营的角度,我会优先选择朋友圈

从老板的角度,两个都发,大家加加班

@王小楠:东抄抄,西抄抄,加点这个,少点那个

@小刺猬001:谁提议谁写,谁能写谁写,谁老实谁写……

,