开发觉得“影响不大的样式差异不算 Bug”，怎么破？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

整理：Ella，人人都是产品经理运营

本文整理自人人都是产品经理社区旗下互助问答模块「天天问」

题图来自 Unsplash，基于 CC0 协议

全文共 3176 字，阅读需要 6 分钟

——————/ BEGIN /——————

程序员，作为产品经理打交道最多的对象之一，在工作上遇到摩擦，那可再正常不过了，比如一产品哥们就遇到了“开发觉得影响不大的样式差异不算Bug”，双方僵持不下的问题。

还在气头上时，产品经理也许想的是：“如果开发在这个问题上能说了算，那岂不是既当裁判又当选手了？”

等冷静下来就会发现，还是解决问题要紧。当下之急，是要知道程序员为什么会这样想，再对症下药。

这篇文章，我们就和各位伙伴们来探讨探讨，开发不配合做调整时，产品经理应该如何应对？

为什么开发觉得样式差异不算Bug？

为什么开发觉得影响不大的样式差异不算 Bug 这个问题，可能是以下三个原因造成了摩擦。

1. 双方对 Bug 的理解不同

对于开发人员来说，只要不是写的代码逻辑有误，报错走不通，都不算 Bug 。而对于非开发人员来说，只要是与需求不符合就算 Bug ，不管是逻辑方面还是界面样式方面，只要不符合需求就是 Bug 。

如同水龙头坏了，开发觉得换个不漏水的水龙头就行，而产品经理坚持要换黑色磨砂质感的水龙头是一个道理。产品经理和开发两个角色各自对 Bug 的定义不同，这是长久以来大家经常争论的一个点，至今没有定论。

2. “好看”不一定“好用”

产品设计重在体验，而体验的第一道门槛便是交互设计，而非外观设计。

好的设计大家都想追求，不过“好”是有代价的，要人力，要预算，要时间。再者，好看的产品很多，但是好用的产品不多，比如在设计网站上，我们常能看到很多好看的设计，但如果直接做成完整的产品，也许会发现很多操作很空洞、界面很虚无，这是想象和实际的差距。

于是，“好看”不一定“好用”，外观设计就不是首要考虑的因素了。

3. 100%还原设计稿的难度极高

根据一位做前端开发的伙伴所言，样式差异在他眼中的确不能算什么BUG。

为什么这么说呢？他表示，高精度设计稿一般是还原8成以上算合格，9成以上就是精细还原了。设计稿是静态图，而设计稿很多的效果，在手机上是无法实现或者实现代价很大，比如磨砂、透明度、自适应排版等等。平台的硬件性能决定了渲染一张 jpg 很简单，渲染一个等质量的 gif 则要困难得多，更别说有很多交互事件要做。

100%还原设计稿？这大概是一场美好的想象。

如何与开发协调解决？

如果要呈现最好的产品，少不了两方操刀手——产品、技术协同沟通，在大方向不偏离的情况下，做好本职工作，可以沟通协商的点尽量协商完成，在我们都无法成为下一位乔布斯的时候，还是好好为产品本身负责，毕竟这份作品是团队实实在在花时间和精力去做的，需要自己的荣誉和责任感。

OK！鸡汤灌到这里，下面奉上不同原因对应的解决方法。不仅仅是上面提到的样式差异需要调整的问题，其他开发不愿意配合的情况也可以代入以供参考。

1. 需求原因

开发对需求不认可，觉得需求不合理，这是最关键的问题。

1）需求本身有问题

任何需求方案都不会是100%完美的，被开发质疑也算正常，莫慌，再思考思考这个点，将最合理的需求方案再次过会评审，以达成一致。

2）需求本身没问题

产品经理可以发挥你的口才了，业务场景、用户、价值等全部跟开发讲下，开发不像产品，很多时候他们对业务的了解没那么强，角度不一致，咱们多解释下就好。

2. 技术原因

如果开发表态：“我技术实现不了哦。”，这时候我们可以进一步了解“实现不了”的具体含义：

1）现有技术实现不了

这可能是由于开发本身能力不够导致的，产品经理可以考虑是否存在替代方案。

2）现有技术可以实现，比较难

这需要产品把需求梳理清楚，让开发更好地理解，然后如果再复杂一些，可以把这个需求进行拆解和细分，划分为更小的颗粒。

3）需要更改系统现有技术框架

比如一个中台系统，用了FastAdmin的集成框架开发，产品经理的需求是想要在里面加个视频效果、动画效果啥的，这可能就需要换框架了，采用一个前后端分离的来处理，这个就不好搞了。应该考虑时间、成本是否值得。

3. 时间原因

时间原因有两个：

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

4. 成本原因

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

1）价值确实不高

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

2）价值很高

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

5. 其他原因

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

总结一下

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

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

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

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

——————/ E N D /——————

▼ 点击「阅读原文」查看更多精彩回答