開發(fā)覺得“影響不大的樣式差異不算 Bug”,怎么破?

3 評論 14204 瀏覽 54 收藏 13 分鐘

作為一名產(chǎn)品經(jīng)理,你一定遇到過與開發(fā)意見不和的情況,例如:這個需求究竟合不合理,能不能趕一趕排期等等。天天問小伙伴則遇到了“研發(fā)覺得影響不大的樣式差異不算 Bug ”的這個問題,一起來看看大家提供了什么好的解決方法吧~

程序員,作為產(chǎn)品經(jīng)理打交道最多的對象之一,在工作上遇到摩擦,那可再正常不過了,比如一產(chǎn)品哥們就遇到了“開發(fā)覺得影響不大的樣式差異不算Bug”,雙方僵持不下的問題。

還在氣頭上時,產(chǎn)品經(jīng)理也許想的是:“如果開發(fā)在這個問題上能說了算,那豈不是既當裁判又當選手了?”

等冷靜下來就會發(fā)現(xiàn),還是解決問題要緊。當下之急,是要知道程序員為什么會這樣想,再對癥下藥。

這篇文章,我們就和各位伙伴們來探討探討,開發(fā)不配合做調整時,產(chǎn)品經(jīng)理應該如何應對?

天天問每周精選第203期:研發(fā)覺得影響不大的樣式差異不算Bug,怎么破?

文章內(nèi)容部分來源于@rkqzzz @非思不可 @林林 @冰雨幻天 @小君毛 @Jarvan156 的精彩回答。

一、為什么開發(fā)覺得樣式差異不算Bug?

為什么開發(fā)覺得影響不大的樣式差異不算 Bug 這個問題,可能是以下三個原因造成了摩擦。

(一)雙方對 Bug 的理解不同

對于開發(fā)人員來說,只要不是寫的代碼邏輯有誤,報錯走不通,都不算 Bug 。而對于非開發(fā)人員來說,只要是與需求不符合就算 Bug ,不管是邏輯方面還是界面樣式方面,只要不符合需求就是 Bug 。

如同水龍頭壞了,開發(fā)覺得換個不漏水的水龍頭就行,而產(chǎn)品經(jīng)理堅持要換黑色磨砂質感的水龍頭是一個道理。產(chǎn)品經(jīng)理和開發(fā)兩個角色各自對 Bug 的定義不同,這是長久以來大家經(jīng)常爭論的一個點,至今沒有定論。

(二)“好看”不一定“好用”

產(chǎn)品設計重在體驗,而體驗的第一道門檻便是交互設計,而非外觀設計。

好的設計大家都想追求,不過“好”是有代價的,要人力,要預算,要時間。再者,好看的產(chǎn)品很多,但是好用的產(chǎn)品不多,比如在設計網(wǎng)站上,我們常能看到很多好看的設計,但如果直接做成完整的產(chǎn)品,也許會發(fā)現(xiàn)很多操作很空洞、界面很虛無,這是想象和實際的差距。

于是,“好看”不一定“好用”,外觀設計就不是首要考慮的因素了。

(三)100%還原設計稿的難度極高

根據(jù)一位做前端開發(fā)的伙伴所言,樣式差異在他眼中的確不能算什么BUG。

為什么這么說呢?他表示,高精度設計稿一般是還原8成以上算合格,9成以上就是精細還原了。設計稿是靜態(tài)圖,而設計稿很多的效果,在手機上是無法實現(xiàn)或者實現(xiàn)代價很大,比如磨砂、透明度、自適應排版等等。平臺的硬件性能決定了渲染一張 jpg 很簡單,渲染一個等質量的 gif 則要困難得多,更別說有很多交互事件要做。

100%還原設計稿?這大概是一場美好的想象。

二、如何與開發(fā)協(xié)調解決?

如果要呈現(xiàn)最好的產(chǎn)品,少不了兩方操刀手——產(chǎn)品、技術協(xié)同溝通,在大方向不偏離的情況下,做好本職工作,可以溝通協(xié)商的點盡量協(xié)商完成,在我們都無法成為下一位喬布斯的時候,還是好好為產(chǎn)品本身負責,畢竟這份作品是團隊實實在在花時間和精力去做的,需要自己的榮譽和責任感。

OK!雞湯灌到這里,下面奉上不同原因對應的解決方法。不僅僅是上面提到的樣式差異需要調整的問題,其他開發(fā)不愿意配合的情況也可以代入以供參考。

(一)需求原因

開發(fā)對需求不認可,覺得需求不合理,這是最關鍵的問題。

1. 需求本身有問題

任何需求方案都不會是100%完美的,被開發(fā)質疑也算正常,莫慌,再思考思考這個點,將最合理的需求方案再次過會評審,以達成一致。

2. 需求本身沒問題

產(chǎn)品經(jīng)理可以發(fā)揮你的口才了,業(yè)務場景、用戶、價值等全部跟開發(fā)講下,開發(fā)不像產(chǎn)品,很多時候他們對業(yè)務的了解沒那么強,角度不一致,咱們多解釋下就好。

(二)技術原因

如果開發(fā)表態(tài):“我技術實現(xiàn)不了哦?!保@時候我們可以進一步了解“實現(xiàn)不了”的具體含義:

1. 現(xiàn)有技術實現(xiàn)不了

這可能是由于開發(fā)本身能力不夠導致的,產(chǎn)品經(jīng)理可以考慮是否存在替代方案。

2. 現(xiàn)有技術可以實現(xiàn),比較難

這需要產(chǎn)品把需求梳理清楚,讓開發(fā)更好地理解,然后如果再復雜一些,可以把這個需求進行拆解和細分,劃分為更小的顆粒。

3. 需要更改系統(tǒng)現(xiàn)有技術框架

比如一個中臺系統(tǒng),用了FastAdmin的集成框架開發(fā),產(chǎn)品經(jīng)理的需求是想要在里面加個視頻效果、動畫效果啥的,這可能就需要換框架了,采用一個前后端分離的來處理,這個就不好搞了。應該考慮時間、成本是否值得。

(三)時間原因

時間原因有兩個:

  1. 開發(fā)本身有其他需求在身,需求調整會導致其他需求延期
  2. 需求調整要求花費較多的時間,最終影響上線時間

兩者其實都好溝通,了解后可以根據(jù)實際情況進行協(xié)調,這里有3個建議:

  1. 需求評審前,跟開發(fā)負責人先簡單過一下需求的開發(fā)工時,有個大致的了解,在后面評審或調整時會更有余地。
  2. 如果產(chǎn)品經(jīng)理懂技術,在開發(fā)的工時評估上能夠占據(jù)更多主動性,也會更合理。
  3. 如果樣式差異不會有太大的問題影響(如一些偏后臺或工具類的產(chǎn)品),就可以先記錄,后續(xù)單獨做版本優(yōu)化的時候再提出。開發(fā)一般情況下還是比較遵循規(guī)則的,不同意修改可能是之前在需求中沒有定義好設計樣式,現(xiàn)在讓他改會比較容易有逆反心理。所以如果影響不大,不如先放一放,后續(xù)通過規(guī)劃迭代統(tǒng)一解決。

(四)成本原因

這是個投入產(chǎn)出比的問題,如果開發(fā)說:“我要花這么長的時間,實現(xiàn)的價值又不高啊,為什么要做?”產(chǎn)品經(jīng)理該怎么回答?

1. 價值確實不高

一些比較初級的產(chǎn)品經(jīng)理,有時候確實會忽略了開發(fā)的時間成本,當開發(fā)這樣說了,我們應該重新評估有沒有必要去做,重新評估理時間成本與需求的價值,不要覺得被開發(fā)反駁就失了面子或失了自信,互相理解、勇于承認錯誤也是一種成長。

2. 價值很高

還是跟前面一樣,是由于開發(fā)沒有理解透徹導致的??雌饋聿黄鹧鄣恼{整,對業(yè)務方來說可能會節(jié)省很大一筆人力物力,對用戶體驗來說可能會帶來質的飛升,產(chǎn)品經(jīng)理需要讓開發(fā)正確認識到需求的重要程度。

(五)其他原因

如果看完前面四種,還沒能夠對號入座,那就思考是不是開發(fā)人員故意找茬了。針對這個問題,我們平時需要和開發(fā)、測試、UI等搞好關系,平時一起吃吃飯、打打球,關鍵時刻點一杯奶茶,順便捏捏肩,說說好話。平時關系處理好,需求推進的時候,自然省時省力,效率很快。

三、結語

大部分情況下,沒有什么實現(xiàn)不了的需求,無非就是排期的問題、開發(fā)成本的問題、人的問題。

因此,以上方法用一句話簡單概括完,似乎是老生常談的道理:采用MVP方案,先用最小的成本嘗試完成需求,只做這個需求中性價比最高的部分,剩下的按優(yōu)先級順延。

害,人們就是這樣,即便提前學習很多道理以面對未來可能會遇到的難題,但真的遇上了,還是會45°角仰望天空,長嘆一句“栓Q!”

但看過這篇文章的你就不一樣了,還可以從積灰的收藏夾里翻出此文,看看大家總結的小伎倆能不能用上,到那時候,說的大概就是:“栓Q,我真的會謝!”

 

參考資料:

[天天問]?當你需求評審時,遇到開發(fā)人員說需求實現(xiàn)落地不了,你會如何解決?

 

關于“研發(fā)覺得影響不大的樣式差異不算 Bug ,怎么破?”,你有什么看法?點擊下面的鏈接,一起來聊聊吧~

戳:https://996.pm/7qbn0

#天天問神回復#

「天天神回復」欄目,致力于發(fā)現(xiàn)天天問小伙伴的精彩語錄。抖機靈,大伙兒也是認真的!如果喜歡,記得點擊問題鏈接,和TA一起互動吧,我們也在這里期待你的發(fā)言喲~

如何從運營的角度去分析產(chǎn)品功能的發(fā)布節(jié)奏:比如語音和朋友圈該先做哪個?

@Bboy小南:

從產(chǎn)品的角度,我會優(yōu)先選擇語音

從運營的角度,我會優(yōu)先選擇朋友圈

從老板的角度,兩個都發(fā),大家加加班

用一個詞或者一句話證明你是產(chǎn)品經(jīng)理?

@王小楠:東抄抄,西抄抄,加點這個,少點那個

新產(chǎn)品,頁面的文案一般誰來寫呢?專人寫,還是產(chǎn)品經(jīng)理寫?

@小刺猬001:誰提議誰寫,誰能寫誰寫,誰老實誰寫……

#相關閱讀#

【天天問每周精選】第202期:做私域,逃不開“加個微信”

【天天問每周精選】第201期:AI伴侶的使命,不只是和你搞對象

【天天問每周精選】第200期:AI面試官,甭想搶HR的飯碗

【天天問每周精選】第199期:慢!慢!慢!百度網(wǎng)盤怎么還沒被淘汰?

【天天問每周精選】第198期:這屆網(wǎng)友撒過最多的謊:我已閱讀協(xié)議

素材來源:天天問話題精選

「天天問」為人人都是產(chǎn)品經(jīng)理社區(qū)旗下的互助問答模塊,致力產(chǎn)品、運營、營銷等領域知識的學習交流。

本欄目由 @Ella 整理編輯發(fā)布,歡迎大家踴躍提問,一起交流。

題圖來自Unsplash,基于CC0協(xié)議

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 對于開發(fā)人員來說,只要不是寫的代碼邏輯有誤,報錯走不通,都不算 Bug 。
    你這個結論是以偏概全。不要妄自揣測,你問過幾個程序員

    來自北京 回復
    1. 可能他指的是開發(fā)自己在寫代碼的報錯不算bug,如果是用戶在用的時候報錯了,開發(fā)不認為是bug的話就錘他

      來自江蘇 回復
  2. 開發(fā)和產(chǎn)品經(jīng)理彼此之間對產(chǎn)品的思考方式不同,導致對bug的判斷標準不一樣。

    來自中國 回復