有些事情，現在不做！永遠都不會做了～～（單車環島日記）

獨孤木　　2006/06/12

話說正當獨孤木正在努力為了打造船隻，開始進行各項外包作業之際。鄭和則是為了解決出訪海外時會面臨到的語言問題，成立了語言學校。他從世界各地找來精通番語的老師，並且派遣宮中的太監與有志成為通譯的人才到學校裡面學習。

這一天，御膳房太監小桂子匆匆忙忙地跑來跟鄭和哭訴。

小桂子：鄭公公，嗚…那個英文老師Tommy Chen他欺負我們宮裡面的人。

鄭和：你先不要哭。告訴我到底發生什麼事。

小桂子：公公，您看他今天要我們寫的功課，這張英文練習卷。

只見小桂子掏出一張英文考卷，上面有一題類似克漏字的測驗題(cloze test)：

我的寶貝 my p________s

鄭和一看，寶貝，不就是自小就被淨身割下來的東西嗎？這些番話我不懂，你說答案是什麼？

小桂子：當然就是penis。指的就是我們身上的寶貝。那壺不開他提那壺。出這種題目，這…這分明就是在糟蹋人嘛。

鄭和一聽之下，果然言之有理，於是勃然大怒，即刻召來Tommy Chen：你幹得什麼好事？我要你教洋文，讓我們出訪番邦時，可以宣揚國威，結果你教得這是什麼東西？

Tommy Chen即刻跪伏在地，連忙請問事情原委。當他明白事情經過後，連忙說：啟稟公公，冤枉呀。小的這個題目是從世界奇幻文學經典名著《魔戒》中找來的呀。正確答案是my precious呀。你只要看電影魔戒第二集第三集就知道小的所言不虛了。還望公公明察呀。

X　X　X　X　X　X　X　X　X　X　

在文字獄盛行的年代，一個考題出得不對，馬上就會招來殺身之禍。暫且不論Tommy Chen的下場如何，當你原本想要傳達的訊息，沒有辦法正確地被解讀時，這就形成了一項溝通上的問題。

軟體開發牽涉到相當多概念的交換，因此怎麼樣可以讓溝通更為精確有效，就一直是很重要的課題。有很多問題，背後都隱含著一個不夠精確的溝通。例如：

開發團隊：你剛剛講的不在scope裡面，這個應該算是enhancement。

客戶：這本來就在scope裡面。你們做的東西不是我們想要的。

開發團隊：哪裡有寫？

客戶：本來就是，你可以翻合約書出來看。

開發團隊：那這個算是你們的requirement產生了改變。

客戶：我們的requirement一點都沒變，是你們從來沒有聽懂過。

開發團隊：我不知道，這個需求以前從來都沒有提到過。

客戶：我以為這是基本常識。我們那有可能講到這麼細？

當我們進一步去探究，為什麼會有這麼多溝通的問題？我想第一個原因是導因於文字的不夠精確。

不夠精確的文字

雖然軟體工程的進步很快，可是當你承包到一個專案時，什麼才是你開發系統的基準呢？什麼又是專案的合理範圍呢？是採用UML所畫出來的model嗎？是採用結構化系統分析的方法所設計出來的model嗎？

事實上，只有你們所簽訂的合約，裡面白紙黑字所寫下來的東西，才是唯一法律上算數的東西。問題是，這裡面的東西能夠精確地描寫出系統的面向嗎？那就牽涉到這份文件是要給誰看的了。

當客戶跟你產生糾紛的時候，這份文件會交給誰看？嗯…律師與法官。那他們有可能看得懂你們想要開發的系統到底包含些什麼範圍嗎？在簽約的時候會有一份清楚的分析設計文件嗎？

當你問了這些問題之後，毋庸置疑地，大多數的專案，關於整個系統的範圍(scope)，其實都是很含糊而不夠精確的說明。即使是一份看起來很完整的工作說 明書，裡面通常還是沒有辦法精確地界定完整的系統範圍。因為這份文件，是給法務、雙方的專案經理人、律師跟法官來看的。而除了專案經理之外，其他的人都看 不懂太深奧的東西。一旦雙方有了歧見，那就大家走走調解委員會，或是法院見。

使用文字來描寫系統要是有辦法描寫得十分精確，那開發系統就不需要再做什麼塑模(modeling)的動作了。

作者為資深工程師及軟體開發專案經理，經常撰寫軟體專案的文章，作品散見於資訊論壇網站及其個人部落格中，著有《軟體超人X光眼：專案開發揭弊大爆料》一書。