上個月 24 日應 MaoYang 兄之邀，分享我在敏捷開發的實戰經驗。這場分享會還找來了 David Ko 兄分享他在公司導入 scrum 開發管理方法的經驗，同人則負責分享我之前在專案中推行 extreme programming 工程實務的經驗。分享會在台北市電腦公會舉行，看到現場互動氣氛的熱絡，以及會後學員們給予不少正面的評價，感覺大家收穫都不少。其實包括我自己在分享會結束之後也產生了一些想法，倒是想藉由此文章分享我的分享會後心得。
同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。
但為什麼人們要盲目地做些行不通的事呢？ Read the rest of this entry »
台北捷運木柵內湖線又發生系統異常。同人昨天晚上搭捷運，我一向習慣坐第一節車箱。列車才自中山國中站離站沒多久，就看到前面不遠處有一台列車停在那裡，隨車人員連忙打開控制箱將列車停止。等前面列車駛離之後，才將列車停靠至松山機場站，並請大家下車。然後，在廣播中播放因為系統異常而導致全線停駛的訊息，並且請大家改搭其它交通工具。
到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。 Read the rest of this entry »
本周一同人在新公司 on board，公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜，讓大家開啟談論品質流程的話題。 Read the rest of this entry »
最近同人看到有一則噗浪提到「一個穩定的程式並非必然，而是偶然」在此噗浪的回應中，發送這則噗浪的噗友表達他對程式穩定性的看法。
先問自己一個問題，一個程式有幾個 Bugs？如果是不可數，那～～它的穩定是相對非絕對，所以穩定不是絕對的，也不是必然的。
同人覺得這位噗友的觀點很有趣，於是加入這則噗浪的討論。我問如果最開始的程式都是穩定的，那麼是什麼原因讓後來的程式變得不穩定？對這個問題，一些噗友提出了他們的看法，其中有一位噗友回應「是我的機器弄好的程式，跑到別人機器就不穩定了」，發送此則噗浪的噗友認為還蠻接近實際的情形。
他提到 Bugs 在自己的機器沒產生，在別人那邊可能會產生，問題可能是因為自己的機器有 Bugs，而不是別人的機器，他說假設機器不會出問題是會有副作用的。
那麼為什麼不在應用系統要運作的目標環境下直接開發程式呢？因為，嚴格來說，開發者不可能有完全一致的環境，因此開發者只能假設環境是不會改變。但實際上，在不同的機器上、甚至在相同的機器上，不同的時間可能也會出現難以預料到的變化，結果使得程式變得不穩定。
這位噗友認為，當我們愈信任一個系統，其實可能是一個災難，因此程式的穩定非絕對而是偶然，它是由一連串的偶然所累積而成的。同人發現這個觀點讓人很難反駁，在我過去程式開發的經驗中，並不乏遇到原來運作正常的程式，在不同時空環境出現問題的現象。正如同這位噗友提到的，作業系統與程式語言它們本身也都是程式，很難確保它們不會出問題。
相信很多人都曾遇到過，程式發生失常通常只因為一個令人難以捉摸的小錯誤，因此似乎真的可以說「穩定的程式是偶然的」。不過，如果穩定的程式真的是偶然的，程式的穩定就只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。 Read the rest of this entry »
本篇文章是投稿 ZDNet 的文章原稿，並以〈專案不確定導致焦慮與迷失〉與〈專案不確定性導致焦慮與迷失(下)〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化，變化總是比不上老闆的一句話」之時，許多專案經理總是會擔心專案無法如期完成或害怕資源不足，而拒絕或延後專案變更的要求。但這樣的行為，卻往往造成工作成果無法符合專案實際需要的結構性因素，而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言，當然並不會樂見專案發生這樣的事情。
筆者前一陣子看到喲哪桑在〈換了屁股，我也換了腦袋〉的分享，提到他在時間緊迫的情形下，接受了專案的功能變更要求。那個變更要求原來是由他所提出，當時前任專案經理以時程緊迫為由而答應延後處理，而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生，於是決定不要再讓這個專案變更要求再次拖延下去，並在當下對專案進行變更。
筆者認為喲哪桑的作為令人激賞，並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定，而是欣賞他在決策過程中，展現出面對自己的勇氣與解決問題的思考。不過，卻有其他讀者對那篇文章抱持相反的意見。
某位網友對喲哪桑的分享，批評他是靠感情衝動來管理專案，甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念，實在有不可思議的謬誤，並且擔心那篇文章會透過 ZDNet 的報導，將不正確的知識與觀念誤導一般社會大眾。
然而，他對這篇文章的批評卻使人感到困惑，那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤，但看在專業人士眼裡，這樣的觀點又何嘗不是相當嚴重的偏頗呢？筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感，進而對改變的抗拒而產生無知的迷惘。
身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中，但在對專案缺乏可供客觀評論資訊的情況下，只憑專案經理接受專案變更的決定，就加以批判其決策感情衝動是否真的恰當？專案管理並不是神學或是玄學，而是屬於管理科學的範疇。因此，如果有人要批評某個專案經理是用感情衝動來管理專案，必須提出具體的事實根據，否則那只是無憑無據的推論而已，而這樣的推論多半只是源自於自我的偏見與扭曲。 Read the rest of this entry »
本文係投稿於 CNet / ZDNet Taiwan 的初稿，並分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。
軟體專案開發常常會面臨時間不足的問題，尤其在台灣，Price on Cost更是不容易達到的理想，迫於現實，開發者只能硬著頭皮上陣去執行不可能的任務。但最後的結果卻常常是賠了夫人又折兵。即使透過不斷地加班，任務依舊還是無法完成，而且還會造成團隊士氣低彌，使得開發者缺乏工作的成就感與滿意度，甚至使專案開發人力大量流失。
其實大多的軟體開發者都期望專案能爭取到足夠的開發時間，不希望他們的青春浪費在無意義且永無休止的加班上。然而，軟體開發的現實就是如此殘酷，受到開發組織的營運面影響，通常專案總是很難爭取到足夠而充裕的開發時間。專案常會受限於市場競爭壓力的考量，為了爭取專案的機會常常會不得不遷就營運觀點而放棄工程與技術的堅持，因而使得專案無法爭取到合理的開發時間。
在台灣，軟體的定價通常是由市場供需機制所決定的，而不見得可以考量到軟體開發的成本。當市場競爭愈激烈時，軟體的價格就相對地會降低。開發者為了獲利，於是就必須想辦法降低開發成本，才能獲取相當的利潤，於是軟體的品質就會受到影響，因為軟體價格實在太低了，開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的一個理想，而現實通常是「時間總是不夠」。
當軟體專案把軟體價格當做專案成本估算的基礎時，這樣軟體開發就會沒辦法重視專業，只能讓外行（市場因素）領導內行（研發設計專業），軟體開發者的痛苦夢魘於是從此開始。
所以，Price on Cost 的理想是很難達到的，現實就是這樣，專案就是難以爭取到足夠的充裕時間。但這樣要如何才能達到專案不可能的任務呢？從筆者在工作上的觀察中發現，不少的管理者會將這個問題焦點放在團隊生產力上，以提昇軟體的開發效率來縮短開發時間。不過，實際上卻不見軟體開發成果獲得到顯著地提昇。
通常，管理者會希望軟體開發者加班或是增派開發人力，來提昇軟體開發的生產力。軟體開發每日的總工時增加了，照理說應該是可以增加軟體開發的效率，但卻也因此引發出新的問題，也就是軟體開發出錯的機率也會隨每日工作時數或開發人力增加而增加，反而降低了軟體開發的效能。
為什麼會這樣呢？綜歸一句話，增加了生產力卻讓軟體開發變得更複雜，使得團隊無法有效整合、發揮綜效。 Read the rest of this entry »
軟體專案後期的變更會讓團隊無法按照既定計劃進行，然而因應現實需求變更又勢在必行時，我們又該如何取捨呢？學長喲哪桑在〈Late Changes Can Be Good〉提出我們必須認清專案初期的需求規格永遠是不完整的事實，因此好的經理面對專案後期變更應該要懂得取捨，發展出良好的適應變更的機制。他提到：
大家都不喜歡 Late Changes，我也不例外。不過，也不要有受害者的心態，把 Change 當做誰的疏失、誰的錯誤、是誰害的。我們還是得認清事實，就是專案初始時的需求規格永遠是不完整的。
好的機制，是要讓產品專案能夠快速應變，而同時間又能把品質的傷害、生產力的影響降到最低。
好的 manager，要懂得取捨。Late Changes Can Be Good.
學長所提的觀念其實並不難理解，但依據同人實務上的觀察卻發現，在面對壓力時，專案管理者往往無法做適當的取捨。理想上，大家都會以為加一點東西、做一點小改變，程式應該不會有什麼問題才對。但事實往往是「千金難買早知道，萬般無奈想不到」，改變對軟體品質的傷害、生產力的影響總是超乎我們的想像，更可怕的是變更所造成的災難似乎永無止盡。當初取捨時的樂觀，事後我們才會發現那其實是無知。 Read the rest of this entry »
本篇文章係投稿於 CNet / ZDNet Taiwan 的初稿，主要是探討開發者及管理者在軟體開發過程中，對專案時程與進度的過度樂觀現象的解決之道。不過，在投稿之後，因應在網路上也興起對專案收尾巴的討論熱潮，同人因此在網誌發表了一篇〈當軟體專案計劃趕不上變化時〉。
那篇文章提到期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但很多人卻無法從這些寶貴的經驗中得到教訓。同人在那篇文章提到一個觀念，就是不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計很難會有足夠的空間來容納新功能。因此，最好還是採取務實的做法，針對變化而適時修正計劃，不要樂觀而天真的以為收尾巴就可以解決問題。
在那篇文章的迴響中，志威兄與可樂魔也分享了他們的經驗。志威兄提到了，專案的控管真的是一門藝術，需要累積許多豐富的經驗。每次專案的歷史重演，真的會讓人抓狂。可樂魔則提到，他看到他們公司的眾家 PM 們，他們的心態還是希望在這最後的階段可以「修復所有問題」，但真的有價值的「記取錯誤經驗」和「再利用經驗」都像是狗屁一樣。
對於他們的分享，本篇文章正巧提出同人因應相同問題的實務做法。我認為如果那篇文章指出了對待樂觀主義的心態問題，那麼本篇文章所討論的則是如何處理軟體專案樂觀主義的問題。本篇文章在 CNet / ZDNet Taiwan 分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。 Read the rest of this entry »
軟體專案在「收尾巴」之前，很多專案的利害關係人都會很樂觀地認為，軟體的問題可以在收尾巴的過程中得到修正。然而，當大家發現專案後期因為需求變更與軟體本身所存在的缺陷產生複雜的交互作用，使得軟體問題不斷地發散，才會發現，收尾巴？！這應該還沒開始吧！
對此，志威兄提到，從程式設計者、網站委外服務之業主、專案管理者之間，存在了觀點的差異。而他指出，讓專案順利及圓滿完成的解決方案就是找到一個稱職、有能力的專案經理。志威兄認為良好的專案經理除了具備相當的領域知識與時程控管能力外，最重要的就是溝通協調能力，他提到了：
他必須將老闆時長過於遠大的夢想，找到執行與實做的方法，更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員，通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程，並且設定適當的check point，隨時掌控進度與各部門狀況。
事先做好規劃，按照時程追踪進度無疑是確保專案成功的基本動作，相信大家都能了解這個道理。但事實上，在軟體專案的開發過程中，要完全做到卻又發現窒礙難行，因為軟體開發本身存在著抽象性與變動性，要事前就規劃好整個專案的時程，恐怕只是個無法實現的理想。
然而，雖然「計劃趕不上變化，變化比不上老闆一句話」，但趕不上或比不上並不代表要放棄計劃，否則專案的成功也只是聽天由命的偶然罷了。同人認為，軟體專案要成功，關鍵不在於如何照計劃進行，而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說，當軟體專案管理者把計劃當成死的名詞時，他將不會成為稱職的專案管理者；稱職的專案管理者會把計劃當動詞，用以採取適當行動，才會讓專案走向成功。 Read the rest of this entry »
本文係投稿於 CNet / ZDNet Taiwan 的初稿，並分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。
在日常生活上，我們常會發現從不同觀點中體會出一致性的道理，如同專案管理與易經，我們可以從專案管理的觀念與方法中，常會發現它們與易經的觀念是相通的。尤其在軟體開發團隊中，不管是在問題的解決上或對團隊成員的管理上，都與易經有不謀而合的地方。
其實專案所談的不外乎談人與事，而軟體與其它類型的專案並沒有特殊的差異。因此，我們可以普遍性地說，表面上專案管理與易經看起來各自呈現出不同的風貎，但本質上它們的背後其實存在著共通的一致性的道理。
為什麼會有這種巧合呢？易經所探討的是事物變化的道理，而專案本身就是企業在面臨環境變化的挑戰所應運而生的一種概念。在變化無常的環境中，變是唯一不變的真理，正因為如此，企業要因應環境的十倍速變化，端賴於在專案管理過程中，了解變化的道理來達成專案使命，以滿足企業的實際需求。
所以專案管理和易經的哲理自然是會相通的。換句話說，專案管理雖然是基於專案需要，依照西方的管理理論所發展出來管理概念與方法，但它必然會符合易經的基本原理。
所以，對於專案管理者而言，如果能善用易經哲理，可讓他們在重要概念上具備理解掌握變化原則的能力，同時培養在管理上以簡御繁的技巧。易經的觀念並不複雜，雖然它是探討事物變化的道理，但事物變化的本質是簡易的，是可以被掌握的，事物會遵循著不變的自然法則而改變，而非沒有章法的改變。這就是所謂的易之三義－變易、簡易與不易的道理。 Read the rest of this entry »
