最近看到一篇文章
「舊系統不好用，叫IT人員「砍掉重練」做個新系統最快？最好再多想想！」
http://www.techbang.com/posts/39297-boss-likes-to-call-it-the-old-system-off-heavy-practice-but-it-is-not-necessarily-better#top
內容跟我的想法很接近，印象中我曾經有寫過關於把舊系統打掉重練的文章，但可能在草稿階段就胎死腹中還是砍掉甚麼的，我目前找不到我寫的文章
我這篇想重新描述一下我的想法
先講為什麼要打掉重練
通常因為使用者在使用上有些問題，而開發者改不太動或者判斷打掉重練比較快
也有可能是開發者想玩新技術，所以就想打掉
開發者想玩新技術的事情，可能會讓人覺得很不合理，要玩新技術沒必要拖整個現有能運作的系統下水，但是就如我以前有次面試時面試官說過的話「軟體開發本來就會有很多鳥事，所以你要open mind」。反正鳥事夠多了，再多一件也沒啥大不了的。
再來講該怎麼看待打掉重練
通常對於打掉重練這件事情，不用寫程式的態度通常都是：「就現有程式複製貼上改一改就好了」(我有次面試，面試官就這個態度，那面試官是老闆)
結果往往變成，使用者要舊系統帶來的好處，也要舊系統無法帶來的好處，這之間有時可能會有衝突，但是使用者就覺得本來就該這樣，於是產生爭執。
而我的主張則是：該當作重新開發一個全新的系統來看待
不管舊系統能做甚麼，只專門著重於新的系統要甚麼，在系統分析時就把該保有舊系統的甚麼，新系統該增加甚麼給搞清楚
如果舊系統那麼好，舊系統能做的都要，那乾脆直接改舊系統就好了，翻新做甚麼
尤其舊系統的實際邏輯可能沒有人清楚，硬要保有可能也根本沒人搞清楚到底新系統該怎麼運作才是對的，既然不知道甚麼是對的，程式設計師也不會知道程式該怎麼寫了
只會變成程式設計師隨便寫，驗收的人看了覺得不好就改掉或整個功能翻掉，這樣改幾次後，新系統可能又跟舊系統一樣存在很多問題(問題不一定存在於看得見的行為，也可能存在於架構上)
我相信不把打掉重練當開發一個全新的系統來看待這件事情，是很多系統翻掉失敗的原因
我的經驗：
我之前在某間我覺得開發很亂搞的遊戲公司就有過兩次系統翻掉的經驗
第一次就管理爛，管理的不想花時間溝通，只是想應付這件事情，出事就推給開發者，該做的訪談都不想做，結果時間花很多，最後產出也不符合需求，變成重寫比較快
第一次翻掉的時候因為我設計整個程式的架構，系統規模小，我也很熟悉要做甚麼，所以整個系統就換一個架構
當時我本來想做得更好，解決一些現有系統做不到的事情，但因為管理者的問題，有些問題就不處理了，反正大家也都能接受，那就這樣吧。
(如果要解決問題，需要資料庫結構大改，還有建立新的作業流程)
第二次的問題根源是當初開發的當事人都跑光了，而公司的開發就是沒有方法的硬幹
沒有系統分析師、沒有系統文件、程式架構也很糟糕(沒啥分層的觀念)
第二次的過程中也有些鳥事，我是覺得也是個糟糕的系統，但我不是主導者，我只是依照別人的指示做事
要是指示有問題，我就會產生有問題的結果，在系統改好之前我離開了那間公司
我是相信新系統肯定也有很多問題
要用甚麼樣的方式翻掉新系統
需要看現有系統的相依性如何，以及要調整範圍(例如要不要重新設計資料庫結構)，以及該怎麼讓使用者切換使用的系統(一個個工作項目換還是直接整個系統切換)
如果變動很大，甚至要改資料庫結構，那就該走一般瀑布式的開發作法
如果使用者也不太清楚自己要甚麼，也沒有要大改最底層的資料庫設計，那我想用敏捷式的做法打帶跑會比較合適
但我認為敏捷式的開發者所需具備的物件導向能力的要求會比較高，而且也需要決定需求的人(product owner)能夠一直花時間釐清與解釋需求
成功翻掉系統要甚麼條件
1.有成功開發全新讓人滿意的系統的能力
有的人對現有系統不滿而覺得翻掉會比較好，但他們可能沒考慮到開發團隊本身是否真的有這樣的能力
可能開發團隊都以為自己可以，但其實沒有能力
至於是誰沒能力，可能是開發團隊，也可能是管理者，又或者可能是相關單位無法配合，可能原因很多。
我是認為管理者好壞很重要，原因是：「好的管理者可以把爛開發團隊或濫相關給處理掉，但是好的開發團隊無法把爛管理者或不配合的相關單位給處理掉」
2.足夠的資源
有的老闆不想花費足夠資源，我相信那種最後不會有多好的結果的。(我在那遊戲公司第一次翻新系統失敗就是資源不足)
3.系統要做的事情變動不太高
如果系統需求變動太快，就算用scrum可能也沒辦法
如果不具備條件，那就該放棄，否則失敗是很有可能的
失敗可能會有甚麼樣的結果呢
好一點的狀況是全部使用者切換到一個不太好用的新系統，過程中可能因為系統有問題而造成些損害
麻煩一點的就是新舊系統同時存在而都需要維護
我以前曾經去一些公司面試，公司存在多個使用不同程式語言的系統需要維護
像是VB、ASP、ASP.net(webform)、ASP.NET MVC之類同時需要有人維護
這種公司我會覺得有問題的可能性還挺高的，因為多種程式語言會導致找人維護會是個麻煩
而他們讓這個問題一直存在而無法解決，這表示能力不足或不願意提供足夠的資源
把系統打掉重練難度跟重新開發新系統差不多
好處是：
有現有系統可以看，讓提需求的人比較「有感覺」能知道自己要甚麼
壞處是：
相關人員可能會把事情開看得太簡單，甚至找藉口不討論與思考到底系統要做甚麼("啊 不就跟舊系統一樣就好了")
推倒重來是否不如逐步改良？
文章中有提到“推倒重來” 往往不如 “逐步改良”。
我是認為看情況，如果現有系統的程式架構很糟糕
程式間的相依性太高，驗證與測試將會是個問題
到時將會需要大量的測試與重構，修改次數多了，出槌是很正常的
在不太容許失敗的台灣，這會變成開發者不該犯的過錯
不如整個翻掉，反正開發過程中有Bug本來就很正常，甚至產生Delay或弄個更爛系統很可能也被視為正常的
如果程式架構還不錯，通常也不太會有人想要翻掉(翻掉的成本與代價太大了)
結語：
我認為要成功翻新系統，對「翻新系統」這件事情有正確的認知是很重要的
如果你搞不清楚你要面對的是甚麼
那事情產生出乎意料的結果將會是很正常的事情
但相對的，如果你很清楚你要面對的是甚麼
也有成功所需要的條件
那麼我相信把「翻新系統」這件事情做好是可能性極高的
(雖然，我覺得在台灣要具備成功所需的條件是件可能性極低的事情)
留言列表
