1樓：Tiao
1、需求準備階段，有機會的情況下可以提前讓開發同學參與了解，例如吃飯閒聊的時候提一提、或者下午茶休息時可以針對預想方案向開發同學請教請教等等，只要有溝通閒聊的機會都可提前同步些後期可能的規劃與安排。
2、需求評審會的時候，建議不要一上來就講需求內容，我們首先要做的是講清楚立項背景、同步清楚我們目前面臨的問題、我們要達到的目標，等這幾項說清楚後再開始評審需求內容(預想的解決方案)。不只是讓開發同學知道這些，其他各部門的兄弟姐妹也是(設計、互動、測試、運營、業務部門等)；很多時候，我們讓大夥知道更多細節內容，才會真正明白自身的付出是有意義的、明明白白地在工作，而不是一上來安排任務似的，長期下去整個團隊都會覺得做得沒意思。我們要讓整個團隊的人意識到大家是乙個團隊、是在協同作戰，這樣每個人都會覺得很有意義，很有責任感，也會很投入。
3、多加深彼此的溝通與了解，平時抓住一切機會多互動，例如主動請同事吃零食、喝咖啡、吃飯等等（並不是刻意在這麼做，要發自內心的），相信雙方都會有收穫的
4、我們做產品的一定要」靠譜「，沒想清楚的需求一定不要交付給開發，不然時間長了肯定會失信於他們，自然對我們提的需求不想配合；所以自身要嚴格要求自己，勤練內功，努力提公升我們的各項產品能力。
2樓：
2.原型做好標記，改版做好備份，難度提前預告，推薦乙個好用的工具「藍湖」；
3.提需求之前先與工程師溝通，在具備可行性的基礎上，保障創新新，推薦看看《影響力》；
4.盡量少開會，每次會議都做到有目標、有結論、有安排；
5.能當面溝通的就不要發郵件，必須發郵件的，發完之後當面溝通。
3樓：吳俊
我是設計出身.大致路線是：視覺 > 前端 > 產品技術或者設計出身，有利有弊。
弊：做為產品經理（ProductManager），在了解使用者的基礎上需要更多的了解市場，環境，團隊管理，溝通等等，這一點可以參考更多傳統行業的產品經理。另外，據傳Tencent的產品經理還要管錢的，給你一比錢，你自己去規劃你的專案，從招人到專案，到發展都要思考。
這種鍛鍊不可多得。利：在工作過程中會更容易了解可行性。
所以有些公司會把產品經理劃分成幾種型別：規劃型，需求型，市場型，技術型...什麼的.
總之目前個人看來，弊大於利，還是需要多學習，多沉澱。
知行養成社群，可以說是現在氛圍最好的時間管理社群
4樓：Roy Du
作為一名工程師，我想大部分的原因是：
資源大部分時間都是匱乏的，例如時間、人、以及其他等等；
那麼在資源不夠的情況下，來實現某些功能，是不切合實際的，就比如你跑100公尺需要10秒，現在剩5秒了，然後和你說，你必須跑到，你只能說，實現不了。
所以這不是溝通效率上的問題，因為雙方都沒有彼此誤解。
5樓：suduren
讓其認識到本人在團隊中的重要位置及責任榮譽等，盡量多溝通。讓他對自己的行為負責，做技術做產品都和做人一樣，你能力不行，那另說。若是態度問題，那就不能怪不給你做事的機會。
做技術的如果總是說這也做不了那也做不了，那可以明確告訴他，那要你幹嗎，要你和大家一起做事目的就是看中你的良好態度和能力，你不能總這樣，如果這樣的話，你將來如果跳槽你拿什麼說業績，你能和人家公司說，我這個做不了那個也做不了嗎，所以讓技術充分認識到做事不是為產品或公司，其實很多時候是為自己而做。
6樓：
1.產品經理提公升自己的技術基礎能力和技術水平。
2.盡量當面溝通，白板溝通，形式化表達方法最有效。
3.最重要的，了解工程師的思維方式和思維習慣，不要以為自己說的一定就是對的。
7樓：
這個問題太龐大了，個人站在PM角度具體說說你問題中兩句比較最常見的東西
1、PM：這個功能必須有
PM傳達自己對產品的熱情和信念是好的，但要注意方法。反覆說必須有是沒有意義的，如下幾種說法也許更合理些：
根據使用者調研/使用者反饋/資料統計/boss拍磚……我們團隊認為這個功能對產品非常重要的，新增了之後會帶給我們產品***的市場占有率增長/**營收增長/**使用者體驗提公升
總之就是給個理由+畫大餅忽悠。如果工程師不信任你的交付物，就給乙個充分讓他信任的理由
2、工程師：這個技術實現不了
有人說PM應該重點考慮使用者需求，但在實踐中我的觀點是：
a)僅存在於想象中但不能實現的功能點沒法滿足任何使用者需求，是完全沒意義的
b)如果你足夠了解你的團隊和產品，心裡應該很清楚什麼是能實現什麼是不能實現的
c)技術可行性評估應該作為產品先期規劃中重要的環節，不是等到最後要做了才想起來
不過假如工程師對於乙個你覺得可實現的東西說做不了，那麼我一般這麼應對：
a)首先搞清楚到底能不能做，這個可以看同類產品是否有類似的功能，或者諮詢更資深的工程師，或者乾脆給工程師提個需求讓他先去調研
b)如果發現實際上能做的，那麼說明要麼是這位工程師對待工作態度有問題（不加仔細評估就斷言，不是乙個好工程師應有的態度）；要麼就是他覺得這個東西實際上不值得他去做。前者可以通過向上反饋解決；後者的話，就要給他畫大餅了，參見第乙個問題
8樓：蔣又新
很少有技術上真正實現不了的東西。工程師回答「實現不了」的時候，大部分時候是認為你低估了功能的實現成本，潛意識裡不願意自己的勞動被「賤賣」而產生牴觸情緒。所以我覺得，這個時候溝通的要點，是首先表達出你完全明白實現成本很高（先知彼），然後才是闡述這個功能的確很重要（再解己），這樣成功率相當高。
很多技術人員，尤其是基層的工程師，有的時候相當「軸」，其實內心深處僅僅是渴望被認可而不是被使喚。
竊以為，產品人員可以適當學習一些技術的概念，做到對技術實現一項功能難易程度有基本的了解，而又不至於讓技術思維主導自己的工作。這樣對溝通很有利，因為「知彼」的過程能更加真實。試想你完全不懂技術，而對方也知道，你跟他說「我知道這事做起來有些困難」，豈不是很假麼。
9樓：
根據問題描述來回答以下
其實沒有技術實現不了的，就看資源投入了。
開發那麼說，可能是認為這個功能沒有必要這麼做，可以把原始的需求拿出來，聽一下開發同學的建議。
研發工程師 演算法工程師如何轉型做產品經理
Fabrice 如果要轉，做兩年技術就轉，產品經理的薪酬和經驗成正相關，演算法工程師就不一定了，很少看到剛畢業的產品經理年薪50w的，但是剛畢業的演算法研究員工程師的就多多了，要麼就認定做工程，要麼就早點做產品。至於如何轉，內部轉崗是最好的機會，想清楚了 學習點產品的 內部轉崗是最好的路徑了 乙個好...
產品經理如何與設計師溝通？
德心小獸 對於創意性的工作，時間緊還要求高。理性要求可以理解，審美本來就是各抒己見，你說好看就好看？你說不好看就不好看？就算不好看，你有足夠的溝通能力去說服別人接受自己的意見麼？所以說，想做好產品經理，麻煩先學學怎麼與人溝通。設計圖總不行，那就不要總是抱怨別人的能力不足，先看看自己是不是有什麼問題吧...
產品經理和前端工程師哪個好
團團 完全不同的兩個工種 前端可以理解為程式設計師 產品經理是產品的負責人 負責需求落地把需求輸出成開發能看懂的文件並持續監控需求實現驗收收集資料指標等 啤酒 哈哈哈，做了前端又轉成產品的我，只能說 多了解一下真正工作內容，還是找自己感興趣的吧。前景也就能幫你做最初始的決定，但是能不能堅持下去，還是...