1、 要看到專案層面，不要只看需求本身。

上面說到的幾點不管是：“資訊不對稱“、”溝通的語言不對稱“、”思考角度不對稱“還是”考核的標準不對稱“是我們常見的幾個客觀隱私。把幾個因素抽取出來剖析，發現還是由於我們站問題的視角的高度不一致造成的。

產品經理只是看到自己得到了商業的需求，策劃了產品的需求，接下來會把很多事情拋給程式設計師做了，那還是站在需求方的角色中。那如果真正的是站在意識層面的專案經理的角度，這個時候看待問題的視眼會廣很多。

這個時候你就想著為了做這個專案這個需求，程式設計師是不是明白了為什麼要做？是不是對這哪些需求的優先順序有了重要的認識？作為產品經理我用怎麼樣一種表達方式程式設計師更明白？是不是需要把時間點等劃定？目前程式設計師的資源和伺服器情況允許他們能做的空間是多大？怎麼樣才能拉動他們的積極性更好的完成這個專案？適當的時候，需要幫助程式設計師做哪些申請或讓步？

對產品經理來說，同樣張羅一件事情，同樣會了得到一個結果，但是中間的過程很可能是完全不一樣的。所以因為思考角度僅僅從做完一個需求死磨硬泡上升到，站在專案的角度去考慮各個關節的風險點、時間點，得到的效果是完全不一樣的。

2、從理解程式設計師開始，換位思考會更好。

一直在問一個問題：“程式設計師是什麼一群人？“就和問自己：”產品經理是什麼一群人？“一樣，有點好笑、有點幼稚。從小工到專家，從CSDN到走出軟體作坊，發現很多很多非常優秀的程式設計師的心聲。

寫php的

寫Java的

寫windows C的

寫liunx C的

寫C++的

程式設計水平一般的

程式設計水平還行的

程式設計水平牛逼的

程式設計水平大師級的

構架牛的

資料庫牛的

勤奮的

懶於思考的

不會JavaScript的

積極的

喜歡鑽研的……

好像都不太合適，因為你找不到解決和工程師溝通的好的辦法。而且這些很多是外在的條件，隨隨都在改變。看到很多朋友一年之間經歷幾個大專案水平突然猛進，態度、一些特點也變得完全不一樣。這個時候你需要的是瞭解和掌握程式設計師，作為職場的人，和我們一樣的人共同需要的一些特點。

產品經理是客戶和程式設計師之間的橋樑。

產品經理要仔細的分析客戶的需求，把客戶的需求轉化成程式設計師能夠理解的具體實現步驟和目標。

所謂程式設計師，往往是一個團隊，有很多很多的成員，產品經理主要是跟這個團隊中的主要負責人進行溝通，只要這個主要的負責人理解了，客戶的需求如何去實現，那麼他就能夠讓這個團隊所有的成員，理解這個專案的目標和要求。通常產品經理沒有必要跟程技術團隊中的每一個程式設計師去溝通。

在技術團隊中，按照不同的分工，這個團隊又可能有分成不同的部門，比如說，有做uI設計的，有做互動設計的，有做前臺的，中臺的，後臺的。產品經理需要根據不同的分工做好對應的技術需求文件，整理好以後交給他們跟他們做好說明即可。