產品部和技術部，在**的開發過程中，是兩個需要密切配合的部門，很多**甚至將這兩個部門合併在了一起，不過大部分還是分開的。在網際網路開發過程中，這兩個部門的溝通效率，對於最終**的質量有著非常重要的意義。筆者嘗試將工作中這方面的一些體會分享出來，供讀者參考或者指正。
首先簡單的介紹一下在大眾點評網的乙個典型的產品開發流程。
第一步是產品創意階段，這時候可能是乙個很粗線條的點子，或者只是乙個問題，還沒有答案，然後通過頭腦風暴來收集點子，這個階段由產品部主導，有時候各個部門甚至是**會員都會參與進來。
第二步是產品設計階段，這個階段仍然由產品部主導，將原先很粗線條的點子細化為乙個可以實施的方案(文件)，並有一些簡單的原型出來(頁面靜態效果)。
第三步是產品評審階段，這個階段將由產品部和技術部的人員一起參加，產品部的產品負責人講述該產品的實施方案並展示效果，參與評審的人將就產品方案的合理性、可實施性乃至更加細節的ui等提出各種意見，而技術部的相關人員除去這些問題之外，還將關注產品的一些隱性需求，而這些需求往往是產品經理容易忽略的。如果產品通過評審，那麼該產品將進入到技術部的實現階段，否則，產品經理將負責修改該產品設計，再進入評審。
第四步是技術設計階段，這個階段由技術部負責，在這個過程當中，技術部的負責人將和產品經理進行更加深入的溝通，所有的細節在這個階段都需要落實，在框架設計評審當中，某些情況還需要產品經理參加，以確認因為一些技術上的要求改變產品設計的可能性，比如由於效能上的要求而不得不放棄一些個性化的設計等等。
第五步是技術開發階段，這個階段很容易理解，不多講述了。
第六步是測試階段，參與測試的人員包括：開發人員本身，技術部測試人員，產品經理，有時候還會包含部分會員。
第七步當然是發布了。
由以上的開發流程可以看出，產品設計人員與技術開發人員的溝通，主要集中在第三步產品評審階段和第四步技術設計階段。在這個過程中，有幾個方面是需要特別注意的。
第一點：聽
在別人講述自己的產品設計或者技術設計的時候，先不要急於發表自己的觀點，有問題可以先記錄下來，讓對方完整的表達清楚以後，再發表自己的觀點，這樣的效率要比隨時打斷對方好的多，而且往往你想要問的問題，對方其實已經考慮過了，只是還沒有到講述的時候，所以一定要善於聽。
第二點：複述
這個非常非常重要，當你聽完對方的表述之後，請用簡短的話來複述一遍你的理解，而不是用一句「我知道了」，或者「我明白了」來作為你的反饋，往往資訊在這個溝通過程中會因此丟失而產生誤解，所以，複述一遍，會對提高你們溝通的效率產生極大的幫助。
第三點：去理解設計背後的需求
無論對技術開發人員還是產品設計人員，都應該去盡量理解對方設計背後的真正意圖，而不是僅僅關注設計本身，只有這樣，你才能在之後很多細節的判斷上有足夠的判斷力而避免更多的溝通成本或者出現差錯。
當然，溝通作為一項重要的職場技巧，本身有著很多需要學習的地方，這個不是本文想要討論的地方。
開發人員應具備的產品設計意識
有時我想 開發人員應該具備怎麼的產品設計意識呢？有時我對一些軟體的醜陋和非人性化操作是不能忍受，感覺開發人員具備一些產品設計意識實在很有必要了。我想需要簡單做到簡單兩點 介面的和諧統一和操作的人性化。首先需要明白的一點是很多時候介面做得差並不僅僅是缺乏產品設計的意識，更可能是缺乏認真細緻的工作作風。...
測試人員和開發人員應該如何溝通
其實作為測試和開發來說，兩方類似於建築方和質檢方，乙個實現建築高樓大廈，另乙個針對質量不合格的進行拆除。所以，兩方有矛盾是再正常不過的事情，但通過下面的一些建議，在換位思考的角度去理解下開發人員的情況，那麼很多問題自然可以化為無形。1.要懂得尊重對方。開發是一件需要全面和綜合考慮的工作，開發工作中，...
產品經理與開發人員的矛盾
1 是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？2 需求文件 功能文件 最新而最全的原型設計文件，這些要求過時了嗎？3 產品經理高階建議。軟體工程領域，本著分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員...