漸進式創新法分類：創新

不斷創新，不斷思索變革之道，也就是要不斷地追求改善。

我想各位聽到「創新」，一定馬上想到龐大的研發費用、一批聰明絕頂的研發人員，NO！錯啦！「創新」並不是來自靈感、來自某幾個發明家。管理大師彼得杜拉克就曾說過：「創新並非來自天才，與靈感也不相干，而是來自辛勤、有系統的工作。」事實上，根據調查，創新的來源也是「漸進多於突破」、「學習多於發明」──取自某演講稿。

一般的程式設計師總會陷入一個迷思，就是只要做好維護的責任，或者是要重視新功能的開發動作，有時因為痛恨舊的架構，所以經常革命性的打掉舊有的程式碼重新再寫過一次，而有人就會有鴕鳥的心態，只是再舊的程式碼裡面加一大堆的特殊處理，來因應不斷出現的狀況，這兩種現象都是太過的做法，雖然都可以解決，但是都會出現很大的陣痛，革命型的做法容易導致客戶有一段的適應期 (debug)時期，時間一拖長，客戶就走掉了，鴕鳥型的做法容易導致一個系統的架構混亂，愈來愈不容易更動。

所以一個良好的系統演化，必須要靠的就是程式設計人員，對於一個系統的觀念是否能往正確的方向走，也是程式設計師的責任，不諱言的，良好的執行者所受到的鼓勵並不是短期間可以看的到的，系統創新的評比也很難在考績上面表現得出來。以下提供幾個漸進式的創新方法......

模組化是一個非常好的方法，只要把模組化當成你的工具，慢慢地將不適用的模組抽換掉，你就可以把系統架構簡單化，未來要加新功能的時候不用在東一個、西一行的加入程式碼來處理例外狀況了。

做紀錄檔統計效能，使用者如何操作系統最清楚的並不是程式設計師，也不是系統分析師，是程式系統的本身，您只要在重要的程式碼做一些紀錄，當然不能影響系統的效能，然後適當的分析這些紀錄，可以很容易的知道系統的瓶頸在哪裡，未來可以用什麼平台、什麼程式語言來開發比較好維護。

絕對不要特殊處理，特殊處理的程式碼就好像是滾雪球一樣，如果是一個大的斜坡，你就會越滾越大，講難聽一點，就好像是說謊一樣，你經常要說另一個謊，來掩飾前面的錯誤，如果架構不對，就要找時間勇於改善系統的架構，花了一個星期來改架構，總比未來花兩個星期來找出 Bug，然後可能賠上幾個系統不穩定的評價好的多吧！

經常在別人的工作報告上看到，了解XX系統的架構、修正XX系統的Bug，其實，這些字句都不應該出現的，除了目標不明確之外，要彌補之前的錯誤，就安排了一大堆的進度，真的非常浪費資源的。

延伸閱讀：【流程】軟體開發過程階段性目標與相容性的做法