網頁制作poluoluo文章簡介：外面大部分賣的專業書籍中，對於人和人溝通的技巧講了不少，主要偏重於市井生活的欲拒還迎、官場上的溜須拍馬、或者商場上的爾虞我詐，厚黑的概念從一而終不曾改變。但是在我們的設計行業中，溝通的方式多少有點技術化，甚至我可以講大部分設計師是討厭勾心斗角，並且嫉
第二部分如約而至，繼上篇中提到的協同的問題，雖然構架稍微清晰，流程也有針對性的調整，但是在做事的過程中，人和人之間如何打交道還是成敗的決定因素。好的事情由於壞的溝通會變得很壞，導致方向的偏差，而壞的事情由於壞的溝通也許會變得很“好”，隱藏了真相與風險，導致問題最終不可收拾。
外面大部分賣的專業書籍中，對於人和人溝通的技巧講了不少，主要偏重於市井生活的欲拒還迎、官場上的溜須拍馬、或者商場上的爾虞我詐，厚黑的概念從一而終不曾改變。但是在我們的設計行業中，溝通的方式多少有點技術化，甚至我可以講大部分設計師是討厭勾心斗角，並且嫉惡如仇的，如果溝通一直處於一種灰色的地帶，那麼潛規則將越演越烈，最終形成對行業和個人的傷害。
那麼，嚴肅而合理的溝通究竟有沒有呢？從我自己的經驗來看是有的：
1. 溝通的情境
我們經常說的一個詞，叫察言觀色，這個技術在用戶測試與可用性研究中是非常重要的手段，強調研究過程中的觀察與分析的要素，而既然我們都是用戶體驗的從業人員，為何在情境轉變以後，又不善於利用這種技術呢？其實在項目管理的過程中，設計師與程序開發工程師、產品經理、市場人員、老板的溝通上都需要“不同的情境不同的溝通方式”。
向上溝通，提供價值 — 和上級領導溝通的時候，如果你希望提出一些需求的話，最好先准備好證明自己價值的材料或工作成績，作為管理層最不願意參與的事情莫過於員工的自我管理，如果一個溝通過程（絕大多數情況是某些會議）顯得缺乏准備，沒有預期效果，那麼我建議你最好不要先通知領導參加，否則他只能看到你處理事情上的不成熟。
優秀的技術型領導多半關注真實的數據和行業發展趨勢， 溝通的基礎是你解決了某些問題，發現了某些更好的方案，而這些價值要得以體現必須得到領導的支持，那麼他會非常有興趣。最沒有效果的溝通方式是，兩個技術人員在領導面前吵架，如果你經歷過，你可以回想這樣的場面是否給你帶來了正面的評價。
平行溝通，注重成效 — 項目UI設計師和軟件工程師、WEB設計師與前端開發人員、各部門內部成員之間，這種叫做職能平行關系，這種溝通之間，最重要的就是溝通的成效。缺乏成效的結果是造成信息的衰減，最後影響到不同人員之間的工作量。比如：一個需求的變更，如果沒有在第一時間讓項目組成員完全了解，就會導致最後一個工作部分的成員積壓大量未知的修改和不確定工作內容。
在平行溝通中，為了節約時間和提高效率，大部分人不喜歡使用文檔，而這正是溝通失敗的主要原因，越是聯系緊密，工作成果傳遞迅速的平行關系成員，越應該建立有效快速的文檔迭代體系。這樣才能保證在任何一次小的需求變更上都有明確的記錄，這個好處一是不能賴賬，二是有脈絡可循，三是工作量評定很直觀。
向下溝通，履行職權 — 工作向下傳遞的過程中，遇到的阻力往往來自於時間壓力還有項目人手的壓力，我之前說過的部門牆會在這個時候發揮巨大威力，如果碰上不太踏實的團隊和流程，你大可以看到同仇敵忾的場面。這個問題的最簡單解決辦法就是在項目開展初期，即明確各個部門的職權與關鍵點的評審責任，比如：頁面實現一定要遵守頁面設計效果圖，代碼效率一定不能低於某款產品的標准，軟件開發一定要滿足交互設計的預研效果…… 確定一個配合的主次關系，再輔以資源支持的范圍，利用好話語權決定溝通以外的事情。
2. 溝通的閥值
溝通的閥值是指溝通的心理底線，每個溝通的過程總是會有目的，達到這個目的會影響每個參與溝通的人的心理價位，一般來說，如果你要確定溝通中的有價值的部分，你需要回答四個問題：你的意見或者批評 — “有用的是什麼”、“沒用的是什麼”、“如果這麼做，得到什麼”、“如果不這麼做，失去什麼”
如果溝通過程中，你說的話沒有解決以上4個問題中的任何一個，那麼你說的話基本是廢話，沒有溝通的必要。
溝通中有句真理：角度決定程度。我們一直提倡換位思考，但有時候換位是沒有必要的，也不是非常客觀的，換位的本質是希望找到共同的戰略目標和利益鏈，如果你們之間的戰略目標有較大的不同，那麼換位顯得有點假惺惺的多余，這時評價的唯一標准不是妥協，而是找到正確的溝通切入點，以及在做事上的程度。比如：關於設計時間和設計品質之間的取捨，過分追求時間和過分追求品質都是有問題的，切入角度在於品質引起危機，還是時間引起危機，如果客戶說1個月不交付就不簽單了，那麼你還能追求品質最大化麼？如果客戶支付的成本足夠你利用2個月來完成設計，那麼就應該投入足夠的精力去面對它。
3. 溝通的門檻
減少溝通次數 — 這裡說的是減少無意義溝通的次數，有部分產品經理喜歡這麼干，確定責任前開會，安排項目前開會，交付周期前開會，質量評審前開會，反正一切都是大家說了算的，出了問題也不能怪到我產品經理的頭上 — 這種二百五的作風說好聽點是群策群力，說難聽點就是為自己的無能找一堆墊背的。請問所有的事情都是大家做的，那麼你個人的價值在哪裡？
所以，不處在關鍵節點的會議是不必開的，超過關鍵節點關注以外的話題是不用討論的，關於品質和評審的標准是客觀的，不需要溝通的。
降低問題難度 — 溝通的基礎是溝通的雙方（或者多方）都能准確理解對方的意圖，因此溝通的過程就是一個稀釋問題，解決問題的過程，最好的方式是降低難度，一個關於開發周期確定的問題，可以降低到開發人員配置與項目周期的問題，而開發人員配置可以降低到人員數量和工作時間計算的問題，人員數量的問題可以降低到是不是有資源提供加班補助的問題。
大部分項目推進困難，主要問題就是出在 錢 的問題還有 成就感 的問題，但是很多佯裝高貴的設計師，開發人員，產品經理，就是不願談這個直接的話題，反復談什麼企業文化，奉獻精神，流程完善、人員經驗等。
我不得不告訴你，如果你的成員說這個東西沒時間做，潛台詞就是“你沒有給加班工資”，如果你的成員說這個東西有風險，潛台詞就是“你給的錢和職位不足以讓我承擔這個風險”，如果你的成員說這個東西很簡單，可以稍後考慮，潛台詞就是“這玩意做得沒意思，殺雞不能用牛刀”，如果你的成員說我們慢慢來，心急吃不了熱豆腐，GOOD，他可能准備跳槽了。
提出問題而不是現象 — 大部分溝通峰會，如果你注意觀察的話，多數人都樂於提出現象，而不是問題本身，比如: 你們市場部不能老這樣提出修改，產品都沒做完，為什麼要改呢？ — 這個話根本沒有說出問題的關鍵，問題出在為什麼市場部可以提頻繁的修改需求？誰給的權利？客戶的要求由誰過濾的？修改的成本誰來承擔？修改不好誰又來負責？是輸入問題還是輸出問題？
溝通要保證效率，就得在溝通之前准備好真正的問題，圍繞問題，提供解決方法，否則溝通就像領導發言一樣“李總，你帶人把這些問題研究一下，盡快給我結果”，官僚思維帶來溝通效率降低。