外包軟件項目中，Q&A LIST是我們不可缺少的與客戶進行溝通和問題確認的手段。由於我們與客戶在語言，文化，習慣，思維方式等方面存在差異，經常導致在Q&A中出現不夠順利的情況，不僅耽誤了項目進度，而且會增加項目的成本。下面根據我個人對日軟件開發的項目經驗，總結一下如果能夠寫好Q&A。
一、與客戶進行Q&A過程中經常出現的問題。
1. 客戶不知道我們在問什麼。
原因：問題的主旨沒有表達清楚。
2. Q&A發過去了，遲遲得不到客戶的回覆。
原因：(1)對於我們提出的問題，客戶需要調查才能理解，有些問題可能需要研討。
(2)客戶由於其他工作，漏掉了Q&A。
(3)沒有指定回答人。
3. 客戶回答的內容不是我們想要的結果。
原因：我們對問題的描述存在二義性。是客戶理解偏差。
4. 客戶對Q&A中某些詞彙或字符不理解。
原因：在寫Q&A時使用了陌生的專業詞彙或者縮略語。
二、簡單，明確，易懂的Q&A作成方法。
在第一節中描述了Q&A過程中常出現的問題和原因的分析，下面是針對以上給出的對策。
1. 使用同一的Q&A List模板。Q&A中除了有對問題的描述項，還要有以下重要的幾項。
(1)文檔或源碼:寫出引出問題的式樣書，設計書，源碼等等，明確給出文檔名、章節及引出問題的位置。
這樣問題確認人很快能找到相關的信息，進行問題確認。
(2)問題回答者：指定問題的確認人，使得回答人很快注意並給出答覆，免得有重複對應情況。
(3)期望答覆日：指定回答時間，能讓客戶瞭解問題對緊急程度，也使得我們很好的監控QA的回覆。
(4)問題的狀態：至少有兩項，[Open]/[Close]用以表明問題是否得到答覆和解決，並在得到回覆後，更新問題狀態，
發給客戶或者問題回答者，以便其確認。
對於Q&A表中其他項如“問題提出人”、“提出日期”也是要有的，這樣可以很好的對Q&A的管理和監控。Q&A表中如需要有其他的項可以根據項目情況具體而定。
2.採用“先問題後說明”的結構方式描述問題，使問題回答者很快的抓住問題，並根據主題有針對性的去確認問題。
3.要使用盡量簡短、語法簡單的句子，避免冗長、語法複雜的句子。便於理解，確認方便。長句子會使確認者還要對句子進行分析，特別是使用日語時。
4.使用一般疑問句提問，儘可能使確認人使用“是”或“否“來回答問題，比如：進行遠程設定的配置信息需要在客戶端進行備份吧？採用這樣的提問方式確認人可以經過簡單判斷就可以得出結論，並且回答人不必考慮回答的語言，會快就能答覆。提問者得到回覆後，也不需要對回覆進行理解，能快速對應。
5.當對問題的多種可能性不能確認時，或者有多種方案要客戶確定時，最好能將所有的可能性或者方案逐條寫出來，並且編號，客戶回到時，回答編號就可以。這樣可以避免我們理解的偏頗，同時使客戶能夠快速確認，同時對於方案的提出，也節省了客戶研討對策的時間，能夠加快答覆的速度。
例1： 關於式樣書中“XXXXXX”的含義我們有如下幾種理解。
A xxxxxx B xxxxx Cxxxxx
請確認是哪一中理解是正確的，如果都不正確，請說明。
例2：根據我們對式樣的確認，XXX的功能存在XXX的隱患，經過認真討論我們有以下兩個對策來解決這個問題，
請確認那種合適？
（1）XXXXX
（2）XXXXX
6.如果可能，儘量採用圖形來描述和說明問題。對於複雜的問題本身就很難說明，同時加上文化和語言上的差異，就更加難以描述，但是圖形是通用的語言，很形象的說明問題，避免問題說明不清楚。
7.如果一個問題的描述很長時，最好在把關鍵句子和詞用特殊顏色加以標準，以引起注意。
8.對於需求說明書，式樣，設計文檔等中出現的疑問，可以在原文檔的疑問處採用特殊標記（特殊顏色，符號，線條，框框等），以明示出問題點，並採用註釋的方式提出問題。或者截圖附在Q&A表中。
9.如果通過Q&A進行BUG的確認時，一定要將正常系和異常系（BUG發生時）的過程寫清楚。
10.在發送Q&A時，一定要抄送給自己的領導和客戶測的負責人及同事，這樣以便於跟蹤和督促的作用。
在外包軟件行業，特別是對日軟件外包，特別注重細節，所以，寫好Q&A也是項目順利進行的一個基礎。以上是僅是我個人的經驗之談，希望能給大家有所幫助。不足之處請指正。
