同人的生活派對

朋友在 MSN 上問我用 vb.net 和 c++ 開發程式有沒有很大的不同，因為她的主管要她加入一個使用 vc++ 開發系統的專案。她很怕接下這個任務會很難上手，但主管告訴他用不同的程式語言，只是工具的差異而已，她只需要依主管給的程式範例照著做就沒有問題。朋友不大相信主管的說法，於是想聽聽我的意見。

同人直覺感到不妥，並非因為朋友並不諳 c/c++ 這種程式語言，加上它與 vb 之間，存在根本的程式語言差異。我認為比較嚴重的問題還是溝通過程出現不精確的語言，這代表她們公司的品質文化，對解決專案的問題是沒有效果的。

學習 c++ 當然並不輕鬆，尤其如果沒有 c 語言基礎的話，學起來更是會格外吃力。因為 c++ 語言特性與 vb 的差異很大。比如 c/c++ 特有的指標，就很容易讓初學者混淆，如果觀念不清楚，常會讓程式產生記憶體衝突甚至是當在不明所以的地方。但程式語言或是程式設計的技術，這些都還可以藉由學習成長，對於積極進取、追求自我成長的開發者而言，這些並非是大問題。

誠如我在 facebook 的好友，也是以前在點空間聚會有一面之緣的仁傑兄，看到我對這件事情的分享，他建議：

If you want to encourage her, you can said that. Let her have a confidence to do it.But you have to keep coaching, monitoring and reviewing her codes.

然而，這件事情我覺得讓人擔心的並不是朋友的能力夠不夠。我注意到的是她們公司的品質文化，品質文化的問題並不在技術，它多半不會是專案成敗的關鍵，而是專案管理者的態度。 Read the rest of this entry »

本周一同人在新公司 on board，公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜，讓大家開啟談論品質流程的話題。 Read the rest of this entry »

在〈開發者的 common sense〉的留言中，同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考，而習慣於用經驗法則來取代思考。然而，誠如 Brooks 所言：「軟體的本質是複雜的，而不是偶然發生的」對治複雜度本來就是開發者的天職，而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來，那些網友的批評著實令人為他們捏一把冷汗呀。

從路邊的垃圾桶與路人的留言，我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論，因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑，如果每個人的 common sense 都不一樣，所以無法一概而論，那這種 common sense 還能叫做 common sense 嗎？

到底他們觀點上邏輯的矛盾，問題是出在那裡呢？同人認為問題並不是開發者的 common sense 不存在，而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說，軟體工程領域本身就是從實務發展出來的理論，其中許多概念就是開發者必須知道的 common sense，對開發者來說是合理的知識，也是他們都知道、無須解釋或加以論證的常識。

由此可知，如果開發者缺乏一般性的通用概念，那他碰到問題就很難舉一反三，自然也就難以掌握重點，而只能依據表相來處理問題，往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應，一開始以自己熟悉的技術來看問題，最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法，更是整個弄錯抽象化思考的意義，結果最後他還是誤解了業務規則的意思。

同人前一篇文章所提到的業務規則，並非來自技術領域上萬用的設計，而是對問題領域經過抽象化思考後，所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考，才會產生嚴重的觀念混淆。事實上，抽象化思考重視的不是技術實作，而是如何從實際問題當中萃取出重要的抽象概念，以增進我們對問題領域的瞭解，才能採用最適當的技術來開發軟體系統。

此外，過份強調技術經驗而輕忽概念性思維的開發者，很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣，責怪同人沒有交待清楚是 XML 格式的問題，直到別人提出質疑才說明與列出參考文獻，認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題，難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎？XML 只是實現交易訊息概念的一種技術，用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。

以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？ Read the rest of this entry »

元旦假期到高雄遊玩，我們搭乘高鐵到高雄，然後以高捷做為連結各個景點的主要交通工具，最後再搭乘台鐵回台北。藉著這次機會，讓同人有了第一次體驗乘坐高捷的經驗，本來對服務人員的悉心解說、與親切的服務態度，讓我對高捷有很好的印象。但可惜在最後，搭高捷到火車站卻因為服務人員的一句話，改變了我對高捷系統的服務評價 Read the rest of this entry »

喲哪桑學長最近寫了一個有趣的故事，並在故事的後面問讀者「Feature Request, Or Bug Fixing?」這個故事引發了許多人進行廣泛的討論。

有人站在專案經理的角度來與故事中的 M 持相同的看法，只要加強 Error handling 改掉 bug 就夠了，不需要再多花工夫來回應 feature reguest。但也有人站在工程師的角度主張支持故事中 Q 的想法，解決問題本來就是 bug fixing，而修改問題所採用的做法只是 work around，而不是故事中 M 所說的這是 feature request。

不過同人覺得這個開放式的案例討論最有趣的部分，倒不是誰的看法才是正確的討論，而是看到 scarfman 「開版圖就已經說明了，bug 穿上衣服就變成 feature 啦！」的回答，這促使同人進一步地思考到一個新觀點；也就是軟體缺陷的信用創造。 Read the rest of this entry »

本篇文章是投稿 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 »

本文係投稿於 CNet / ZDNet Taiwan 的初稿，並分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。

軟體專案團隊在專案開發的過程中，常會面臨許多問題，例如需求的不斷變化、資源的短缺、時間的急迫性、以及技術的難以掌握等。這些事件雖然都將直接影響專案的產出與品質，並且會令開發者會感到相當困擾，但只要存在希望，問題都還是可以有解決之道的。然而，在什麼情況下，專案發生了什麼事會讓開發者完全失去希望，並且感到他的世界相當悲慘呢？

相信許多人都會同意，總要等到專案驗收前，才發現程式品質有問題是一件很令人沮喪的事情。 Read the rest of this entry »

軟體專案在「收尾巴」之前，很多專案的利害關係人都會很樂觀地認為，軟體的問題可以在收尾巴的過程中得到修正。然而，當大家發現專案後期因為需求變更與軟體本身所存在的缺陷產生複雜的交互作用，使得軟體問題不斷地發散，才會發現，收尾巴？！這應該還沒開始吧！

對此，志威兄提到，從程式設計者、網站委外服務之業主、專案管理者之間，存在了觀點的差異。而他指出，讓專案順利及圓滿完成的解決方案就是找到一個稱職、有能力的專案經理。志威兄認為良好的專案經理除了具備相當的領域知識與時程控管能力外，最重要的就是溝通協調能力，他提到了：

他必須將老闆時長過於遠大的夢想，找到執行與實做的方法，更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員，通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程，並且設定適當的check point，隨時掌控進度與各部門狀況。

事先做好規劃，按照時程追踪進度無疑是確保專案成功的基本動作，相信大家都能了解這個道理。但事實上，在軟體專案的開發過程中，要完全做到卻又發現窒礙難行，因為軟體開發本身存在著抽象性與變動性，要事前就規劃好整個專案的時程，恐怕只是個無法實現的理想。

然而，雖然「計劃趕不上變化，變化比不上老闆一句話」，但趕不上或比不上並不代表要放棄計劃，否則專案的成功也只是聽天由命的偶然罷了。同人認為，軟體專案要成功，關鍵不在於如何照計劃進行，而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說，當軟體專案管理者把計劃當成死的名詞時，他將不會成為稱職的專案管理者；稱職的專案管理者會把計劃當動詞，用以採取適當行動，才會讓專案走向成功。 Read the rest of this entry »