正确的提示信息

扫码打开虎嗅APP

从思考到创造
打开APP
搜索历史
删除
完成
全部删除
热搜词
2022-09-14 16:38
产品和开发的“小分歧”,要如何解决?

本文来自微信公众号:人人都是产品经理(ID:woshipm),整理:Ella,文章内容部分来源于@rkqzzz @非思不可 @林林 @冰雨幻天 @小君毛 @Jarvan156 的精彩回答,原文标题:《开发觉得“影响不大的样式差异不算 Bug”,怎么破?》,题图来自:视觉中国


程序员,作为产品经理打交道最多的对象之一,在工作上遇到摩擦,那可再正常不过了,比如一产品哥们就遇到了“开发觉得影响不大的样式差异不算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. 时间原因


时间原因有两个:


  1. 开发本身有其他需求在身,需求调整会导致其他需求延期;


  2. 需求调整要求花费较多的时间,最终影响上线时间。


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


  1. 需求评审前,跟开发负责人先简单过一下需求的开发工时,有个大致的了解,在后面评审或调整时会更有余地。


  2. 如果产品经理懂技术,在开发的工时评估上能够占据更多主动性,也会更合理。


  3. 如果样式差异不会有太大的问题影响(如一些偏后台或工具类的产品),就可以先记录,后续单独做版本优化的时候再提出。开发一般情况下还是比较遵循规则的,不同意修改可能是之前在需求中没有定义好设计样式,现在让他改会比较容易有逆反心理。所以如果影响不大,不如先放一放,后续通过规划迭代统一解决。


4. 成本原因


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


1)价值确实不高


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


2)价值很高


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


5. 其他原因


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


三、总结一下


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


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


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


本文来自微信公众号:人人都是产品经理(ID:woshipm),整理:Ella,文章内容部分来源于@rkqzzz @非思不可 @林林 @冰雨幻天 @小君毛 @Jarvan156 的精彩回答

本内容为作者独立观点,不代表虎嗅立场。未经允许不得转载,授权事宜请联系 hezuo@huxiu.com
如对本稿件有异议或投诉,请联系tougao@huxiu.com
打开虎嗅APP,查看全文

支持一下

赞赏

0人已赞赏

大 家 都 在 看

大 家 都 在 搜

好的内容,值得赞赏

您的赞赏金额会直接进入作者的虎嗅账号

    自定义
    支付: