如何描述好一個問題。

本週在幾個不同的會議上，和不同的同事過問題清單，發現大家很少把問題描述的非常清楚。導致在覆盤問題的時候，還需要不斷的找到提問的同事詢問，到底是什麼問題。有些時候，我們能得到具體的答案，有的時候，因為時間太久，他自己也記不清楚了。

那麼，如何描述好一個問題，才能夠減少溝通？

就像我們上學的時候寫記敘文，有六要素，時間，地點，人物，事情的起因，經過，結果。對於描述問題，其實也是大概這麼個套路。

問題發生的時間，記錄時間的用途在於可以用於追溯在那個時間範圍，是否有相同的問題發生。問題發生的地點，可以是所在的辦公室，具體操作的電腦，使用的哪套系統。與問題有關的人物：操作人員，操作賬號 事情的起因：就是我們要有什麼樣的業務，準備開始在系統裡面做什麼操作。事情的經過：這一部分是需要重點描述的。在做PPT的時候我們知道，一圖勝千言，在描述問題的時候，如果用圖來描述，也有同樣的效果，如果有相關的影片，可能會更加直觀。用SAP系統舉例，事情的經過包含以下幾個重點內容：a） Tcode：操作的tcode是什麼b） 單據編號：比如採購訂單號、銷售訂單號、憑證號等等c） 錄入內容：在哪個欄位，需要錄入什麼樣的資訊。d） 錯誤資訊：這個最好是有全面的截圖，以及對應的操作，比如是滑鼠點選，回車，或者其他的操作。事情的結果：這個是留著要給後續問題關閉的時候用的。如何解決的問題，是改了開發，還是改了配置，還是使用者操作順序問題等等。

我想，這樣記錄下來的問題，多半是不需要再找提出人去確認的。如果可能的話，接到這個問題的人自己會找相類似的環境，去測試，或者去復現，看同樣的資料和操作，是否會出現同樣的結果。

最好，後面還有個“反思”或者延伸思考，如何避免這個問題。

這樣記錄問題，雖然繁瑣，但是能夠將問題完整的記錄下來，對於其他人也會有比較好的借鑑意義。

一個好的知識庫，就是透過一個一個問題，不斷的積累，才能夠最終構建起來。