對每個定製項目來說，工作產品的質量的高低都是根據客戶需求決定的，要求高，給錢多的，質量就高，要求低，給錢少的，質量就低，這個項目也不例外。做過對日外包項目的人都知道，日本人對質量的要求特別嚴，尤其是那些銀行證劵類的軟件，上線之後的bug數直接影響到能拿到多少回款，多出一個bug就會少拿一筆錢。因此試運行階段，對全部項目組成員來說，都像頂了個避雷針似的，不定哪塊雲就能來個雷炸着自己，雖然不至於直接被罰款，但是加班和捱罵甚至半夜被從家裏叫來都是很可能的，這段時間，要求全員24小時隨傳隨到。爲了避免後面的這些問題，項目的質量從開始時就要求的很嚴，下面詳細說說都是怎麼做的。
一、文檔化
概要設計、詳細設計、測試用例、概要設計的評審、詳細設計的評審、測試用例的評審全部都有一一對應的文檔，我相信能出這麼多文檔的項目沒幾個。詳細設計到僞代碼的程度，測試用例要求所有分支全覆蓋。
當然，單純有文檔是提高不了質量的，但是文檔的存在，降低了溝通難度，很大程度上消除了誤解、理解上的差異並在形成了共同語言，比如說到“銘柄”這個詞的時候，沒人知道是什麼意思，但是項目組中的人都知道這是一個功能模塊。
二、評審
所有的工作產品都必須經過評審，評審採用會議評審和交叉評審兩種方式。
最先產生的工作成果採用會議評審的方式，把大家都可能出錯的地方找出來，統一改正，會議評審一兩次之後，改成交叉評審，這樣可以提高工作效率。
所有的評審問題都要記錄下來，形成評審表，需要橫向展開的問題，進行統一管理。
三、測試
單元測試，連接測試，系統測試，monkey測試，當然還有疏通測試，“V”模型裏提到的所有測試，在這個項目裏都存在，而且所有的測試都有文檔化的測試用例，有測試過程記錄，測試結果記錄，所有的bug都被記錄，被分析，bug中描述不清楚的用截圖表示。
在評審和測試中，單純因爲手誤或者馬虎出現的bug是很難被原諒的，如果是多個人出現相同或類似的單純錯誤的話，則認爲是大家都可能出現的，要所有人把自己的代碼都查一下。
四、限定代碼行數
將每個模塊的複雜度控制在一定範圍內，超出範圍時，進行拆分，以降低開發和查找bug的難度以及出錯的概率。
五、變更記錄
不管是代碼也好，文檔也好，凡是有修改的地方，都要有變更記錄，而且原來的內容不能直接刪掉，要保留。變更記錄中要寫明是誰在什麼時間爲什麼做的修改。
六、工具
這個前面也已經提到過了，基本上都是項目組自己開發的小工具，用來提高工作效率和質量的。
這些管理質量的方法，不能算是這個項目經理的原創，只是這個項目中是這樣做的，而且不僅這個項目，很多對日外包項目都是這樣管理的。