本篇文章係投稿於 CNet / ZDNet Taiwan 的初稿，主要是探討開發者及管理者在軟體開發過程中，對專案時程與進度的過度樂觀現象的解決之道。不過，在投稿之後，因應在網路上也興起對專案收尾巴的討論熱潮，同人因此在網誌發表了一篇〈當軟體專案計劃趕不上變化時〉。
那篇文章提到期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但很多人卻無法從這些寶貴的經驗中得到教訓。同人在那篇文章提到一個觀念，就是不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計很難會有足夠的空間來容納新功能。因此，最好還是採取務實的做法，針對變化而適時修正計劃，不要樂觀而天真的以為收尾巴就可以解決問題。
在那篇文章的迴響中，志威兄與可樂魔也分享了他們的經驗。志威兄提到了，專案的控管真的是一門藝術，需要累積許多豐富的經驗。每次專案的歷史重演，真的會讓人抓狂。可樂魔則提到，他看到他們公司的眾家 PM 們，他們的心態還是希望在這最後的階段可以「修復所有問題」，但真的有價值的「記取錯誤經驗」和「再利用經驗」都像是狗屁一樣。
對於他們的分享，本篇文章正巧提出同人因應相同問題的實務做法。我認為如果那篇文章指出了對待樂觀主義的心態問題，那麼本篇文章所討論的則是如何處理軟體專案樂觀主義的問題。本篇文章在 CNet / ZDNet Taiwan 分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。 Read the rest of this entry »
喲哪桑提出為了軟體維護的二種設計策略，在設計的彈性策略方面，提到了我的〈專案成本估算之軟體價格的迷思〉某種程度上也說明了為何開發者難以達到彈性這個理想。既然學長提到了，我也好藉這個機會表達我在這方面的看法與經驗。
《易經．繫辭傳》有言：「天下事一致而百慮，殊途而同歸」。在不同產業中，設計所呈現出的面貎也許不盡相同，但是其策略本質卻是不會輕易改變的，亦即為未來可能發生的變動提供適應變化的能力。然而，開發者想要讓軟體具備足夠的彈性，以符合未來可能會面臨的需求改變，抽象化思考與設計能力會是關鍵因素，加上專案成本估算之軟體價格的迷思所形成的動態模型，當我們愈想要加入有彈性在我們的軟體設計上時，就更難以面對市場的競爭壓力，於是只好放棄設計彈性的理想。記得我和吳宗成教授曾經討論過國內軟體設計的議題，依照吳教授的觀察，他告訴我：＂台灣的軟體開發者大部分都在做 concrete design 而非 concept design，有用的設計是 concept design 而非 concrete design＂。由此可知，在台灣軟體開發環境不重視設計的情勢下，大部分的人多抱持著：今天先把功能寫出來，明天再求最佳化往往是軟體專案以時間換取空間的常見做法；我並不反對這種看法，但設計者必須培養持續改善的專注力，好的設計其實源自於紀律。
設計真的沒辦法堅持彈性的理想嗎？如果我們願意換一種思維方式，是不是就可以堅持理想，試圖打破軟體價格的迷思。於是，我們換一種做法，不以降低軟體開發成本為目標，而是藉由邊際效益的提昇來展現設計的附加價值，強調高品質的軟體設計及好的軟體來自於軟體工程的想法，不再自廢武功落入削價競爭瘀惡性循環中。換句話說，當我們體認到軟體維護的重要性時，就必須為未來可能的改變而設計，以保有系統修改及維護的彈性。那要如何做呢？我們可以學習別人良好的設計範例，先從臨摩就座開始，慢慢提昇我們的設計能力。於是，我們向 design patterns 取經，學習如何為不確定來設計、體會務虛的設計藝術。
然而，design pattern 的學習看似簡單，但學了之後，要真正用在軟體開發上，卻又不是那麼一回事。看得懂是一回事，要實際去用卻是另外一回事：為什麼那些大師可以「化腐朽為神奇」，運用 design pattern 使設計變得更有彈性，而我們常把能用的 pattern 都用上了，不但沒讓設計變簡單，反而讓設計變得相當繁複，要了解它都很困難了，更不用說實作與維護了。〈由招熟漸悟懂勁〉告訴我們設計招式與心法搭配的其中奧妙所在：
設計技巧如何，因人而異，面對相同問題，每個人可能會有不一樣的設計手法，程式寫得愈多，對設計愈有不同的體會，如果你對程式如何解決問題沒有深切的體認，很難設計出彈性及功能兼具的系統。所以以個人的心得來說，業務流程、演算邏輯及程式語言的技巧是招式的運用，而內化的領域知識、OOAD 的分析設計原則、封裝、抽象化乃至於 Pattern 的運用則是心法的展現。這兩者互相反覆搭配、增長。
運用 design pattern 雖然是增加設計彈性的利器，但為了維護這些設計彈性，卻必須付出開發成本，當我們的設計充斥了「沒有用的彈性」時，就會浪費許多無謂的時間與資源，而不會再有足夠時間回應軟體需求的變化，及足夠的空間來容納真正需要的功能。以經濟學的角度而言，設計者須重視設計的機會成本，要為現實需求而設計，避免想太多而造成軟體設計的過度工程化的後遺症，而在設計上充斥著沒有必要的複雜度。以物件導向設計原則而言，抽象性愈高的套件，穩定度就要愈低，否則它就會沒有什麼用處，穩定度愈高的元件，抽象性就要愈低，否則它就會很難被重複使用[]。總之，要設計彈性與功能兼具的系統，其實最關鍵的是務實與務虛兩種設計策略能夠相互達到均衡，以達成設計與實作觀點的兩分之形，如下棋般，讓不同觀點皆能發展出最佳的著手。
Read the rest of this entry »
附註：
喲哪桑的「摩托車日記」清楚地道出藉由問對問題來找出適當的度量方法，在讚嘆學長的罕譬而喻之餘，也想到了同人當年度蜜月遊蘇州的一段經歷，剛好可以來說明「專案」的度量，來看看和學長的摩托車日記有何不同？
Read the rest of this entry »
章子怡為軟體度量代言告訴我們軟體度量的 Gilb’s law，任何事物，只要它需要度量就會有方法可以量，只不過我們需要在度量成本與準確度做取捨。不過，最近在閱讀 Berkun 所寫的《專案管理之美學》時，書中對專案經理處於「流程與目標的混淆」現象的提醒也很值得讓我們注意：
有些處在這種情況下的 PM，會訴諸於量化一些不需要量化的事物。由於不確定該做什麼，或者害怕去做最需要做的事，他們會以次要事情占據時間。當 PM 與專案之間隔閡變大時，把注意力放在不必要的圖表、資料表、查核清單、以及報告的情形就會增加。PM 在某一時刻開始相信資料流程就是專案，這是有可能的。他們把焦點擺在不重要而容易做的事情上（試算表或報告），而不是重要而難做的事情上（程式設計成果或進度）。他們也許會自欺說，如果照著特定程序執行，然後把查核清單上的事做好，專案就可以保證成功（或者比較嘲諷地說，任何會發生的失敗，技術上都不是他們的錯）。
Read the rest of this entry »
之前我都會把我在網誌的文章轉貼在台科大 94EMBA 班網，其中〈有關「Stakeholder Management」的後續討論〉這篇文章林序學長回應：
木金兄果然厲害,拜讀所談,獲益斐淺. 小弟補充一點如下:
最新的 CMMI v1.2 版裡已將籌獲流程獨立出來，成為 CMMI-ACQ，即Acqusition 採購流程管理。與原來的開發流程 CMMI-DEV、以及新的CMMI-SVC 服務流程，合成所謂的互補薈集 (Three Complementary Constellations)。
CMMI-DEV 對於資訊系統/軟體開發流程提供了管理、度量及監控的指引，CMMI-ACQ 促使委外籌獲單位居於清楚認知及決策領導的地位。CMMI-SVC的重點則在於提供組織內部及外部客戶服務的參考模式。
看起來 CMMI 的標準，也在朝向提昇 StakeHolder 的參與在努力。
外包單位不可以自外於整個專案，CMMI-ACQ 與 CMMI-DEV 的流程互相對應，共同面對整個專案的成敗。
誠如學長所言，外包單位不可自外於整個專案，外包管理做不好，輕者績效不彰，重者損兵折將，其影響 stakeholder management 甚鉅，不可輕忽。
附記：上週六才發現，林序學長和喲哪桑學長早就認識，人際網絡真是四處連結的網路呀！
