作為一名産品經理，你一定遇到過與開發意見不和的情況，例如：這個需求究竟合不合理，能不能趕一趕排期等等。天天問小夥伴則遇到了“研發覺得影響不大的樣式差異不算 Bug ”的這個問題，一起來看看大家提供了什麼好的解決方法吧~

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

還在氣頭上時，産品經理也許想的是：“如果開發在這個問題上能說了算，那豈不是既當裁判又當選手了？”

等冷靜下來就會發現，還是解決問題要緊。當下之急，是要知道程序員為什麼會這樣想，再對症下藥。

這篇文章，我們就和各位夥伴們來探讨探讨，開發不配合做調整時，産品經理應該如何應對？

天天問每周精選第203期：研發覺得影響不大的樣式差異不算Bug，怎麼破？

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

一、為什麼開發覺得樣式差異不算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，我真的會謝！”

參考資料：

關于“研發覺得影響不大的樣式差異不算 Bug ，怎麼破？”，你有什麼看法？點擊下面的鍊接，一起來聊聊吧~

#天天問神回複#

「天天神回複」欄目，緻力于發現天天問小夥伴的精彩語錄。抖機靈，大夥兒也是認真的！如果喜歡，記得點擊問題鍊接，和TA一起互動吧，我們也在這裡期待你的發言喲~

@Bboy小南：

從産品的角度，我會優先選擇語音

從運營的角度，我會優先選擇朋友圈

從老闆的角度，兩個都發，大家加加班

@王小楠：東抄抄，西抄抄，加點這個，少點那個

@小刺猬001：誰提議誰寫，誰能寫誰寫，誰老實誰寫……

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部