銀彈迷思

自從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 最好的提案，就這們辦吧！」

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

※ ※ ※ ※ ※ ※ ※ ※

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

知識應該有幫助吧……

誰來晚餐

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

※ ※ ※ ※ ※ ※ ※ ※

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

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

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

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

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

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

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

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

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

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

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

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

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

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

※ ※ ※ ※ ※ ※ ※ ※

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

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

給你三個月，給我全世界

每一個軟體專案的開發， 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 人員手中的鐵鎚與鑿子，避免這上百個漏洞的形成。再者，上百張狗皮膏藥補強的防洪牆……不嚇人嘛？

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