夏日炎炎正好遊

回頭看了一下前一篇 Post 的日期......哇，足足偷懶了三個月！原因是美國東北部的夏季不比台灣，天氣不錯，是出遊的好時機，尤其是在歷經大半個凍人的冬天之後。夏天一到，大家都便趕緊排滿週末行程，深怕短短三個月一下就溜走了。

底下貼幾張我到 Yosemite 國家公園美景，讓大家欣賞一下。







請到這裡繼續 (http://www.jason-photos.com)......

說了半天，只是幫自己找找 Blog 空白的藉口，該動動筆了......

YouTube.com

最近看 Wired 雜誌才發現，在網路上 Post 照片和文章已經是老掉牙的事了，Podcast 也不再稀奇。目前最 Hot 的應當屬 YouTube.com 了，Post 你的影片。

Wired 雜誌特別介紹有名的『Back Dorm Boys』，到底下的 Links 瞧瞧。

• I want it that way
• Radio in my head
• Chinese opera
• Irresistible love (Chinese song)

另外又找到兩個有趣的影片，也貼出來瞧瞧。

• Mac 廣告 (This is what happens when you put an Intel in a Mac XD)
• 爆笑 "Muscle" Boy

突然發現我正在做『老掉牙』的事......

眾人皆醒我獨醉？

公司企業文化裡，上司和下屬的關係總是很微妙，一不小心對峙的情勢便會形成。立場畢竟不同，即使沒有糟糕到成為恨之入骨的敵人，也別想成為心意契合的朋友。就好比蛇與老鼠，最好別碰到面。照此說法，下屬們的立場相近，彼此之間應該容易同舟共濟，一齊抵禦外侮。遇到有些需要理直氣壯處境，大伙兒一鼻孔出氣，義正辭嚴的指點亂象，聽似理所當然。

然而，事實總是與理想相距遙遠。

有一次開會的時候，忍不住向強權發表了一些 『公理正義』。原本以為能夠得到 『同船人』 的支持，未料，話一收口，四周悄然。頓時覺得荒野之中，就見一隻孤零無助的小老鼠，等待被大莽蛇生吞活剝的慘狀。果不其然，落得一句：「怎麼大家都沒問題，就你一個有問題？」

不論是個性使然或是環境影響，現實總會驅使人低頭。能依靠的，只有少數的革命者精神。不過壯烈犧牲的義士和名垂千古的英豪，往往只是一線之隔。

革命不成，只有看上位的人怎麼見微知著了。

明君所見到的會是：「眾人皆醉你獨醒！」

昏君所見到的卻是：「眾人皆醒你獨醉？」

醒或醉呢？就當這篇醉話連篇吧。

銀彈迷思

自從20世紀電腦研究和發明以來，科技持續進步，人們的生活方式因此而完全改觀， 『Information』 成了所謂的『新經濟』。專家學者將其稱之為資訊革命 （Information Revolution），是繼農業與工業革命之後的第三次革命。資訊革命當中變化最大的，莫過於 『數位產品（Digital Products）』 的誕生 —— 一種異於 『實體』 觀念的產品 —— 也就是我們所說的 『Software』 ，『軟體』 或 『軟件』。

對於這種新型態的產品，或許是因為仍在襁褓之年，我們始終無法像控制 『實體』 產品般，有效率的掌握其完成日期（Due Date）與良率（Quality）。當然，眾多的專家學者提出各種學說與方法，想要改善這種問題，而且更進一步提升生產力。不過 Fred Brooks 在 1986 提出了一篇 『No Silver Bullet』 的文章，吹皺眾專家學者們的一池春水，但也一語中的，點醒他們偏離實際的大夢。

雖說如此，銀彈（Silver Bullet）迷思一直存活在大頭們的心中，彷彿是種能夠醫治百病的 『靈丹聖藥』。

※ ※ ※ ※ ※ ※ ※ ※

果園管理系統的開發，已經進入膏肓期...呃...後期階段。全公司總動員的情況下，古專員當然也不能例外的捲進產品修補大事。然而在眾人焦頭爛額的 『救火』 過程中，古專員發現了不少離奇古怪的系統需求 （Requirements） 與資料庫設計 （Database Design）。秉持著 『爛，但不可以更爛』 的心態下，古專員不得已向大頭提出了這些弊端，看看能不能藉機挽回一些劣勢，不過換來的是另一場中高級幹部的『高峰』會議。

會議室裏，大頭一號再度語重心長的說道：「看到古專員的 Email 才瞭解到，我們這套果園管理系統有不少弊病。白課長，你說說看這是怎麼一回事？」

白課長裝出一副受盡委屈的小媳婦兒臉孔：「偶們的 Resources 有些不足，加上前一陣子又有同冷（同仁）離職，才會這樣......」

每次看到白課長這副模樣，古專員便氣從中來：「照你這種不審核 Requirements 的作法，再加幾百個人也永遠不會足夠的！還有你們資料庫每天都在改，叫 Developers 怎麼做啊！」

為了避免沒完的爭執，大頭一號中斷兩人的對話，一副胸有成竹的向大家說道：「關於這些問題，我已經有解決的方法了。」

全場鴉雀無聲，摒息以待。

「軟體界龍頭 Macrosoft 公司剛剛發行一套幫助軟體開發管理的系統 —— Crew System 。系統內含數百種，依照產品開發時期分類的樣版文件，我們只要照著做，問題應該都可以解決。此外，這套系統還提供和開發環境整合的工具庫，可以更進一步提升程式 （Programs） 開發效率；它更提供工作項目追蹤和測試工具，確保我們能夠順利完成所有項目，消除所有的 Bugs ，更進一步提高產品的品質......」說話同時，大頭一號嘴角泛起淺淺的微笑，彷彿這套 Crew System 是上天賜與的仙丹妙藥，一切產品開發的問題與阻撓將灰飛湮滅。

古專員試著把大頭一號從夢境拉回現實，說著：「我瞭解 『工欲善其事，必先利其器』 ，我想這套系統絕對能夠改善我們開發產品的一些窘境，不過問題的根源還是時間與人啊。數百種文件格式，我們不知道有沒有那麼多資源與能力一一照著做。而且，像是 Engineer Side 人員和 Customers 溝通的技巧，或是不經過濾審核，就把 Requirements 丟給 Developers 去做，可能結果還是一樣的啊......」

大頭一號彷彿沈浸在服用仙丹妙藥後，如入雲端的美夢中，一副百思不解望向古專員說道：「總而言之，這套系統必定可以解決你所說的所有問題。說不定，系統中有一份 『顧客面談技巧』 的密笈啊！」

說完，駕著雲朵向南天門飛去，留下古專員這個凡夫俗子傻楞楞的站在那兒。

※ ※ ※ ※ ※ ※ ※ ※

如果細讀 Fred Brooks 的文章，會瞭解他的 『沒有銀彈』 指的是沒有簡單的方法可以讓軟體工程 （Software Engineering） 的生產力在十年內提高十倍。他的論點是必要與次要複雜度 （Accidental Complexity and Essential Complexity） 的差異。程式語言 （Programming Language） 這類由人們所創造出來的工具，屬於次要複雜度，可以隨時間進步被改良。然而必要複雜度，像是軟體本身要解決的問題，則無法移除。如果軟體需要提供30種功能 （或所謂的 Features），那麼這30種功能都是必要的，程式就必須做出這30種功能。

在我看來，除了產品的 Features 之外， 『人』 本身的複雜度也是必要的，正所謂 『成也蕭何，敗也蕭何』 。不論多麼好的方法或是工具，問題總是在 『人』 身上。

到底這世上有沒有萬靈丹呢？只在神話故事裡吧！

寧吃過頭飯，莫說過頭話

從小被教導，做人說話要謹言慎行，辭嚴義正，巧言令色鮮矣仁。

一直以來，認為循規蹈矩也沒什麼不對，所以許多話出口之前，總是內心反覆三思，不敢輕易允許自己不明白或是無法達成的承諾。話一出口，也都據實以告，深怕食言而肥。

所以當許多人向我提出問題或要求的時候，他們所得到的第一個回答，通常不見得是『正面的』答覆；換句話說，不是他們『心中想要』的答案。雖然後來經 過仔細、再三、反覆、推敲之後，終於允諾他們心中所謂的『正面』回答，然而覆水難收，就像濫情偶像劇女主角常掛在嘴邊的一句話，『再說什麼也沒用，傷害已 經造成』。

也因為如此，常落得一個『你這人很難溝通』的惡名，真是有冤難伸，御狀難告！

於是，漸漸體會到自古忠言多逆耳的真義。即使大家都常掛在嘴邊：「我要你老實告訴我。」但心裡想聽的其實是順耳之言，忠不忠你看著辦。

「話該如何說呢？」根據經驗，大約歸類如下四種回應。

第一種，『實話實說』。

所謂巧言令色鮮矣仁，不少人秉持五千年傳承的儒家中心思想，絕不說欺天瞞上的假話。不過就如同孔子周遊列國，卻得不到各國諸王的青睞一樣，是要付出代價的。

如果一不小心說了實話，心理就隨時要有被懸賞通緝、推出午門斬首的戒慎恐懼。如果運氣好點兒落個全屍，也免不了被眾人立一個『遺臭萬年』的牌坊，萬年遺臭。趕緊回家閉門思過去吧！

第二種，『實話不說』。

最簡單達成『實話不說』的方法就是『不干己事不張口，一問搖頭三不知』。不過這種隱瞞實情的應對方式顯得有些不夠『用心』；況且頭搖久了，也要小心扭傷脖子。

真正深入此道的人，需要瞭解『旋乾轉坤』的精髓，其奧妙之處在於，不能說謊的情況下不說實話，隱瞞實情的同時，又要能夠不說謊話。因為不說實話並不同於說謊話，不說謊話的同時也可以不說實話......（沒看懂得人請回頭再讀一次。）

第三種，『睜眼瞎說』；亦或是大家耳熟能詳，那個該死的『放羊的小孩』。

說謊是需要一點兒技巧的，尤其要小心『事發』和『事後』兩種風險。

『事後』的風險很明顯，當然是指謊言被拆穿，大人們提槍前來卻不見野狼的慘狀。不過這容易些，打死不承認就好了；或是說大野狼『剛剛好』跑掉了。即使某些情況下，很難打死不承認，你也可以說：「我當時不是那個意思。」意思是很難對證的。

『事發』的風險嚴重些，和當事人對話的當口可得小心翼翼，現行犯被抓，總是難逃其究。雖然你也可以學放羊的小孩耍賤說：「哈哈，我騙你的！」

第四種是這些類別中最高深莫測的：『漫天胡說』。

老實說，自己無法體會此等道的真諦，只能從門外漢的角度略微窺探，給一些分析：

『胡說』並不相同於 『說謊』。『說謊』代表你知道事情的真相，但卻說出與事實相反地結論；而『胡說』卻是沒有事實根據，昧地瞞天的信口亂語。

胡言亂語自然沒有『事發』的風險，原因是事實不存在。就算『事後』被揭穿，你也可以輕而易舉的說：「我的消息是根據另一個（荒謬詭譎的）事實」。

『漫天胡說』也不算是『實話不說』，因為胡說的人根本不知道實情，何謂隱䐽呢！

此道淵博之處，真所謂仰之彌高，鑽之彌堅；箇中蹊蹺，如人飲水，冷暖自行體會！

人生旅途中，四種人都見過，苦果也都嚐過。

自己一直是第一種『實話實說』的笨人，牌坊大概已經從街頭立到巷尾了。也因此如此，我時常收到一些勸說告誡：「哎，就算你已經知道做不到，也可以先 （不說實話）說試試看，人家喜歡聽這類的話嘛！」雖說我並不堅決排斥此種論調，但這類的勸告總是讓我陷入一種迷思，坦白不欺瞞已不是衡量的最高價值。

『忠言逆耳利於行，良藥苦口利於病』不再適用，『利於行之順耳忠言，利於病之甘甜良藥』才是上上之道。

想想，不想落個遺臭萬年的惡名，也不願意像第三種欺天罔人，更沒有第四種的天生才份......

朝第二種人邁進吧。

魔法帳棚

在軟體開發的生命週期當中，總會有一個時期，是所有人拼命的趕工補足未完成的項目，或者是修補產品漏洞，希望能夠順利趕上截止日。但不知是否因為這種令人焦頭爛額的非常時期，盲目了大家看事情的能力。輕重緩急、優先次要，全都亂成一團。很多情況下，產品的功能 （Features） 和有限的時間（Due Date）就如同魚與熊掌，不可兼得，適當的折衷方案需要被擬定。

大頭們其實很瞭解這類 『需要擬定折衷方案』 的情況，只是很多時候，這些方案有著令人意想不到的 『驚奇』 。

※ ※ ※ ※ ※ ※ ※ ※

會議室裏，大頭一號召集所有 System Side 的中高級幹部共聚一堂，氣氛凝重。

大頭一號語重心長的說道：「各位同仁，眼看果園管理系統的內部截止日就剩兩個星期，產品小組的白課長已經告訴我，我們大約還有幾十個功能（Features）未完成，加上一籮筐的 Bugs ，現在是公司總動員，全力救火的關鍵時刻了！我想聽聽大家有沒有什麼好的方案可以幫助我們度過這個危機？」

靜坐一旁的古專員心裡想著：「兩個星期還有一堆 Features 和 Bugs ？全力救火？別到時候葬身火窟......」想的同時，狠狠瞪了白課長一眼，可惜白課長裝作沒看見。

平時很少說話的溫專員，這時竟率先說道：「眼看時間很緊湊，我建議我們應該先全力修 Bugs ，讓產品穩定下來，同時間，仔細審核未完成的功能，或許有些可以延到下一個版本。」

古專員心想溫專員也受不了了，大聲附和道：「我完全贊成溫專員的意見。我認為 Customers 寧可要一個穩定但功能少一些的系統，而不要一大堆功能卻錯誤百出的系統。另外，幾十個功能一定有些可以刪除或延期，除非截止日可以延...... 」說著微微把頭轉向大頭一號。

大頭一號果決的說道：「為了公司的名譽，我們要堅守截止日期。白課長，那幾十個功能可以延到下一個版本嗎？」

白課長嘟囔說道：「可是有些功能，偶們已經答應 Customers 會給他們了......能不能第一個星期做完所有未完成的功能，第二個星期再全力修 Bugs？」

古專員像是看到了外星人降落地球，一副不可思議地看著白課長：「一個星期全力修 Bugs？你以為是用殺蟲劑修 Bugs嗎？還有，只用一個星期做完的幾十個功能，我看全都會變成第二個星期要修的 Bugs ！」說著火氣又上來了。

溫專員也緩緩搖頭：「白課長，事情不能這樣做！」

大伙兒僵持不下的情況下，大頭一號突然開口：「我看在截止日期不改而且功能不減少的情況下，公司需要買幾頂帳棚，大家做到晚上累了，可以直接在公司露營，醒過來可以繼續......」

還沒等大頭一號把話說完，古專員再度不支倒地。

昏迷之中，古專員似乎看到那幾頂帳棚活動了起來，幫著大家寫程式，修 Bugs，如同到了『哈利波特』中的魔法世界......

※ ※ ※ ※ ※ ※ ※ ※

Joel On Software 在他的 Painless Software Schedules Blog 提過：「計畫 （Schedule） 就像是木塊，截止日 （Due Date） 就像是木箱。當所有的木塊無法裝進木箱的時候，你只有兩種選擇：一種是少裝一些木塊 （減少計畫的項目） ，或者是找更大的木箱 （延期交貨），而不是說『一定有辦法』這類自欺欺人的話。」當然這是金錢和資源有限的前提之下。

想靠幾頂帳棚就可以完成這艱鉅的任務？那必定是充滿神奇力量的魔法帳棚！

肯湊包

對於有多項軟體產品的公司而言，應用程式的開發，除了會分成不同小組專精於不同層面（Layer）的開發之外，為了避免各產品之間重複投入相同的人力，大 都會設立一個核心小組，開發一些公司內部共用的類別庫和架構（Reusable Class Libraries and Framework）供各產品使用，減少開發資源（Resource）的浪費。

正因為如此，核心小組的立場必須中立，只應該把各產品之間的 『共通點』 納入考量，而不應該把各產品特有的屬性歸入類別庫。不過，產品開發小組和核心小組時常會有不同觀點，而有責任區分的討論與紛爭。

※ ※ ※ ※ ※ ※ ※ ※

會議室內，大頭一號召集白課長和古專員共商產品大事。

大頭一號開場說道：「我想大家已經大略讀過果園管理系統的 規格（Specification）了，今天我們要討論一下這套系統設計以及權責區分。我們希望藉由這個系統，順便分析並建立公司內部共用的類別庫和架構，讓所有產品將來可以分享。這些類 別庫和架構一定要夠動態、夠彈性，更要有擴充性與前瞻性，而且也要簡單好用，能讓 Developers 能夠在一兩天內就輕鬆上手。之前已經和大家說明分組上的變動了，白課長將帶領產品開發小組，古專員則負責核心小組的工作，全力支援白課長。好的，開始討論 吧！」說完便靠到會議室角落，開始啜茶。

白課長搶先說道：「偶看果園管理系統裡面有不少的媽九（Module）都蠻有共通性的，應該很多都可以晃路（放入）核心類別庫哦......」

古 專員還正在從大頭一號遙不可及的軟體烏托邦甦醒當中，聽了白課長的建言當場清醒：「呃......白課長，利用這套產品來分析公司內部共用的類別庫和架構 固有其必要性，不過我們要謹慎審核，以免產品的特有邏輯不小心滲入核心類別庫，使得類別庫不夠獨立性。我已經大約分析了一下，這些算是比較通用的控制元件 （Controls）......」一面說一面將手中的說明文件遞出去，「我們可以先 Review 一下是不是有過之或不及。」

白課長才瞄了不到五秒鐘，立刻說道：「怎麼有些媽九都沒提到，『產量昏析』和『人員管理』都可以晃進氣核心類別庫啊！」

古專員有著對牛彈琴的無奈：「有部分『產量分析』的計算和『人員管理』的核心都已經納入核心類別庫，你只需要組合一下，應該就可以得到結果了......」

白課長似懂非懂答道：「喔......那『採收』和『維護』的媽九呢，你有肯湊（Control）浪偶們使用嗎？」

古專員已經有些不耐煩了：「『採收』和『維護』算是產品比較特別的 Modules，雖然共通的部分已經納入核心小組的考量，不過你們還是需要做一些產品專有的 Controls ......」

白課長不等古專員把話說完：「那你有肯湊可以浪偶們很快的做『播種』和『施肥』的媽九嗎？」

古專員的火氣已經上來：「白課長，核心類別庫和架構並不是依照果園系統架構走的，我們只是把共通的部分抽離出來，有些工作還是開發小組要自行設計的！」

白課長以耍賴的口吻回答道：「你就幫幫偶們把肯湊包一包，浪偶們傳參數（Parameters）就可以得到結果嘛......」

古專員終於氣不住說：「你要不要我寫一個慌選（Function）給你，讓你傳進 『專案名』 ，我就幫你把整個專案做好啊？」

白課長拍手說道：「好啊，好啊！」

大頭一號突然開口：「嗯，這是今天 Meeting 最好的提案，就這們辦吧！」

古專員再度暈厥，不支倒地。

※ ※ ※ ※ ※ ※ ※ ※

軟體開發的過程當中，有不少好的想法和建議，總會因為許多『不可抗拒』的因素而無法順利執行，只是這些『不可抗拒』因素是否真的不可抗拒，評斷自在人心了。

知識應該有幫助吧......

Who comes the supper

最近把 Blog 介紹給朋友的時候，發現一個有趣的現象。由於這個朋友比較習慣讀英文，便把我的文章輸入線上的翻譯程式，結果令人捧腹大笑。貼出來讓大家笑笑。

======== 原文 ========

『責 任制』的工作態度，已成為大多數科技公司，或者說是大多數公司，運作的模式。工作時數的延長，已成為日常生活的一部份。如果沒人加班，大頭們似乎會覺得公 司營運一定出了什麼問題， 可能快要見不到明天的太陽了。當然，要人留下來超過吃晚飯的時間，一定要準備些塞嘴的東西，吃人嘴軟嘛！至於超時的補償（加班費）呢......就多吃點 兒吧！（全文網址）

======== 譯文 ========

"Responsibility system" the work manner, has become the majority science and technology company, or said is the majority company, the operation pattern. Work 時數 lengthening, has become the daily life a part. If nobody working overtime, the big end can think as if company transport business certainly had any problem, possibly soon will see tomorrow the sun. Certainly, the important person stays behind surpasses eats the dinner the time, certainly must prepare a plug cock the thing, eats the person to have one's speech softened! Compensates (overtime pay) as for the overtime..... Eats! (By http://www.systranbox.com/)

[P.S. Funny that "塞嘴" becomes "plug cock"......]

======== 譯文轉回原文 ========

「責 任系統」工作方式，適合多數人科學和技術公司，或者說是多數人公司，操作樣式。 工作時數加長，成為了日常生活每part。 如果超時工作的沒人，大端能認為，好像公司運輸事務一定有所有問題，明天很快可能將看星期日。 一定，留下來超過的重要人物吃晚餐時間，必須一定準備塞嘴事，吃人安排一.的講話變柔和! 補償(加班費)作為對超時..... 吃!

＊＊＊＊＊＊＊＊

上面的例子讓我回想起許多彆扭不通的翻譯小說，It all makes sense to me now......

UI 好書

做 Web Applications UI 有一陣子，看了不少好（原文）書。最近在逛 博客來 的時候，發現其中一本自己覺得不錯的書『 Don't make me think 』有了中譯本。不過對於翻譯書總是一則以喜，一則以憂，在它親近另一群讀者的同時，總害怕翻譯失了真。其實有機會的話，讀讀原文書也是不錯的。







另外有一本還沒看見被翻譯的書（或許比較厚），也順便推薦一下：『 The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience 』。做 Application UI 的朋友絕對不能沒有。

誰來晚餐

『責任制』的工作態度，已成為大多數科技公司，或者說是大多數公司，運作的模式。工作時數的延長，已成為日常生活的一部份。如果沒人加班，大頭們似乎會覺 得公司營運一定出了什麼問題， 可能快要見不到明天的太陽了。當然，要人留下來超過吃晚飯的時間，一定要準備些塞嘴的東西，吃人嘴軟嘛！至於超時的補償（加班費）呢......就多吃點 兒吧！

※ ※ ※ ※ ※ ※ ※ ※

在幾人共擠一間的 Office 裏，System Side 的古專員正在收拾公事包，準備向同事們道別，結束忙碌的一天。大頭一號正好『碰巧』地經過辦公室門口。

大頭一號探頭進來：「古專員要走啦？」

古專員楞了一下：「呃......是啊，時間差不多了......」心裡想，反正已經比正常下班時間晚了些，應該沒什麼問題吧。

話才一結束，四周突然變得鴉雀無聲，空氣剎時凝結。時空一轉，彷彿到了美國牛仔拓荒的西部時代，兩位槍手正準備生死對決。

大頭一號眼睛微瞇，不疾不徐：「是嗎？......聽說公司今天買的晚餐不錯哦......」雙手緩緩靠向腰際，手掌輕扶槍柄。

古專員挑了挑眉，面露微笑答道：「哦，公司蠻照顧員工的......」雙手早已神不知鬼不覺搭上腰邊，解開槍套。

「要不要和大家一起吃啊......」大頭一號棋高一著，不見雙臂有絲毫移動之下，雙槍已經出了套。

「多謝好意......」古專員撐著已有些僵硬的笑容，微微點著頭:「下次有機會的......」槍也不落人後，已出了套。

「偶而讓公司『請個客』也不錯啊......」大頭一號的槍管平舉，槍口眼看就要對準古專員的胸口了。

「有啊，上個星期剛剛讓公司請過......」古專員的槍管也已緩緩平舉。

緊張氣氛已升到最高，一陣強風颳過，街邊的稻草球承受不起，疾速從兩人中間滑過。

「就算陪我吃個飯吧！」碰的一聲，火花從大頭一號的槍口亮起....

「我......」古專員趕緊摳動扳機......

畢竟將是老的辣，古專員的子彈只在地上滑過，激起一團塵土。大頭一號的子彈已在古專員的胸口染起一片紅醞......

※ ※ ※ ※ ※ ※ ※ ※

有趣的是，大頭們常常以為員工留下來吃晚飯，就能夠完成更多的事情；而且到了年底 Review ，『有沒有留下吃晚飯』變成了員工努不努力的不成文象徵，真是奇且怪哉！

大頭們可能天天都在煩惱：「今天誰來晚餐？」

電玩原聲帶

為了幫 Blog 灌灌水，在哈拽找到了一篇十年前幫某家遊戲雜誌寫的文章（My...十年光陰......），內容是有關當時遊戲音樂的一些感想，源自於自己曾經幫遊戲業 編寫過一些音樂的感觸， 貼出來分享一下。比起十年前，現今的遊戲音樂製作已與流行音樂不相上下，不過似乎還未有機會佔據唱片行的一個專區，仍有進步空間。

⊙ 電玩原聲帶 ⊙

記 得好一陣子以前，在唱片行晃的時候，看到了一塊與眾不同的音樂CD，便迫不及待地將它收入荷包。或許也有許多人早已將它收入珍藏了，不是別的，正是 The Dig （註：LucasArt 1995 出的冒險遊戲）。

撇開它的銷售量不說（雖然這有點兒令人憂心），忍不住要為這一塊唱片背書，順道為國內「千千萬萬」做電玩遊戲配樂的勞苦工高的戰士們說幾句話。

回憶一下國內的電腦遊戲發展史，感覺上一直是在資訊界的邊緣求生存，關心的人不多，反對的人倒是不少，也無怪乎國產遊戲常會給人一種不夠入流的感覺，不是畫面差了，就是音效缺了；或者遊戲本身就很「難」玩。

不過近幾年來，國產遊戲逐漸有漸入佳境之感，畫面更細膩誘人，遊戲過程也聽到了全程語音，可是音樂似乎還是一直放在被人遺忘的角落……，什麼道理呢？是畫畫的人都喜歡玩電腦遊戲，而寫音樂的人不太碰遊戲？還是學音樂的人覺得遊戲音樂無法入主流呢？

有時候翻了翻廠商們的應徵廣告，缺少的似乎只是美術設計、程式設計、故事腳本，或者是遊戲企畫，還沒見過音樂設計的需求。是國內的遊戲音樂設計已經不缺人才了呢？亦或是一個遊戲的成就比較不需要音樂？

根 據自己的了解，其實國內的遊戲開發廠商大都有滿腹苦水，本身開發經費的拮据，加上泡麵軟體的猖狂，養些程式設計師、企畫和美工就是一筆負擔，而且完成遊戲 的主力也在此；對於遊戲中時常被人關掉的音樂而言，能省則省，找個臨時工作作曲，或是找個外包商再談價錢。最糟的是，有時候乾脆找些現成的曲子湊一湊，節 省一點開銷囉。

遊戲音樂的水準參差不齊其來有自，無「重賞」之下，何來勇夫？這樣講或許現實了點，卻也不失真實。在流行音樂創作如此蓬勃的台灣，不覺得可惜了些？真的要「很」賺錢才能做嗎……

令人感到慶幸的，遊戲音樂也逐漸邁出腳步（可能發現可以賺錢了），一兩支團體逐漸浮出檯面，成為「主流」的供應商，為國產遊戲添加另一抹豔麗。不過在過多的需求下，有限的供給，會不會犧牲了品質？相信不是大家所樂見的。

對曾學過音樂的人來說，看到國內遊戲音樂的進步，心中是雀躍萬分的，更無庸置疑發行唱片。希望越來越多的音樂人投入此道，有朝一日發行國人的第一片「電玩原聲帶」（註：應該有不少了）。

給你三個月，給我全世界

每一個軟體專案的開發， Scope 永遠是一把兩面鋒利的刃，如果使用得當，絕對可以克敵 (Competitors) 致勝、所向披靡，贏得美人 (Customers) 芳心。但若是胡亂出招，到頭來可是會搞的遍體鱗傷體無完膚。

※ ※ ※ ※ ※ ※ ※ ※

在密不通風狹小擁擠的會議室裏。

大 頭一號激動的高呼：「各位同仁，公司剛剛接到從軟體大廠 JBM 手中搶來的 Case，是幫果醬工廠設計一套果園管理系統。這可是公司揚眉吐氣、千載難逢的機會，我們一定要好好的把握。今天這個會議的主要目的，是要決定這套系統的 Scope，各位同仁踴躍發表意見。」

System Side 的古專員首先發難：「既然是管理果園，基本上應以果園為中心，大致上包括『播種』、『施肥』、『採收』、『維護』幾個模組。另外，果醬工廠最關心的莫過於收成，所以或許『產量分析』可以是另一個輔助模組。」

Engineer Side 的胡專員以一副很了解 Customer 的心態補充道：「果園要靠人來運作，是不是也要『人員管理』的模組？」

古專員皺了一下眉頭：「嗯……雖然不是核心，基本的『人員管理』模組倒還無所謂啦……」心裡想著：「你是嫌我不夠忙嗎？」

胡專員繼續說道：「那可能也需要人員打卡系統，追蹤員工的出入席時間，以及工作效率和果園收成的關係。可以加個『Schedule工作效率』模組。」

古專員眉頭皺的更深：「追蹤工作效率本身並不簡單，況且和果園收成分析可以分開管理，我們真的需要 Implement 打卡系統嗎？果園應該是重點……」說的同時，斜眼看了一下大頭們。

大頭二號露出沈思的表情：「應該可以增加賣點，我覺得不錯。」古專員如同胸口挨了一記悶棍。

胡專員得到鼓勵，再接再厲：「既然有了員工的工作效率，我想我們可以加個『Incentive』模組，幫忙他們年終的時候分配績效獎金更方便。」

古專員連忙阻止：「Incentive 怎麼會跟果園扯上關係啊？再說，關於錢的系統，有很多專業上的知識， 以及 Transaction Issues，我們的時間和資源並不是很充裕……」

胡專員側了側頭，給大頭二號一個『古專員很不上道』的眼色。

大頭一號不等古專員把話說完，『語重心長』的說道：「古專員你應該學學胡專員，多為公司想想！」

可憐古專員猶如啞巴吃黃連：「我當然希望公司可以 Deliever 一個穩定實用的產品啊！這麼多 Features，一定為搞出一個大怪獸來的。況且胡專員又不寫 Code……」心理哭訴著，嘴巴一張一闔，彷如離水的金魚，說不出話。

大頭二號最後補一句：「順便一題，Delivery Date 是三個月後……」

古專員當場暈厥，不支倒地。

※ ※ ※ ※ ※ ※ ※ ※

聽來荒唐，卻是現實世界的常客。公司大頭們總是以『給我全世界』的心態看待軟體開發。殊不知，即使最終產品真的有上百樣的 Features，Cutomers 常用的總是其中那十幾樣。許多公司皆因如此，而將開發的金錢與資源浪費在『大小通吃』的心態上。

嗯……『果園管理系統』裡真的需要一個『績效獎金分配』模組嗎？

狗皮膏藥防洪牆

關於公司專案開發，總覺得大頭們無法看清楚世界的轉動，發現不到問題專案的開端，而只是不停的在補救。最後落得的下場，只是個 Beta Quality 的 Final Product。

※ ※ ※ ※ ※ ※ ※ ※

建造防洪牆的工地現場。

大 頭們大聲疾呼：「公司這次（其實是每次）建造的防洪牆，不知怎麼回事，有漏水現象。眼看颱風就要登陸，我們定要竭盡全力，修補到滴水不露！來， System Side 人員每人發一百張狗皮膏藥，開始修補，一定要在颱風登陸前搞定。Engineer Side 人員負責審核 Specification，查看漏洞，如果一百張不夠，就繼續追加，知道嗎？」

Engineer Side 人員手持鐵鎚與鑿子微笑點頭，可憐 System Side 人員已經快被上百張狗皮膏藥壓的喘不過氣來了。

※ ※ ※ ※ ※ ※ ※ ※

問題的解決，永遠不是在最後一刻召集全公司 System Side 人員集體修補上百個漏洞，而是一開始懂得卸下 Engineer Side 人員手中的鐵鎚與鑿子，避免這上百個漏洞的形成。再者，上百張狗皮膏藥補強的防洪牆......不嚇人嘛？

唉，大頭們搞的我們一個頭兩個大！

前言...

雖然自詡是科技人，永遠走在時代尖端，追尋科技的腳步；不過隨著智慧髮的增長，步伐卻緩了下來。Blog 上市好一陣子，才提手打了這篇文。

好的開始，是成功的一半......（希望不要只是一半）