1樓：月尊
沒有完美方案
產品經理提供的解決方案是平衡了對需求的滿足程度和開發成本的，是要考慮ROI的。在開發成本未出現明顯差異的情況下，產品經理會盡所能地滿足業務需求，或超預期的滿足業務需求；但在開發成本出現明顯差異的情況下，產品經理會在滿足業務同學核心需求的情況下，去說服業務同學採用不完美的次優方案，但卻是ROI最高的最優方案。
所以，當出現此類問題的時候，業務千萬不要過分糾結方案是否完美，要明白在滿足業務需求的前提下，ROI最高才是最優方案。即便是不惜一切代價做出來完美方案，但也只是現階段的完美。隨著業務的飛速發展很快就變得不完美了，不能再支援業務的發展。
在網際網路行業，能夠快速搶占市場，也是需要業務同學考慮的重要因素。過於追求完美方案，最終失去了搶占市場的先機，得不償失。引用一句鄧爺爺的名言：
「黑貓、白貓無所謂，能最快抓耗子的就是好貓。」
月尊：如何正確給產品經理提需求
2樓：啊波
最重要的，要搞清楚為什麼他要說」做不了」
有幾種情況，摸魚，嫌麻煩，確實不可能，或者，乾脆就是不認可你的為人。
現實中，一一分辨這種情況再去應對，太耗費精力了。
我建議只用一招，」用對待客戶的方式，對待程式設計師」
講清楚為什麼做，有什麼價值，從心底說服他，就像你說服客戶那樣，不要強壓，而是要真的讓他理解自己在做什麼。
然後問他，」如果我的技術方案不行，你的建議是什麼」，通常會有驚喜
3樓：鬱鬱黃花
就軟體開發來說，技術說做不了是個偽命題，產品經理應該從客戶的需求出發。從解決了客戶這個需求對企業營收的正面影響來說服技術！
4樓：風中流浪
這麼說吧，拿我以前曾經帶過的兩個創業團隊舉例子。
其中一家創業公司是扁平化管理，技術團隊在一起，我負責管理產品和運營團隊，有些邏輯稍微複雜些的需求，產品基本都要在評審會上講清楚來龍去脈，包括需求的價值、選擇這個解決方案的原因等等來想技術解釋這個需求的必要性，文件也要盡可能的詳盡。就這樣，撕逼的事情也時有發生，技術經常會很抗拒有難度或有風險的需求，需要通過我去跟技術部門的leader協調處理。
另外一家公司，情況則完全不同。也是創業公司，但是有幾條業務線，以類似事業部的形式管理。我負責其中一條業務線，具體管理是我直管產品和運營團隊，對這個業務的ROI負責，部門裡有個技術leader掛著技術總監的頭銜直接管理技術團隊，向我匯報。
在部門裡，基本上我過了的需求，到技術那裡，有問題的都會主動找我協調開發難點和難處。有的需求我也明白確實比較費時費力，但是業務需要沒辦法，必須要做，我就會強硬一些，直接要里程碑。事實證明，哪怕某些需求確實有難點要攻克，大多數也都能按時保質保量完成，基本都吃的到慶功宴。
技術們從來不去過多論證「為什麼要做這個功能」、「將來會不會反覆」、「已經有了類似解決方案為什麼要重新做」等等一系列經常讓產品很費口舌的問題，反而我會覺得大家要比較明確專案的目標，才好有針對性的規劃產品技術架構，常常主動拉著技術們講產品方向和畫餅，跟他們講要多思考產品方向。
總的來講，技術能不能做這個需求，一方面取決於你的需求設計的好不好，更重要的一方面是取決於你說的算不算。所以，產品經理都要有乙個成長的過程，盡快積累能力，讓自己能最短時間裡成為某個業務或者某功能的決策者，情況就會好很多。當你手裡捧著技術的飯碗的時候，說實在的，他幹活也會比較有動力，不管是因為想多賺錢還是怕被辭退，都差不多。
另外，說句題外話，程式設計師也是人，一樣公尺養百樣人。從我的個人角度來講，我不怕別人說我帶有色眼鏡，越是培訓班出來的技術，越會面試，脾氣越大，也更會推需求。我合作過的幾個比較有能力的技術大牛，通常會更多考慮怎麼實現，而不是要不要實現，或者在鄙視產品設計之後，給你指出另一條讓你不得不服的解決方案。
5樓：以北為望
提供兩個簡單有效的方法作為參考，分別是資料反饋和表述反饋
1、資料為王雙向反饋：平常的時候將已開發功能所用開發時間做好記錄，按照模組進行區分，將模組設定難度係數，同時使用難度係數和開發時間來評定乙個模組的屬性，難度係數由你自己分級和填寫，不要分的過多，最好控制在4-5級即可，遇到類似的模組或類似難度系統的模組可以對照相應的歷史開發時間來評估，計算平均值和最大最小的偏差值，基本上也可以確定乙個模組的開發周期和上下變動時間範圍了。
這種方式要求對模組數量有一定的積累，以免差生太大的誤差，同時對於模組的難度係數要有準確的估算，之所以不將難度系統分級增加太多，並且計算偏差值，就是怕不懂技術的產品對於難度係數估算不準確。
2、拆分功能刨根問底：將功能拆分成更加細的需求點，乙個點乙個點的詢問大概時長，程式猿的邏輯性雖然強，但強在技術層面，而不是口頭表述層面，所以要麼表述的很有道理，你可以學到一些東西並且了解為什麼要花這些時間；要麼其很難自圓其說，導致需要其重新估算整體開發周期。
這個方法的核心在於，首先要有一定的口頭表達能力，注意觀察對方的表達是否猶豫、磕巴、重複，如果出現上述情況，抓住痛點進行回擊。
6樓：Holych浩男
解決型思維，以下是解決順序：↓↓↓
1.「哦，是嗎？」 / 「哦，為什麼？」
二次確認一下，斃掉「因為懶不想做」的情況。
去了解原因，斃掉「沒聽懂，只是覺得貌似不太合理」的情況。
2.「那麼你的建議呢？」
Diss別人，除了故意找茬之外，一般自己心裡都會有個貌似更好的大概方案（或解決方向），才會覺得別人的不好。這麼問一下，調起技術同學的主觀能動性，畢竟產品經理以為OK的方案在客觀的角度上也不一定命中合理範圍。
3.「其實我想要的是這樣這樣的最後效果，要達到什麼什麼樣的目標，為的是這個這個目標。」
在聽完技術同學的大概想法之後，你看是否貼合預期、執行起來的內容大概是否可控。如果覺得這個方向更合理，那麼可以基於最終目標尋求合理範圍內的最優解，開啟共同優化方案的配合模式。
補充一點：如果出現反饋說「資料庫有問題，做不了這個功能」的情況，一般情況下和當前你方案裡的功能和體驗的關係就不大了，屬於技術層面的問題會多一些，多去了解一下原因，多請教一下技術方案。
有個原則是，硬性實現不了的可以軟性實現。理論上他們總能實現的。話說回來，有時產品也要幫助技術避坑，側面＆迂迴解決也是一種思路，與創新和規劃結合著用。
7樓：瑪莉和興爺
有可能是文件問題，在寫文件都的時候要想清楚可行性方案ABC
做不了很簡單的意思就是太浪費時間了，給出適當的排期在於部門領導溝通就可以了。
8樓：
我是乙個解決問題型的選手，通常遇到這種問題，我都以解決問題為前提，不扯皮。
下面介紹一下我的解決方法：
遇到這樣的問題我通常都先多去詢問幾個為什麼，知道原因後我才能評估需求是因為設計的不合理還是什麼原因實現不了，後續在設計時候該如何的去規避同樣的問題。
通常在設計乙個需求或解決乙個問題時候，先不要著急的去著手做，而是先分析目前的情況，把問題的背景了解清楚，尤其設計需求時，先去了解目前現有的整個業務流程，產品邏輯，實現方式，資料儲存和傳輸方式，當我們都了解清楚，在做產品設計時，自己就能先評估需求是否可以實現，不能實現的原因是什麼，通過什麼其他方式可以解決，我們可以先拿著產品解決方案去跟技術先碰，等到都沒問題時再做具體的需求設計。
這樣的過程可能會讓人覺得時間比較長，繁瑣費事，但是好處是不用返工，在過程中你可以清晰的了解整個產品架構，底層邏輯，後面再做產品時，就會順利很多，效率也會提公升。這種方法普遍適合對業務不了解的產品或新手，當你都在乙個team呆了好幾個月，還因為產品設計的邏輯問題和需求不能實現卻不知道原因被開發噴的時候，就該找自己的問題了。。
9樓：紫電清霜
就這個問題，個人覺得，正常情況下產品經理的要求應該都不是很過分，或者說應該不是類似那種你給我造個鋼鐵俠出來的需求。
那麼，一般情況下並不存在絕對的做不到，只是更多的是程式設計師與產品之間對這個需求本身存在異議。
我們不會畏懼乙個複雜的需求，但是在時間和精力有限的前提下我們不會盲目承諾任何事情。同時也不會為了個無關痛癢的需求去打亂自己腳步
10樓：孫尚香
看到產品經理就好想黑啊~
在網上看到乙個段子：有乙個殭屍想吃人類大腦，於是他就去了殭屍熟食店：商務的大腦:
10美元/磅；運營的大腦:15美元/磅；程式設計師的大腦:20美元/磅；PM 的大腦:
1000美元/磅。於是他問店員「為什麼PM的大腦這麼貴」。店員回答說「你知道我們必須殺死多少 PM 才能獲得一磅的大腦嗎?」
11樓：
平心而論，不該問如何「應對」這樣的問題，而是為什麼出現這樣的問題，不要把程式設計師當成你的敵人，當你把他們作為敵人的時候，你就有了怎樣「應對」這樣的「問題」的情況。
你是否有一下問題：
1，你們在做同乙個產品，都為了產品更好，他是否也這麼認為，如果不是，這是你的問題；
2，你是否有「產品經理」的立場，還是個掛名「產品經理」的專案經理，把他們當人力（人天）而不是合作的工作夥伴；
3，程式設計師居然都去在乎投入產出比，是否你的產品根本就是個專案，而不是產品，而非得硬生生的掛上這個title；
4，再問問自己是不是真懂開發，是否自己今天東乙個主意，明天西乙個想法，如果是這樣，鬼才來了也白搭；
5，最後乙個，你是否是個合格的產品經理，自己能力是不是能夠完全勝任自己的本職工作，你的能力是否給對方造成了對你能力的不信任；
如果你以上問題沒有，那就把他們換了吧，他們能力不行，也只能這麼說了
12樓：我欲乘風歸去
其實這個本質上真的是乙個溝通和雙方意識問題。
產品經理當然要在技術上多做一些了解和積累，除非技術人員水平足夠高並且溝通服務意識足夠好。
技術人員一定要有產品思維，去溝通了解哪些是重要的，哪些是不重要的。放平心態給出合理的解釋和建議。
否則怎麼著兩邊溝通都會很累的。
產品經理和技術人員的這種搭配方式，我覺得基本要素是各方的水平和意識都比較好。否則合作起來真的很累，而且會出各種各樣的問題。
回到樓主問題，具體的解決方案建議：
1、產品經理放平自己的心態，積累技術，學習溝通；
2、站在技術的角度上把問題再考慮一遍，是否對技術人員的要求確實不合理。若不合理，調整之。若依然合理，尋求更高水平的技術經理的幫助，甚至CTO或者CEO。
如何應對產品經理甩鍋？
Bamboo是竹子 事前明確任務分工及DDL 掌握規則，分清權責。當接到老闆的工作任務後，要做到工作透明化，和小組成員進行分工，要明確以下四方面 工作內容，工作量，工作職責及截止時間。利用郵件等工具留作備份，並抄送自己和對方的上級 其他團隊成員平時在工作中要養成不用口頭方式交流的習慣，在工作的過程中...
初級 產品經理 在不懂技術時如何應對極個別 RD 的故意刁難或推諉扯皮？
日野俊基 作為開發談一下吧。1.關於重構 設計和試錯是需要成本的，只有團隊裡雙方都作出必要的退讓才能實現。2.關於需求 元需求是妥善解決問題必須的，但開發也別想著忽悠或者越俎代庖，將方案利弊鋪開，讓策劃自己權衡。3.慢慢來，其實是最快的。能夠盡量有條不紊的把問題解決，比快更好。忙中出錯是必然的，策劃...
產品經理，遇到強勢的業務方如何應對？
產品經理的那點事 業務方一般有老闆，合作方 合作夥伴 客戶，使用者，運營等公司內部人員。這種 強勢 指的是性格強勢吧。每個公司都有自己的核心目標，既然業務方提需求了，從業務方自己的角度肯定有一定道理，但是業務方僅僅是站在自己的角度思考提出需求，這都沒問題。但是作為產品經理，要有同理心和大局觀念。同理...