![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjveFO2clR2WymJkv71_JM67MU1B0cr7mXjaJ6ydDNC7getIugUMqz8rZy6_17Dkst9XHnDXcLkl3VH0FE45LI1C0tcxRcFYQ90f_kGEGN5KlK9hsxTG7OzY1KSg_-dWp5AYrNrn-yXcFs_wdN-xPpxw1-XpAY9SL5rzRLT_bwRiq67DvfQZEdWMdgZzw/w640-h366/group-programmer-pic2.webp)
無論是大型軟體公司,還是小新創公司,軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證,遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者,孫子兵法有云:兵聞拙速,未睹巧之久也。似乎都在說速度比任何事重要。
然而,做完軟體主管,唯一不能做的事情,就是犧牲品質,現在犧牲品質,下一個犧牲的就是自己和開發團隊,接下來就是公司本身。
兵聞拙速,未睹巧之久:指的是快速決定一個方向,並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條(或者只能期待對方更差)
為什麼不能犧牲品質?
(1)如果PM/Sales/BD說可以不再太在乎品質?我需要在乎品質嗎?
當然要在乎品質,事實上,負責任的人會是決定的人。當軟體出現問題的時候,難道PM會負責改code上patch?最終負責的人就是會真正感受到痛苦,並且付出代價的人。軟體品質有問題,會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價,當然就不能決定品質。
(2) 這次改動範圍大,但是有環境上的時間限制deadline-driven的開發,難道我能說品質不好就不上線嗎?例如耶誕夜12/24要上線,無論如何耶誕節都會來,已經做得差不多了難道就不上線嗎?
品質是可以有範圍定義,畢竟不能可能期待大型系統完全沒有bug。但是,即便是有環境上時間限制,如果品質真得無法達到要求,上線只會讓事情變得更糟糕。最近的例子是7 pay,而我們其實可以輕而易舉地找到很多過去的例子。
那麼,為什麼還是會被「逼」上線?許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短,大家工作這麼拼,每天都加班,品質要是有問題應該「高層能理解」! 這絕對是錯誤的認真,品質有問題的話,「高層」只會知道你們做得不好,更糟的是,你自己已經知道做得不好,連自己的良心也都過不去,而使用者拿到品質差的軟體,當然只是浪費他的時間,這會是個lose-lose-lose三輸的決定。相反的,直接說品質不好無法上線,高層也是知道你們做得不好,但起碼你不會對不起自己的良心,最起碼不是雙輸決定。
(3) 真的沒有時間怎麼辦?
時間資源,品質,規模範圍:這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話,會自動犧牲品質。然而,其實品質是可以控制,但絕對不能犧牲,因為一旦犧牲,整個軟體不能做出本來該做的事情,有再多功能,用再快時間上市都沒有意義。
因此,其實最應該考慮的是規模範圍,簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up(精實創業)的精神。