1樓：董董
從這個問題上，可以從2點來分析:
一、產品經理產品改進的理由；
二、開發拒絕的理由；
第一點:產品經理產品改進的理由是否充分，對產品的價值有多大，是否得到領導的支援等。
第二點:拒絕就是不開發，而不是延期等。理由可能是改進的價值不充分、沒有領導層面的壓力、開發實現複雜、開發與產品的關係不融洽都存在這種情況。
此時，需要具體問題具體分析，個個擊破
其實，如果產品經理有足夠的決策權，開發人員是不會拒絕你的。
2樓：schwimmers
其實。。很有可能開發人員說的是對的呢？
其他情況有以下：
1) 視角。有些需求是牽扯到商業和內外部其他因素需要搞。盡量給他們解釋清楚。好的開發也不會只喜歡當執行工具.
2) 開發不理解產品或者使用者。這個經常出現在經驗或者情商都不太成熟的開發身上。還是要解釋清楚。要是他們還是不理解，就給帶他們的上級解釋清楚。
3) 沒辦法的需求。有些需求，產品狗也很無奈，沒辦法。。還是要解釋清楚。。
如果開發和產品都稱職，決策部門也基本靠譜的話，這種情況非常少。很多時候扯皮的內容更複雜，涉及到排期，各部門協調。產品不能被繞進去。
盡量幫忙把各種麻煩最小化。要照顧好各方情緒。
利益相關，產品狗。跟開發部門工作關係和私交都很好。
3樓：尼格
產品需求和說明我在寫，設計我畫，說明和標註也是我在弄，發給程式交流問題都是我個設計在做，你說，這個時候產品的話有沒有說服力？
我唯一遇見過負責任的好產品並不是我們組的，悲催
然後，別問我為什麼產品不做，因為他說他忙┑(￣Д ￣)┍
4樓：
說不好聽的，很多做產品的純屬把技術人員當作實現工具，一拍腦瓜就要怎麼怎麼做，一看沒效果或效果差就立馬要下來，既不考慮真實場景需求也不考慮「工具」的感受，你沒把技術當作乙個team，技術自然也不會吊你。
技術其實也想融入專案，知道自己做出來的是什麼有什麼用達到了什麼效果。別說你產品經理要做出來上線了才知道結果，那你這產品真是個擺設。
5樓：蘇杰
是時候上「說服三寶」了：
競品已搞；
老闆想要；
開發量小。
如果不行，
再上殺招：
求求你了好不好~~~
額，純屬玩笑……
==== 加兩句背後可能有的道理 ====競品已搞——曉之以理，背後對應要做的是市場等外部情況的研究，但競品有沒有做絕不是關鍵；
老闆想要——繩之以法，背後對應的是一些規則，當然規則不一定合理；
開發量小——誘之以利，總得有點好處吧，雖然工作量不大的好處不是核心；
跪地求饒——動之以情，和團隊成員的私交，對工作的幫助絕對比你想象的大。
———— 2023年更新 ————
極客時間
6樓：吳學毅
我認為還是溝通方面的問題。
了他們解背後的話。
DEV 和 UI說「沒意思，沒區別」的原因有很多，但是真的因為沒意思的可能性不大。根據個人經驗，DEV和UI說這話可能來自以下幾個方面的原因：
專案需求經常變，人都已經做煩了，不想改
新的需求，在DEV和UI看來需要投入大量時間精力，投入產出比不高，不想改
新的需求在DEV和UI看來真的和原有設計沒有區別
DEV和UI手頭上有其他優先順序更好的任務，新的需求優先順序不高，弄乙個藉口推脫過去
DEV，UI 和 PM關係不好，已經產生敵對情緒
等等。。。。
努力去談，坦誠去談。
在不了解DEV和UI 的想法之前，怎麼推進專案都最後都會出問題。 所以盡可能獲取DEV和UI的新需求的真實想法吧。
PM只要表明是為了產品做好的出發點，一般大家都願意談。但是如果PM抱著一種，「你為什麼不聽話，不合群的態度去談」，估計談不出什麼結果。
重新推動專案
根據DEV和UI的不滿意見，PM應該對工作計畫和方式有一定調整。
需求經常變更的情況：如果是因為產品經常拍腦袋，請反思。如果因為前期DEV和UI沒有參與產品設計，可以組織一次會議，從新講解產品設計理念並統一收集DEV和UI對產品的意見，統一分歧。
投入產出比不高：PM需要重新評估功能的重要性和回報率，確定這個功能要不要做。
DEV和UI感覺功能之間真的沒區別：PM應該通過使用者反饋，使用者資料給DEV和UI講解為什麼新功能如此重要，具體是什麼使用者需要，可以幫助他們解決具體什麼問題。（這不就是PM的日常工作內容嗎。。。
）DEV和UI有其他任務：PM重新評估時間安排
敵對的情緒：關係只能慢慢修補了。
說白了就是溝通。
另外：個人認為，雖然需求改進推動過程中遇到一些阻礙。但是PM就應該堅持自己的產品觀，可以通過一種大家都舒服的方式推進專案，可以調整工作計畫，可以協商推進的方式，但是功能需求不可以折中！
不然很容易產生四不像的產品。
7樓：
任何良好的專案管理都建立在良好的私交基礎上，最好是有共同的利益。
拒絕改變的原因往往是因為你沒有讓他們信任你。
其次的在乙個東西未經驗證之前，所有人都會有自己對此的判斷。了解他們的判斷，然後嘗試去說服。
「老闆命令、上頭指示」這樣的句式只有在萬不得已的時候再用。
8樓：
產品經理做為產品的「父母」 應該是有決策權的但是在實際當中必須去說服很多人，比如boss，還有開發人員等在之前應該先說服自己~或推翻自己~再提出來的意見遇到疑問也應該應答入流
真的遇到「軸」的開發或設計也沒辦法只能強推因為很多時候理想的方法不適用於任何人
9樓：包子
如何說服設計師修改設計方案？
參照這裡 http://www.
1、曉之以理：告知己方需求
2、動之以情：以適當的方法，告知己方需求
3、以適當的方法，告知己方需求，並講明修改與否的利害關係
10樓：且歌
技術這種態度往往是由於慣性。。。
自己要先有取捨，該去的地方去掉了，該加的地方就能加。別讓技術認為產品是只會拍腦袋提需求的角色。
11樓：李丹華
拋開流程，機制等等，談下個人。
產品經理的基礎素養裡面，資料分析，UED等等應該逐漸成為基本技能，說服不了開發和設計的原因不在流程，而在個人。
在假設大家都是做事情的基礎上，有以下幾點可以辦。
1、用資料說話
這次的優化改進預期能帶來多少的提公升，上次的改進效果如何如何。這些是資料和預估。任何乙個做事的人都必須正視資料。是資料反映這個改進有沒有作用。當然，預估要準確。
2、嘗試使用者的視角來看優化
技術，開發在這個產品上有雙重身份，一方面是開發者，要評估實現方式，實現成本，開發周期，另一方面是使用者，因為這個使用者比較「專業」，所以有時會喪失細節，畢竟開發者是按照自己的偏好來看產品的。
嘗試從這兩個角度來看問題，然後給對方乙個理由。是否是成本不可行，還是因為對方在使用者視角裡面考慮了自己，而沒考慮大部分使用者？如果是，說出理由，證據。
3、冷靜想清楚自己的建議是否是使用者的訴求
是否也因為自己的偏好而去改產品，有沒有基於使用者視角，CE，UED，資料，技術等多角度的思量？
12樓：任毅
1、看你們的工作流程和機制。一般，如果對頁面或者產品進行完善修改屬於日常工作之一，那麼正常的改進，開發人員是必須實施；如果公司沒有規定這種工作流程，那麼乙個是提議公司建立起工作流程來，二個就是直接爭取公司領導的支援和認可，改進方案先獲得領導認可，由領導下達工作指令。
2、在很多時候，開發人員不像產品人員那麼「講究」，特別是中小公司，在工作量大的情況下，開發人員不太願意進行一些修改，這個是正常現象。這個時候，就需要產品人員和開發人員處好人際關係，通過溝通交流來解決問題，強制要求開發人員進行工作不利於團隊合作。這裡就看產品人員的協調資源能力了
為什麼說mac更適合設計人員和開發者？
仰望天堂 個人覺得，第一，Mac的鍵盤不像機械這種按下去比較費力，不費力，而且反應靈敏 其次而且Mac的鍵盤快捷鍵用起來特別舒服，command就在空格旁邊，不像普通鍵盤，按Ctrl要把手張開的老長 KelvinSun 說出來你們可能不信比爾蓋茨開發的微軟自己卻用的Mac 在辦公和某些程式設計開發上...
開發人員最討厭產品經理的哪些做法？
Lucia 開始實施之前 說不清需求價值 技術問 為什麼要做 的時候，支支吾吾，或者說 老闆要的 運營要的 成為了傳話筒，是最Low的，相反，能有理有據的頂老闆的產品經理，通常會在大家的眼中逼格滿滿 沒想到功能細節 表現為技術問細節 當然，是涉及業務的細節，不是技術實現細節 的時候，自己還沒想過，現...
產品經理在產品設計中如何給開發挖坑？
一農婦餵雞，錯把壯陽藥當飼料灑在雞圈裡。一公雞吃了，雄性大發，將本家的雞幹完後跑了出去。至晚不歸。農婦去找，見本村的雞無一生存，皆被奸而死。找到村外，見自己的雞站在一棵大樹上。問他為何不回家，他說，我等著幹老鷹呢。挖坑很容易，但是這不是重點。重點是哥們，挖坑之前你最好搞清楚誰會被埋進去。 咖啡 1....