開發(fā)覺得“影響不大的樣式差異不算 Bug”,怎么破?
作為一名產(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)理的需求是想要在里面加個視頻效果、動畫效果啥的,這可能就需要換框架了,采用一個前后端分離的來處理,這個就不好搞了。應該考慮時間、成本是否值得。
(三)時間原因
時間原因有兩個:
- 開發(fā)本身有其他需求在身,需求調整會導致其他需求延期
- 需求調整要求花費較多的時間,最終影響上線時間
兩者其實都好溝通,了解后可以根據(jù)實際情況進行協(xié)調,這里有3個建議:
- 需求評審前,跟開發(fā)負責人先簡單過一下需求的開發(fā)工時,有個大致的了解,在后面評審或調整時會更有余地。
- 如果產(chǎn)品經(jīng)理懂技術,在開發(fā)的工時評估上能夠占據(jù)更多主動性,也會更合理。
- 如果樣式差異不會有太大的問題影響(如一些偏后臺或工具類的產(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 ,怎么破?”,你有什么看法?點擊下面的鏈接,一起來聊聊吧~
#天天問神回復#
「天天神回復」欄目,致力于發(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:誰提議誰寫,誰能寫誰寫,誰老實誰寫……
#相關閱讀#
【天天問每周精選】第201期:AI伴侶的使命,不只是和你搞對象
【天天問每周精選】第199期:慢!慢!慢!百度網(wǎng)盤怎么還沒被淘汰?
【天天問每周精選】第198期:這屆網(wǎng)友撒過最多的謊:我已閱讀協(xié)議
素材來源:天天問話題精選
「天天問」為人人都是產(chǎn)品經(jīng)理社區(qū)旗下的互助問答模塊,致力產(chǎn)品、運營、營銷等領域知識的學習交流。
本欄目由 @Ella 整理編輯發(fā)布,歡迎大家踴躍提問,一起交流。
題圖來自Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
對于開發(fā)人員來說,只要不是寫的代碼邏輯有誤,報錯走不通,都不算 Bug 。
你這個結論是以偏概全。不要妄自揣測,你問過幾個程序員
可能他指的是開發(fā)自己在寫代碼的報錯不算bug,如果是用戶在用的時候報錯了,開發(fā)不認為是bug的話就錘他
開發(fā)和產(chǎn)品經(jīng)理彼此之間對產(chǎn)品的思考方式不同,導致對bug的判斷標準不一樣。