關於品質

最近在客戶端，有一經常出現的問題，一直困擾我們--問題資料，經過調查，很可能是某個已存在的bug，在修正前所造成的錯誤資料，所謂[很可能]，基於資料完整度，我們無法百分之百確定是不是這樣，但種種跡象似乎都指向這個defect，另一因素是因為，也許這樣下結論，可以讓我們心理好過點，暫時不必戰戰兢兢地去想，何時會再出現這樣的問題資料。

同一個defect，前前後後花了我們不少時間，在追查問題來回源，回覆客戶，和修正資料，雖然已經修正很久了，甚至在程式中已不復存在，但直到現在，我們仍在為它所造成的影響而付出成本，而我也預期接下來的一兩個月，我們仍要付出時間，去追蹤這個問題。

這幾天，我反覆思考，到底是哪個環節出了問題？在思考的過程中，我曾經想:
1. 是在一開始交代工作時，沒有說清楚嗎？
2. 是在review階段不夠詳盡，導致遺漏？
3. 是在test階段沒有疏失，造成這個漏洞？


以下是我的思考結論:
1. 交代工作，由A交代給B，A沒實際去做過，因此只能抽象地交代B，不管A在腦袋中如何沙盤推演，實際去做時，一定會有不及之處，如果A能鉅細靡遺地交代B，可能表示：
(a). A天 英才。
(b). 或者是A花了非常多的時間，在腦袋中沙盤推演，甚至實際模擬。
我想(b)較有可能，A花了非常多的時間？事情是要交由誰做？如此不就失去了交代的意義？

2. review如果夠詳盡，勢必花費相當於實做的時間，這是不可負擔的。
3. 以目前的test case覆蓋率來看，只足以滿足評鑑，test case的覆蓋率不高，

就不能對測試後的品質抱太高的期望，而且短期內，高覆蓋率的測試，是不可負擔的。以上2，3短期內做不到，為了避免問題，所以我們要期待鉅細靡遺的交代？鉅細靡遺不如不交代 = 自己做，所以公司內大小事務，最後都會落到一個人身上-總經理，鉅細靡遺的交代是很有問題的。

竊以為，負責implement的人，有最好的條件，可以最清楚狀況，最有可能最有機會發現問題，千萬不要抱著，[我只負責我被交代的事務，其它不在我範圍內的心態]，當你在implement，發現某處可能有問題，或是隱隱覺得可能會出包，是的，沒錯，你是第一個發見這個問題的人，請試著把它紀錄下來，跟交代你的人或co-worker一起討論，或是在會議中提出，試著在它上線前解決它(即使已經上線)，如果不這麼做，可能會發生[看吧，我的第六感是正確的]，這時必須付出更多的成本。

要培養發現問題的習慣及能力，可以時時思考user使用時之scenario，個人認為，軟體品質，比軟體時程還要重要，雖然有時我們不得不在這之中做些妥協。