文檔
對于大型或復雜的項目，需要文檔來解釋說明，這是其他任何一種溝通方式也無法取代的。文檔的缺失，不利于大家正確理解項目，也不利于發(fā)現(xiàn)問題。這樣出來的結(jié)果很難令人滿意。
3. 視覺或前端沒看懂交互稿要表達的意思，或者是感到存在問題，卻沒有提出來。
作為交互設計師，我會盡量把交互稿做的精致些，配上詳細的說明，但最后的結(jié)果總是不如預期理想。
4. 還有很多大家當初沒發(fā)現(xiàn)的問題，制作完卻成了大問題……
面對這些問題，我也在不斷的思考解決方法，目前想到的如下：
1. 作為PM，還是要盡量寫需求文檔。首先，需求文檔對理清PM的思路非常有幫助，可以通過它發(fā)現(xiàn)自己還有哪些地方?jīng)]考慮周全;另一方面，它是設計的重要參考依據(jù)，靠簡單的溝通不可能遍歷到所有的用例和需求點;第三，文檔可以幫助其他項目成員有針對性的提出問題，而不是感到困惑和無所適從。
也許有人會問，如果交互設計師從一開始就參與到項目中，甚至是參與需求的確定，還要寫需求文檔嗎?答案是肯定的。需求文檔可以規(guī)范的把需求要點有序的整理起來，對后續(xù)提高項目效率非常有幫助。
2. PM不寫需求文檔怎么辦?
將心比心，沒有人不熱愛自己負責的產(chǎn)品。PM不寫需求文檔，一定有自己的立場和原因。作為項目組成員，可以總結(jié)自己在項目中需要知道和了解的問題，列出一份清單，請PM回答。相信每個PM都不會拒絕為大家回答問題吧。如果覺得對方回答的不清楚，可以繼續(xù)細化問題，直至回答清楚為止。
3. 需求文檔到底要寫什么內(nèi)容，是一個難題。到底什么樣的需求文檔能合理的概括重點內(nèi)容，讓后續(xù)工作順利進行呢?我覺得這是一個長期的摸索過程，需要PM和交互、開發(fā)等角色一起討論，通過長期的項目實踐逐漸得到最適合當前團隊、項目狀況的文檔格式。
前提是：PM及每一個項目成員要認識到大家是一個共同協(xié)作、平等互助的團隊，而不是領(lǐng)導和被領(lǐng)導的關(guān)系。
4. PM不僅提供需求文檔，還應向團隊主要成員整體講述一遍思路。前期溝通主要傳遞想法;中期溝通解決不斷發(fā)現(xiàn)的問題，迭代需求;后期溝通確認問題是否得到解決。
5. 其他角色以此類推。
類似的項目如果做的多了，在這個過程中，就會逐漸形成規(guī)范機制，使得后面的工作越來越輕松。
通過溝通把握微妙的情感：
溝通過程不總是理性的，也有很多感性成分。
大家在一起工作，但又屬于不同的部門或小組，時間長了，難免會產(chǎn)生各種小摩擦。正確的溝通，可以盡量避免這些不快，幫助我們更好的工作，或者說更快樂的工作。要想達到好的溝通效果，需要注意以下幾點：
1. 放平心態(tài)。
不太計較得失，客觀的看待問題，保持心情愉快……這些看起來誰都懂，做起來卻困難的很，需要不停的在工作中磨練自己的心性。
2. 換位思考
你有沒有對某人很不爽的時候?巧合的是，這個人十有八九對你也抱有同樣的想法。對待同一個事情，每個人的立場不同，太過堅持自己的想法，就容易造成誤解和矛盾。很難說誰對誰錯，重要的是客觀認識不同的立場，最后尋求一個好的解決方法。意氣用事不會帶來任何益處。
當你埋怨PM做的不好，溝通不到位的時候，有沒有想想自己是不是也在犯同樣的錯誤?自己有沒有認真的把設計意圖傳達給視覺?每個人都有自己的難處，寬容、諒解，做好自己的事，也幫助別人做好他的事情，才能促使更好的結(jié)果。
3. 真正認識溝通的意義
溝通是平等的，而不是一方強勢的壓過另一方。這是一個協(xié)作的時代，不是個人英雄主義的時代。
4. 積極主動
多思考、多提問、多表達自己的意見。遇到不快的事情不要急著下結(jié)論，或是越想越歪，而是探清事情因果。其實，事情永遠不像我們想的那么樂觀，也不像我們想的那么悲觀。