瑕疵該發生嗎？是理所當然的嗎？

在估算一件任務所需的時間之時，大多數的人都會對主管或客戶這樣說，「X 天可以完成，另外，解 bug 還需要 Y 天」。這樣的說法，在邏輯上其實是有很大問題的，為什麼呢？

首先，所謂「完成」的定義到底是什麼？既是「完成」，為何還有 bug？

其次，我們請這樣說話的人換個位子，讓他當主管或客戶的角色，然後讓他的部屬或是承包商對他說同一句話，你覺得他還會接受這種說法嗎？如果不會，那為什麼他可以對自己的主管或客戶這樣報告時程呢？

當主管交辦你任務，或客戶花錢請你完成一件任務的時候，不會有人會允許你用有瑕疵的成果交差，不是嗎？你也許會不以為然地反駁，「我們的產品都馬還有一大堆 bug 沒解決就出貨，誰說不能帶著瑕疵交差的？」

我必須說，會這樣認為的人，是既不夠道德又不夠專業的！

試想一下，你也是某些產品的消費者之一，當你從口袋掏出辛苦血汗錢，滿心歡喜地購買了心目中的完美產品，之後卻陸續發現一堆 bug，此時你心中的感受如何？

「己所不欲，勿施於人」，自己不希望遭受這樣的待遇，就別這樣對待你的客戶或用戶。就算「零瑕疵」很難達成，我們仍舊應以此為高標準自我要求。我們應該這樣想，做不到其實是自己能力的不足，能這樣不斷地「反求諸己」，才會成為一個夠專業的工作者。如此，工作成果的品質才有可能愈來愈好，不會隨著泛泛大眾向下沉淪。

那些市場上帶著一堆 bug 出貨的產品，說到底，都是一種「不得已的妥協」，並非是「應該的」，更不該被視為是「正常的」！

當我們說出「還要額外 Y 天來解 bug」時，意思其實是，「我們一定會製造出 bug，而且我們還可以預估是哪一種 bug，所以我們知道還需要多少時間去解決它。」你不覺得，這樣的邏輯是很可笑的嗎？如果真是這樣，那為什麼還要分「完成任務」和「解 bug」兩種時間估算呢？

好，如果你認為，那個「Y 天」只是預留的時間 buffer，是用來「以防萬一」的，那就更好笑了，為什麼你在不知道會產生什麼樣貌 bug 的情況下，卻能預知預留 Y 天就夠用了呢？

因此，無論你怎麼解釋，只要講出「還要額外 Y 天來解 bug」這樣的話，都是不合乎邏輯的！

瑕疵可以放任多久再處理？

如果你能真的把「零瑕疵」當成嚴以律己的高標準，我相信，你定無法容忍任何 bug 的存在，定會在第一時間就「立刻」消滅 bug。如果有人會放任 bug 擺在那兒好幾天，甚至是好幾週、或好幾個月的，我敢肯定的說，那個人絕對是團隊中的大 bug！

道理很簡單，因為，被此人放生的那些 bug，其實一直都在暗中干擾或阻礙他人的工作，並且，還會不斷地釋放煙霧彈，混淆他人除錯的視聽。此外，此人所放生的 bug 愈多，這些 bug 累積起來的負面效應會指數型增長，最後會導致整個團隊的工作成果品質失控，客戶只好「被迫妥協」，接受帶有大量 bug 的產品出貨，結果，傷害用戶、傷害客戶，也傷害了團隊自己！

若是團隊能把「零瑕疵」當成品質要求的目標，那麼，團隊肯定會在第一時間就把 bug 消滅，不讓它們有任何作亂的機會。況且，在第一時間就去調查 bug，團隊的記憶通常都還很鮮明，解起 bug 來，速度當然就快得多，團隊效能自然會很高。

過去我曾經帶領過一個五人左右的研發團隊，開發一個需在電子郵件伺服器上運行的應用程式，因此，對於此應用程式的可靠度和效能，要求都非常地高。在八個月的專案開發期間，我的團隊恪守上述心法，「解 bug」先於「開發新功能」，竟可做到「待解的總 bug 數量」常態性地守在十五條以下，且極少有 bug 能存活超過一週。

儘管我們也沒有真的做到「零瑕疵」，但因為我們堅守此心法，故而團隊解 bug 的速度其快無比，專案成果的品質奇佳。更重要的是， 團隊也因此變得更有自信，士氣更為高昂，加班變少，生活與工作也變得更加地平衡。

瑕疵該以用戶故事紀錄、跟催嗎？

談到這裡，相信聰明有智慧的你，已可了解，「看待 bug 的態度」才是一個專案品質管理的重點，而不是如何記錄和跟催那些 bug，更不是你用了什麼 bug 管理系統。如果團隊能堅守上述心法，那麼，很多時候根本就不需要紀錄和跟催 bug，因為 bug 往往在幾分鐘內就被解決掉了，根本就還來不及被登錄呢！

既然如此，那為什麼我們還要浪費時間去紀錄、跟催一大堆 bug 呢？

敏捷方法 所力推的，就是「不斷提升團隊效能」，若團隊能落實上述心法，隨時且即時控管好工作成果品質，不就可以省下大量紀錄、跟催、討論 bug 所需的時間了嗎？這不就是提升團隊效能最好的方法之一嗎？

也許你會繼續說，「有些 bug 的真因真的很難抓，真的需要比較長的時間啊？」OK，我同意，的確會有這種案例，但我絕對不會同意，團隊落實上述心法後，這樣的 bug 還會很多。

對於這種 bug，我的建議是，直接把本來宣稱「已完工」的相關 用戶故事 ，改回「未完工的狀態」，並重新安排進 衝刺（Sprint） 執行即可。因為，這些 用戶故事 確實是「未完工」，只是從前「誤以為完工」了啊！

若該 bug 較緊急嚴重的話，也可直接把那些相關「未完工」 用戶故事 ，插隊到現行 衝刺 來優先處理，也無需把 bug 畫蛇添足地定義為一個新的 用戶故事 。

如果一時之間，團隊還無法確認最終的解決方案應該為何，那麼，團隊可以用一些簡易快速的 work-around 先「止血」，也不需浪費時間為這 work-around 寫個 用戶故事 ，畢竟這只是短暫的應急措施，需要很快速做完，也需要在很快的將來把它給移除掉。

不過，為了跟催、產出最終的正確解決方案，這時最好就寫張 用戶故事 ，並註記此 用戶故事 完成後，需一併將相關 work-around 移除，以免出貨時留下一大堆莫名其妙的 work-around 在裏頭，導致日後維護作業上的困擾。

至此，我們可以說， 落實專案品質管理心法，是提升專案團隊效能的關鍵，最終能有效激勵專案團隊的士氣 ，這一連串的蝴蝶效應，實不可不慎呢！

全文授權轉載自 威廉網紙 的 敏捷品質管理：笨蛋！問題不在是否能做到「零瑕疵」，而是在「看待瑕疵的態度」

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。

怎樣給部屬回饋才有效又不傷和氣？學學「三明治回饋法」實作要領

上司不好當，管理階層需注意的「情緒勞動」

【菜鳥主管成長日記】不知道怎麼培養幹部來接班？善用培養幹部五部曲，教出會帶人管事的好主管！

專案成果的爛品質到底是怎麼形成的？正本清源的解決之道又是什麼？

點我看更多

盧老師曾任HTC軟體專案經理團隊主管，掌管上百個智慧型手機軟體專案（包含全球首款WiMAX 4G手機），總出貨量超過 1,500 萬支。亦曾於趨勢科技、友立資訊、華康科技、文生真空科技等企業擔任研發部門主管、產品經理，以及總經理室協理等職務，領導軟體研發團隊與管理專案之實務經歷超過20年。 盧老師在教學上善於利用遊戲化教學，將真實情境轉換為模擬個案，引導學員透過動手實作來學習管理知識。授課經驗包含兩岸多家知名企業，例如台達電子、華碩電腦、揚智科技（台北/上海/珠海）、久元電子、飛宏科技、宜鼎國際、精技電腦、震旦集團、南僑集團 (上海)、杏輝醫藥集團、新北市政府等。

您正在瀏覽的是 Project Up （專案管理生活思維）網站。由兩位管理顧問/企業講師 張國洋（Joe）與姚詩豪（Bryan）共同創立。

我們的初衷是建立一個共享知識平台，將專案管理、產品開發、時間管理與企業經營等知識，用淺顯易懂且容易實踐的方式，分享給大家。

如果您喜歡這裡的內容，歡迎分享給身邊的伙伴（請註明原作者與出處）。也歡迎有空來逛逛姊妹站「大人學」，裡面有更多職涯發展、兩性關係、個人成長相關的精彩內容。或訂閱同名的Facebook、Instagram專頁，取得最新訊息。部分內容也會以音頻的形式在「大人的Small Talk」podcast節目中放送！

Email信箱：[email protected]

首頁 | 大人學 | 關於我們 | 隱私權政策 | 服務條款 | 加入我們

識博管理顧問公司  台北市大安區仁愛路四段107號9樓  02-2711-2720 [email protected]

專案管理的生活思維 © 2007 All Rights Reserved.