一、为什么开发觉得样式差异不算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，我真的会谢！”