輕鬆談軟工

趁歲末，我花了一點時間，回憶一些各方對今年發表的諺語與部落格文章所提出的意見，雖然這些意見不能涵蓋全面，但多少反應一些現象，這種現象顯示國內軟工教育問題，就是學校的軟工教育訓練不能完全『 學以致用 』，也讓我這個開授軟工課程多年的教師匠有點『做白工』的感覺，嚴重一點說，有點誤人子弟。 話說，從今年2月20日薛教授post上去的『好人難為』一篇文章，以及最近Q39諺語：『Schedule是用來Delay的』說起，我覺得我們的軟體工程師似乎受很大的委曲，大部分的委曲都是說很難與老闆溝通，有人說溝通無效只好忍氣吞聲，或者默認，甚至乾脆打包走人(「好人難為」意見箱)，『‧‧‧要不然抱怨變化永遠趕不上客戶的一通電話』(Q39諺語)，甚至說如果客戶來個需求變更，那(專案)就要delay到天荒地老等等，是不是那麼嚴重，我想還不至於吧，不過我相信這些抱屈都是事實，也都是經驗之談，不過從軟工的角度來看，似乎並不希奇，雖然有幾位教授以及本人對這種現象多少有些解釋也提供一點意見，我相信這種現象並非完全無解，重點在於『學以致用』，要致用當然要『百鍊成鋼』，只可惜據我所知，許多學校的軟工訓練並未提供這種機會(包括我自己)，例如世界上許多軟工界的『先賢』或『現賢』，提供不少設計軟體的方法(methodologies)、原則(principles)、或樣式(patterns)，諸如Agile Methods，Protected Variations及其引伸的OCP、DIP、或Information Hinding等等原則，我不知我們的軟體工程師發展軟體時是否應用到這些『優美』的方法、原則、與樣式？但這些設計原則的確可以解決上述不少問題，我不相信當我們的工程師要應用這些方法‧‧‧時老闆會加以干涉，如果我們的軟體工程界發生這種干涉現象，『軟體工程學會』應該出面解釋甚至說服，學會有責任導正軟體發展的方向，而不是只開開會討論了事，這是我寫這篇不怎麼討喜的短文主要動機。

最近景氣不好，許多公司的MIS部門開始接受到上級的指示，把部門內的產品做一些包裝拿到外面去賣。賣不好，部門的人事可能就得精簡。這對MIS部門的確是晴天霹靂，景氣好的時候公司需要大量的電腦化支援，所以雇用了不少的人，現在人力過剩也是事實，只好硬著頭皮來賣產品。 但是從支援部隊轉換為賺錢部隊並不是一件容易的事，個人認為需要考慮幾點。從  開發者   來看，應考慮幾點 心態調整。 過去的MIS主要以支援為主，不是主要的生產部隊，績效的評估從模糊的『服務績效』變成明確的『獲利績效』。MIS人員是否做好了心理準備？ 面對客戶 。過去MIS人員僅要面對自家公司的人員，自己人好說話，軟體有bug也可以互相容忍一下; 或者是習慣性的接受同公司的任何修改請求。現在必須全新的體認開發者與客戶之間的商業關係，制度化的客服與變更流程顯得更重要。 在產品方面，或可從下面幾點來看： 產品的獨立性 。MIS 所開發的產品通常並不完全，而是搭配其他購入的產品共同存在（所以MIS人員的職責有一部份就在於整合自家產品與商業產品）。顧客要的是一整套的解決方案，而不會單一的產品，所以你得與商業產品搭配一起販售，這時候利潤的計算與分配、甚至於是合作模式都需要好好的計畫。 企業機密 。MIS所開發的產品多半伴隨著企業邏輯，應該要考慮企業機密的問題。如果企業的弱點或漏洞隨著產品一起出去，讓競爭者有機可乘，便倒賠了一把。 產品的品質 。 為了配合公司的業務流程，MIS所開發的系統多半是修修改改的，架構、功能、實作方法都相當複雜，若要當成產品來賣，恐怕得好好整理一下。 在管理方面應該考慮 產品或專案 。MIS主管可能會有這樣的誤解：A公司與我們業務相同，我們可以將我們的產品直接或微幅修改後賣給他們。在這樣的狀況下，產品的價格會壓的很低。殊不知每個公司都有自己的文化、作業流程，軟體系統移植後一定需要很多的修改，成本一定不會太低。也就是說，主管所認為可以大量直接販售的產品其實是一個誤解，應以專案的方式進行。所以專案管理的能力得重新訓練才行。 組織調整。 需不需要將開發團隊由原有的MIS部門切割出來？切割的好處是MIS可以專心的服務原有公司，不需要為業務煩心。但原有系統的設計是分散在所有員工的腦袋中，要做清楚的切割的確有困難度。如果沒有切割開來，就得避免MIS員工在服務與客戶之中迷失，不能因為重服務而失了客戶，也不能因為...