所謂純文本工作報告，即用純文本對工作進行總結匯報。由於沒有Excel強大的數據處理功能，沒有PPT絢麗的表現形式，很多人做出的報告都很難讓人讀懂、甚至晦澀雜亂。
本文，從最原始的一篇報告開始改起，通過7步法（個人理論），將其變為一篇通俗易懂、合格的報告。
原始報告：
上午看了一個小時的需求說明書，另外參考了OutSpec和InnerSpec，算是又通讀整個功能A了，發現了一個需求上的問題，就是哪幾種狀態的XXX可以對它的xx進行修改。跟組里人和領導商量之后，發現是一個我們這邊無法解讀的需求，已經作為需求疑問QA出去了。接着，根據上周做完的SD，差不多11點左右開始了PG，上午編了差不多0.2ks的代碼。
下午用了一個小時完成了整個功能A的實現，總共0.43ks的代碼，有待評審。
A功能的PG完了，領導安排讓測試功能B，客戶說這個功能好像有問題，想知道是不是我們這邊的代碼問題，已經登錄到Redmine上讓我們調查了，所以我就測了一下，最后發現在模擬器里沒有問題，但是在實機環境有問題，客戶后來說不是我們這邊的代碼問題，是他們代碼合並的問題。B功能測試，之后，進行了C功能的黑盒測試，我測了30個用例，有1個Bug，還有一個因為模擬器無法測試，所以擱置了，可能會耽誤進度吧。
隨便拉一個普通人，閱讀上面的報告都會覺得亂，除非某個上司時間多的用不完，或許會一字一句的“研讀”這篇報告。更多的情況，應該是直接丟掉不看。下面，開始修改我們的原始報告。
第一步.分類
分類的方法有很多，而常用的分類方法有兩種：時間類和空間類。
■時間類。即以時間段為類，將各時間段的工作放到一起。
■空間類。即以工作內容為類，將耦合度高的工作內容放到一起。
[原始報告]是用於給上司看的，從上司的角度來看，其關心的是你做了哪些工作，而不是你在什么時間段做了什么工作。所以，依照空間類分類，會讓上司一眼看出匯報者工作的內容，修改后的效果如下：
A功能編碼作業
上午看了一個小時的需求說明書，另外參考了OutSpec和InnerSpec，算是又通讀整個功能A了，發現了一個需求上的問題，就是哪幾種狀態的XXX可以對它的xx進行修改。跟組里人和領導商量之后，發現是一個我們這邊無法解讀的需求，已經作為需求疑問QA出去了。接着，根據上周做完的SD，差不多11點左右開始了PG，上午編了差不多0.2ks的代碼。
下午用了一個小時完成了整個功能A的實現，總共0.43ks的代碼，有待評審。
B功能調查作業
下午，領導安排測試功能B，客戶說這個功能好像有問題，想知道是不是我們這邊的代碼問題，已經登錄到Redmine上讓我們調查了，所以我就測了一下，最后發現在模擬器里沒有問題，但是在實機環境有問題，客戶后來說不是我們這邊的代碼問題，是他們代碼合並的問題。
C功能測試作業
進行了C功能的黑盒測試，我測了30個用例，有1個Bug，還有一個因為模擬器無法測試，所以擱置了，可能會耽誤進度吧。
上面的報告，對於上司來說，可以一眼看出來這個小伙子做了哪些工作，一眼明了，這小伙子一天沒有白忙活，做了三個作業。
第二步. 條目化
條目化的目的是讓看報告的人一眼觀全局，很多新手擔心領導不明白自己寫的什么，於是大寫特寫。其實大錯特錯，領導的經驗是豐富的，你只寫一句，他或許就明白你要表達什么。所以，在匯報工作上，以簡練為佳。
條目化的方法，就是把工作內容核心抽出來，下面是條目化的效果：
A功能編碼作業
1.看了一個小時的需求說明書，另外參考了OutSpec和InnerSpec，算是又通讀整個功能A了，發現了一個需求上的問題，就是哪幾種狀態的XXX可以對它的xx進行修改。跟組里人和領導商量之后，發現是一個我們這邊無法解讀的需求，已經作為需求疑問QA出去了。
2.根據上周做完的SD，差不多11點左右開始了PG，上午編了差不多0.2ks的代碼。下午用了一個小時完成了整個功能A的實現，總共0.43ks的代碼，有待評審。
B功能調查作業
1.領導安排測試功能B，客戶說這個功能好像有問題，想知道是不是我們這邊的代碼問題，已經登錄到Redmine上讓我們調查了，所以我就測了一下，最后發現在模擬器里沒有問題，但是在實機環境有問題，客戶后來說不是我們這邊的代碼問題，是他們代碼合並的問題。
C功能測試作業
1.C功能的黑盒測試，我測了30個用例，有1個Bug，還有一個因為模擬器無法測試，所以擱置了，可能會耽誤進度吧。
上面的報告已經條目化了，可以明顯的看到在功能A的編碼中，匯報人做了兩件工作。
第三步. 簡練化
報告不是作文，是給時間少的上司看的，所以要避免大篇幅的廢話，以最精煉的語言來描述工作內容，描述問題。簡練化后的報告如下：
A功能編碼作業
1.需求說明書閱讀（Outspec、InnerSpec），發現需求不明點，已提QA
2.編碼（0.43ks，待評審）
B功能調查作業
1.Redmine上客戶提的課題調查，問題在客戶方，代碼合並遺漏，已解決，具體信息參照Redmine課題。
C功能測試作業
1.黑盒測試，已測30個，發現一個Bug，一個模擬器無法測試（進度延遲可能）
第四步.數據抽出
在七步法里，這一步其實是最難的，需要經驗的積累，需要敏銳的直覺。就本報告而言，我們來分析一下，缺少什么數據。
1.A功能編碼作業→需求說明書閱讀（Outspec、InnerSpec），發現需求不明點，已提QA
作為閱讀者，想知道這個式樣不明點是什么，他無法找到該問題，因為QA沒有編號，沒有提到登錄的地方。所以，可以追加數據：QA#123，用於指向問題本身的信息。
2.A功能編碼作業→編碼（0.43ks，待評審）
作為閱讀者，想知道這個功能當初預估的代碼有多少，與實際代碼量的偏差是多少，是不是在計划內完成的。他是無法得知的，所以，可以追加數據：預估代碼量，代碼量偏差，計划時間表。
3.B功能調查作業→Redmine上客戶提的課題調查，問題在客戶方，代碼合並遺漏，已解決，具體信息參照Redmine課題
同1.作為閱讀者想知道問題發生的具體細節是無法得知的，所以，可以挖掘的數據：課題#888，用於指向課題本身的信息。
4.C功能測試作業→黑盒測試，已測30個，發現一個Bug，一個模擬器無法測試（進度延遲可能）
作為閱讀者，只知道匯報者測了30個，不知道總量是多少，不知道還有多少量沒測，不知道作業是否在進度計划作業內，所以，這里可以挖掘的數據：總用例量，已測占總量的比重，計划時間表。
修改后的匯報內容如下：
A功能編碼作業
1.需求說明書閱讀（Outspec、InnerSpec），發現需求不明點，已提QA#123
2.編碼
-------時間-------------------代碼量------------進度------
予定：2012/9/25-2012/9/30 0.5ks -
實績：2012/9/26- 0.43ks 100%
---------------------------------------------------------
B功能調查作業
1.Redmine上客戶提的課題調查，問題在客戶方，代碼合並遺漏，已解決，具體信息參照Redmine課題#888。
C功能測試作業
1.黑盒測試，一個模擬器無法測試（進度延遲可能）
-------時間-------------------用例量------------進度------Bug數------
予定：2012/9/25-2012/9/30 80個 - 3個
實績：2012/9/26- 30個 38% 1個
--------------------------------------------------------------------
從上面的報告可以清晰看出來作業進度，以及質量是否在合理的理論閥值內。
第五步.圖形應用
圖形，就是一些最簡單的可以在純文本里顯示的一些符號，主要有：■、▲、※、△、①、ⅱ、→、↑、↓、←、？、★。
圖形運用，靠經驗，靠自己的美感，所以，如何靈活的運用，靠自己的把握了。這里舉兩個例子。
1.對於有或可能有風險的地方，用※標識，並在后面注明風險的具體內容。
2.對於大類別，可以用■標識，因為比較易見，可以很快找到類別。
3.對於數據大小發生變化的，可以用上下左右的符號進行標識。
基於以上三點的運用，修改匯報后如下：
■A功能編碼作業
1.需求說明書閱讀（Outspec、InnerSpec），發現需求不明點，已提QA#123
2.編碼
-------時間-------------------代碼量------------進度------
予定：2012/9/25-2012/9/30 0.5ks -
實績：2012/9/26- 0.43ks↓ 100%
---------------------------------------------------------
■B功能調查作業
1.Redmine上客戶提的課題調查，問題在客戶方，代碼合並遺漏，已解決，具體信息參照Redmine課題#888。
■C功能測試作業
1.黑盒測試，一個無法測試※
-------時間-------------------用例量------------進度------Bug數------
予定：2012/9/25-2012/9/30 80個 - 3個
實績：2012/9/26- 30個 38% 1個↓
--------------------------------------------------------------------
※：無法在模擬器上進行測試，可能會影響C功能黑盒測試的計划進度。
第六步.去冗余
報告類別盡量做到專一，上面的報告還有是有可以改進的地方的，比如A功能編碼作業的1和B功能調查作業所提出的課題，屬於同一個類型，所以，可以A中的1和B抽出來，去除冗余，做成一個新的類別。修改后的報告如下：
■A功能編碼作業
-------時間-------------------代碼量------------進度------
予定：2012/9/25-2012/9/30 0.5ks -
實績：2012/9/26- 0.43ks↓ 100%
---------------------------------------------------------
■C功能測試作業
-------時間-------------------用例量------------進度------Bug數------
予定：2012/9/25-2012/9/30 80個 - 3個
實績：2012/9/26- 30個 38% 1個↓
--------------------------------------------------------------------
※無法測試用例1個：無法在模擬器上進行測試，可能會影響C功能黑盒測試的計划進度。
■課題&QA
①．QA#123。A功能的需求不明的問題，無法確定哪幾種狀態的XXX可以將其xx進行修改
②．課題#888。客戶讓我方調查的課題，代碼合並問題，已解決。
第七步.格式化+美化
最后，對於報告的格式要有精益求精的追求，上面的報告還是有美感問題的，格式的調整就看個人的態度和美感了，一下是修正后的報告：
張三的工作匯報 2012/09/26
■A功能編碼作業
-------時間-------------------代碼量------進度-------狀態----------------
予定：2012/9/25-2012/9/30 0.5ks - -
實績：2012/9/26- 0.43ks↓ 100% ◯（完了，待評審）
------------------------------------------------------------------------
■C功能測試作業
-------時間-------------------用例量------進度------Bug數-----狀態-------
予定：2012/9/25-2012/9/30 80個 - 3個 -
實績：2012/9/26- 30個 38% 1個↓ →(着手中)
------------------------------------------------------------------------
※無法測試用例1個：無法在模擬器上進行測試，可能會影響C功能黑盒測試的計划進度。
■課題&QA
①．QA#123 A功能的需求不明的問題，無法確定哪幾種狀態的XXX可以將其xx進行修改
②．課題#888 客戶讓我方調查的課題，代碼合並問題，已解決。
最后，祝願大家都能寫出高質量的報告，謝謝閱讀。有什么更好的技巧，還望指教，以期進步。