軟體導入的過程

Perforce是一個適合大型專案開發用的版本控管軟體。我們這個團隊一直以來使用perforce來做我們的版本控管。不過最近聽說subversion還不錯用，而且還不用錢，因此我們也嘗試著想要引進subversion來做我們的版本控管。

Subversion導入負責人：現在我們要引進subversion。環境跟帳號都已經開好了。請大家每次改檔或是每天早上來公司時就先update一下code。改完後再commit code…。

團員A：負責人，我要怎麼知道這個檔案現在有人在改? 不然我要上code時都會被reject。還是有沒有什麼其他的功能，可以讓別人知道我現在在改這個檔案?

團員B：負責人，subversion有沒有像perforce有force sync的功能?

Subversion導入負責人：ㄟ…你們講的這些功能，subversion都沒有耶~。可是它的介面比較簡單好用…

團員A：什麼好用，難用死了，沒有force sync、又沒有辦法可以知道現在這個檔有人在更改，每次都會conflict，每次都要手動merge。以前都不用merge，就算要merge，用auto-merge就可以了，perforce就會自動幫我們merge好，都不用再去手動merge。還有啊，以前看到有人在改相同的一個檔案時，就先放著等一下就好了，先改其他的code。現在用subversion都要問一下：「現在沒有人在改這個檔案啊? 沒人改的話我要改囉」。難用死了，以前用perforce都不需要這麼問，現在換一個軟體反倒要這麼問，這說不過去啊…。

於是在團員們的抗議下只好終止引入subversion這套系統。

這讓我想起在讀BPR時，一個最主要失敗的因素就是使用者習慣的抗議。連我們身為最前線的開發人員都會有這樣的心態，再加上領導者又不夠力，也難怪BPR起不來。拿舊有的習慣去使用新的軟體，要求新軟體要可以有舊系統所有的功能跟操作習慣；除非新軟體的設計目標是要完全取代舊有軟體，否則當然會覺得新系統處處彆手彆腳。於是這就牽扯到了新軟體如何去打入舊有軟體的市場。