絕不犧牲品質 (成為主管的31堂課)

無論是大型軟體公司，還是小新創公司，軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證，遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者，孫子兵法有云：兵聞拙速，未睹巧之久也。似乎都在說速度比任何事重要。

然而，做完軟體主管，唯一不能做的事情，就是犧牲品質，現在犧牲品質，下一個犧牲的就是自己和開發團隊，接下來就是公司本身。

兵聞拙速，未睹巧之久：指的是快速決定一個方向，並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條（或者只能期待對方更差）

為什麼不能犧牲品質？

(1)如果PM/Sales/BD說可以不再太在乎品質？我需要在乎品質嗎？

當然要在乎品質，事實上，負責任的人會是決定的人。當軟體出現問題的時候，難道PM會負責改code上patch？最終負責的人就是會真正感受到痛苦，並且付出代價的人。軟體品質有問題，會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價，當然就不能決定品質。

(2) 這次改動範圍大，但是有環境上的時間限制deadline-driven的開發，難道我能說品質不好就不上線嗎？例如耶誕夜12/24要上線，無論如何耶誕節都會來，已經做得差不多了難道就不上線嗎？

品質是可以有範圍定義，畢竟不能可能期待大型系統完全沒有bug。但是，即便是有環境上時間限制，如果品質真得無法達到要求，上線只會讓事情變得更糟糕。最近的例子是7 pay，而我們其實可以輕而易舉地找到很多過去的例子。

那麼，為什麼還是會被「逼」上線？許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短，大家工作這麼拼，每天都加班，品質要是有問題應該「高層能理解」！ 這絕對是錯誤的認真，品質有問題的話，「高層」只會知道你們做得不好，更糟的是，你自己已經知道做得不好，連自己的良心也都過不去，而使用者拿到品質差的軟體，當然只是浪費他的時間，這會是個lose-lose-lose三輸的決定。相反的，直接說品質不好無法上線，高層也是知道你們做得不好，但起碼你不會對不起自己的良心，最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦？

時間資源，品質，規模範圍：這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話，會自動犧牲品質。然而，其實品質是可以控制，但絕對不能犧牲，因為一旦犧牲，整個軟體不能做出本來該做的事情，有再多功能，用再快時間上市都沒有意義。
因此，其實最應該考慮的是規模範圍，簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up（精實創業）的精神。