2013年3月29日

第14章-照樣造句的寫作技巧



煉金師:綜合大成的能力

    天才的第三種創意方程式是煉金師,或是連結的原理。煉金師將兩種不同的領域合而為一--不同的興趣、學科或思維系統,以獨特的方式將它們連結已發展出一種突破。它的三管齊下是:

    1. 煉金師採借構想。
    2. 煉金師廣泛的興趣激發他們的構想。
    3. 煉金師藉著連結發掘獨到見解。

    您可以將意想不到的事物合而為一,藉此發現獨到的構想--石破天驚的構想。您可以做連結,感受您所看到的周遭及您的工作之間的相似處。向煉金師學習。尋找相關處。

節錄自《天才的五種創意方程式》

我在寫作時,其實經常使用「煉金師的創意方程式」,借用非IT技術書籍內的詞句和想法,然後進行融合、變形、改造和提煉,經常會得出很不錯詞句和構想。最近終於有空讀完了《天才的五種創意方程式》這本擺在書櫃上很久很久的舊書,發現自己慣用的寫作技巧恰好可以歸為其中的一種創意方程式呢!

***

照樣造句的寫作技巧
小時候,多數人在小學時代國語課堂上,都學過的「照樣造句」技巧,這就是一種最簡單好用的煉金手法了。《天才的五種創意方程式》這本書剛好還在手邊,我隨意翻了翻,看到了下列的內容,覺得挺不錯,正好可以用來示範給您看看我是怎麼照樣造句的。

觀察者:明察秋毫的能力

    以下是觀察者的職場主要原則之摘要

    1. 解放您的好奇心:鍥而不捨地追根究柢。
    2. 注意耳語:聆聽可能成為趨勢指標的周遭構想。
    3. 將各個細節點連結在一起:留意細微的影響並尋找主題。
    4. 鑑賞您工作中的美:在您的職場中追求美感、關懷、親切。

節錄自《天才的五種創意方程式》

上面那段內容,其實讓我聯想到,系統分析師是不是也應該具備著觀察者明察秋毫的能力呢?所以,我就試著把上述的內容做一些照樣造句、詞語替換之類的融合、變形、改造和提煉,如下:

觀察者(系統分析師):明察秋毫的能力

    以下是觀察者的職場主要原則之摘要(系統分析師必須培養的重要能力)

    1. 解放(系統分析師)的好奇心:鍥而不捨地追根究柢。
    2. 注意耳語:聆聽可能成為趨勢指標(系統需求)的周遭構想。
    3. 將各個細節點連結在一起:留意細微的影響並尋找主題()
    4. 鑑賞您工作中(領域概念?UML模型?軟體系統?)的美:在您的職場中(領域概念?UML模型?軟體系統?)追求美感關懷親切()

您看,就這麼簡單替換一下語詞,是不是一下子就得到一個很不錯的內容及看法了。而且,同時間也可以引發我們再度思考一些概念。比方說,針對第4項,可以讓我們有機會再一次反思,到底系統分析師應該鑑賞的,是領域概念、UML模型、還是軟體系統之美呢?
如果,我們思考過後,認為系統分析師應該懂得鑑賞的是軟體系統的話,那應該追求的軟體系統之美又是什麼呢?會不會是軟體系統的和諧、彈性和穩定呢?

系統分析師:明察秋毫的能力

    以下是系統分析師必須培養的重要能力

    1. 解放系統分析師的好奇心:鍥而不捨地追根究柢。
    2. 注意耳語:聆聽可能成為系統需求的周遭構想。
    3. 將各個細節點連結在一起:留意細微的影響並尋找主題()
    4. 鑑賞您工作中(領域概念?UML模型?軟體系統?)的美:在您的職場中(領域概念?UML模型?軟體系統?)追求美感關懷親切(和諧、彈性、穩定?)

經過幾次的煉金之後,就得到了下面的內容,至於第3項可能要再多花一些時間思考提煉,我們就不繼續往下示範了。對了,這邊要特別提醒IT人員的是,千萬別這樣直接改完就公開發表了,在正式公開使用這些文字內容前,一定要再用自己的風格和語氣整個改寫過才行。

系統分析師:明察秋毫的能力

    以下是系統分析師必須培養的重要能力

    1. 解放系統分析師的好奇心:鍥而不捨地追根究柢。
    2. 注意耳語:聆聽可能成為系統需求的周遭構想。
    3. 將各個細節點連結在一起:留意細微的影響並尋找主題()
    4. 鑑賞軟體系統的美:在軟體系統追求和諧、彈性、穩定

UML囈語
這個照樣造句的煉金手法非常簡單,是吧!之前我寫的一堆關於UML感想短句-UML囈語,其中有很多句子其實也是這樣邊看書邊留心一些不錯的句子,隨時拿來照樣造句一下,最後就得到這些可以深思、像哲理般有意思的詞句了。

UML囈語


  1. UML是輔助,不是限制。
  2. 腦海中的想像,永遠比UML的表達,來得重要。
  3. UML的表達是拋磚引玉,別眷戀眼前的圖,因為更佳的設計將破圖而生。
  4. 製圖期間的三不政策:不管UML語法是否正確、不管自己的觀點是否合理、不管專家說些什麼,一切等畫完圖再說。
  5. 充分且完整地表達所思,然後反思,即使不合乎UML語法也絕不罷休。
  6. 創意通常在超越UML語法而現身,但是為了讓眾人分享,事後還是得勉為其難地用UML來表達。
  7. UML像練雙節棍,耍的好,可以唬人;耍不好,會K得自己滿頭包。
  8. UML圖示少用一點,你就可以看到更多。
  9. 六祖慧能以手指月;UML是指,不是月啊!
  10. 如果UML不去重視本身過於繁雜的難題,UML很快就會成為難題的一部分,或者現在就已經是如此了。
  11. 對於我們無緣參與的專案而言,唯一的替代品就是UML圖與原始程式碼。
  12. 發現自己陷在UML圖坑裡時,千萬不要再往下掘洞。
  13. 陷溺於過多的UML圖示中,恐怕會一事無成,並且對結果感到失望。
  14. 多少次我們興高采烈地買了UML書回去,翻開之後才發現,艱深抽象的文字毫無樂趣又令人挫折。
  15. UML的妥善組織力,能使複雜的系統顯得比較簡單。
  16. 為了解釋複雜、理解複雜、處理複雜,學習UML,就有絕對的必要。
  17. 採用UML必然有風險和成本,但遠低於不採用所帶來的長程風險和成本。
  18. 以可預測性來替代變動性,可以讓UML從小卒變英雄。
  19. 趕快畫出下一張圖,用來麻醉腦袋。畫出下一張圖時,其實並沒有真的改變任何事。不過,當注意力轉向可視見的圖形時,已經增加了正面的能量和動力。
  20. 製圖只有兩個問題:一、知道自己在想什麼,但不知道如何表達;二、根本不知道自己在想什麼。
  21. 開始動手製圖,體內的某一部分就會不由自主地想著:「我沒有全部的資料。」此時,我們就會感覺好像遺漏了什麼,但又不確定是什麼,所以就名正言順的停擺了。
  22. 把畫不下去的圖找出來,什麼也不修,全部砍了,這種感覺很不錯。面對令你腦殘的方法之一是,勇敢刪除。
  23. 在我畫了什麼之前,怎麼會知道自己在想什麼?
  24. 如果沒有工具把圖畫下來,甚至可以感覺到腦袋根本不想深思。
  25. 有思考UML更清明的時刻,也有根本不該思考UML的時候。
  26. 頭腦並不擅長記憶、提醒等工作,UML能夠擺脫這些「低階」任務,讓我們專注於思考。
  27. UML要用的好,必須學會見樹又見林,且了解其中之關聯。
  28. 得出好圖的方法是,先畫出一堆圖。
  29. 有太多人愛畫圖而不愛改圖,這樣就等於放棄了吸收更多新思想和可能性的機會。
  30. 不要求去學太多的UML圖示,因為學到時往往已經過時了。
  31. 繪製UML圖時,先要知道自己在找尋什麼,然後再去找尋它。
  32. 建構UML模式不光是設計的藝術,不光是說服別人認同就夠了,而是創造出一種讓參與者想說出自己想法的情境。
  33. 達到效率,卻抹殺了創意,不要以效率來衡量建構UML模式期間的所有活動。
  34. 決定UML價值如何,是需求的假象,而非UML實際的價值。
  35. 當我們能從UML圖中的錯誤之處學習,錯誤才有價值可言。
  36. UML圖可以在一開始創造出讓我們的觀眾(使用者、夥伴、上司、顧客)了解我們,與我們建立理性溝通及達成共識的方式。
  37. UML圖比一連串的事實或資料更能在觀眾心中停留更久。
  38. UML專業技能上非常精通,既是優勢也是弱點。
  39. 對許多UML圖示,你只需要知道一點點就足夠了。
  40. 繪製UML圖不是在產出結論,而是一個收集資訊和創意的過程。
  41. 阻礙我們繪圖的障礙很少是由於缺乏技術性資訊,更多的是由於缺乏自信與勇氣。
  42. 透過UML圖打開自己的心扉,而不是封閉自己的頭腦。
  43. 學會讓UML圖跟隨你的思想,而不是讓思想跟著你的UML圖。
  44. 捍衛UML圖的表像是沒有意義的,應該捍衛的是你的構想。
  45. UML雖然是讓我們能做很多事情的工具,卻也可能使我們失去很多能力。
  46. 簡化UML圖是減少明顯的,增加有意義的。
  47. 面對複雜的UML圖示,只能簡單的選用。
  48. UML可以讓人跟人之間的溝通更明確、更聚焦,但是不可能取代人跟人之間的溝通。
  49. 不能帶來價值的UML元素,不值得花時間和成本去用它。
  50. 用得好,UML就像能夠改善體質的維他命;用不好,UML可能變成只會帶來熱量的垃圾食物。


練習照樣造句
請您再看到下面的內容,一樣是在《天才的五種創意方程式》隨意翻到的內容,直覺也可以改成「系統分析師與團隊」,留給您練習練習,看看能煉出什麼有創意的內容來。

觀察者與團隊

    觀察者是團隊中的「創意良知」。他們的構想很完備,因為那是完全以職場的實際問題為基礎--真正的資訊、真正的客戶、真正的當務之急。他們以這些議題為基礎提出有發展潛力的解決方案。觀察者在職場能成功,因為他們是對周圍工作很敏感的觀察者,而且能做出獨特的貢獻。您會發現觀察者專注於研究、工程、策略與規劃、分析,及營運功能。
    觀察者的好奇心激發了團隊的新構想。他們的好奇心激勵團隊進步;他們的問題經常會引導團隊前進。他們概念式的思考技巧成為指標。觀察者有獨到而重要的構想與團隊分享,團隊也會發現它們有前瞻性的貢獻極為珍貴。

節錄自《天才的五種創意方程式》

引發思考
IT人員要特別注意的是,不要只是透過照樣造句的煉金手法來產出隻字片語,更有價值的是,這樣的跨界連結可以引發我們思考更多。
再舉一個例子,一開始我之所以寫下這一段內容,是因為我正在自己的部落格(UML Blog)上鍵入《我沒時間討厭你-香奈兒的孤傲與顛世》這本書的書摘,剛好鍵入了-「廉價只能從高價而生,為了讓廉價時裝店生存,就必須先有昂貴時裝的存在。」這一段話。

有關時尚或注定消逝的新發明

    我常聽人說成衣扼殺了時尚。時尚需要被扼殺,它生來就注定如此。
    廉價只能從高價而生,為了讓廉價時裝店生存,就必須先有昂貴時裝的存在。數量並非多重的質量,兩者本質上截然不同。如果大家能夠了解、體會、接受了這一點,巴黎就有救了。

節錄自《我沒時間討厭你-香奈兒的孤傲與顛世》

剛好昨天跟一個專門開發APP的新創立小公司創辦人談話,他們劈頭就說:「我知道貴公司是通過CMMI認證的公司,非常重視文件的產出,可是我們團隊擅長寫程式,不擅長寫文件,所以。我們團隊採用敏捷開發。」
在我對昨天的那段談話還記憶猶新之際,恰巧又遇到鍵入上述那段書摘,所以就在電光火石的瞬間,腦袋自己就將兩者做了連結,如下:

廉價(XPScrum這類熱門的敏捷開發)只能從高價(昔日CMMIRUP這類繁雜的開發流程)而生,為了讓廉價時裝店(敏捷開發)生存,就必須先有昂貴時裝(CMMIRUP)的存在。

腦海中直覺地做了這樣連結之後,我便開始檢視並反思自己這個一閃而過的念頭。然後,進一步思索,擁抱敏捷開發是否得拿CMMI當槍靶,以便能夠藉此大聲宣示不喜歡寫文件、不想要遵循繁雜的流程。而我自己的看法又如何呢?文件真的會扼殺軟體嗎?文件真的沒有存在的價值嗎?這其中可有迷思?
以上這些問題,當然不是此時我想要討論的重點,我只是在要示範並提醒IT人員,煉金手法不只可以煉出好詞句、好構想,也能夠提煉自己的思維,而且後者其實價值更高呢!

***

煉金師的技巧非常簡單實用,您有沒有很心動啊!最後,請容許我在引用另一本《學習要像加勒比海盜》一書說的話,IT人員千萬別只讀IT技術領域的書,而是要往別的領域的書籍中去找尋詞句和想法來煉金。

你不該只讀電腦軟體的書,到別的領域找解決我們問題的方法。

節錄自《學習要像加勒比海盜》

2013年3月28日

第13章-連接詞表達邏輯關係


如果,要我列出IT人員產出的文章或文件中,最嚴重的寫作問題的話,「文句之間缺乏連接詞」大概可以列入前三名。老實說,我有非常多的機會看到IT人員產出的文章或文件;在IT人員的文章內容中,其文句、段落之間缺乏連接詞的狀況,真的是非常嚴重。

***

連接詞可以讓文句通順
我常看到IT人員的文章句子,落落長,既不善用標點符號、分段,也不重視句子之間的連接詞,有點類似下面的兩段文字。

    使用案例圖及敘述、類別圖與循序圖三者之搭配幾乎是UML專案的基本型,在分工或外包的設計文檔中通常少不了這三款UML圖。常見的開發程序是並行建構使用案例圖文與類別圖,才建構循序圖以及按圖編碼。一個系統只有一個內部結構,系統對外提供的所有的服務,依賴這個穩定的內部結構支撐。每一項服務的運作方式皆不同,系統有一個靜態結構,很多個動態行為。
    透過UML圖來呈現系統的狀況時,一個系統僅有一張呈現系統內部結構的類別圖,使用案例圖中有多少個使用案例。每一個使用案例至少對應一張循序圖,呈現出系統執行使用案例期間,其內部的一群物件互動的運作情況。類別圖通常不是一次就能夠設計完全,透過一個又一個的使用案例,一張又一張的循序圖,三者經過多次循環更新的歷程後,類別圖才逐步成形且穩定下來。

        您要是認真讀一讀上述的範例,會不會覺得,好像有點不容易理解。但是,倘若我們把上述的兩段文字,一句一句條列出來、分開來看的話,其實每個句子又都能看得懂,如下:

  1. 使用案例圖及敘述、類別圖與循序圖三者之搭配幾乎是UML專案的基本型,在分工或外包的設計文檔中通常少不了這三款UML圖。
  2. 常見的開發程序是並行建構使用案例圖文與類別圖,才建構循序圖以及按圖編碼。
  3. 一個系統只有一個內部結構,系統對外提供的所有的服務,依賴這個穩定的內部結構支撐。
  4. 每一項服務的運作方式皆不同,系統有一個靜態結構,很多個動態行為。
  5. 透過UML圖來呈現系統的狀況時,一個系統僅有一張呈現系統內部結構的類別圖,使用案例圖中有多少個使用案例。
  6. 每一個使用案例至少對應一張循序圖,呈現出系統執行使用案例期間,其內部的一群物件互動的運作情況。
  7. 類別圖通常不是一次就能夠設計完全,透過一個又一個的使用案例,一張又一張的循序圖,三者經過多次循環更新的歷程後,類別圖才逐步成形且穩定下來。

所以,上述的兩段文字到底出了什麼問題?或許,看不太懂的最主要的原因:只是因為句子之間少了連接詞,所以難以理解句子之間的邏輯關係。因此,上面的七個句子形成一種缺乏邏輯關係的句子堆,讀者則必須費神地在腦海中,補上句子之間的邏輯關係。
接著,請您看到下列的範例,我還原了上述兩段文字的原始內容,補上了文句之間的連接詞,而且適度地多分了兩個段落,這樣一來,是不是很容易就能看懂了!

簡易的開發程序

    實務上,使用案例圖及敘述、類別圖與循序圖三者之搭配,幾乎是UML專案的基本型,所以在分工或外包的設計文檔中,通常少不了這三款UML圖。常見的開發程序是,並行建構使用案例圖文與類別圖,接著才建構循序圖以及按圖編碼。
    一個系統只有一個內部結構,而且系統對外提供的所有的服務,都僅依賴這個穩定的內部結構支撐。然而,每一項服務的運作方式皆不同,所以雖然系統有一個靜態結構,可是卻有很多個動態行為。
    因此,透過UML圖來呈現系統的狀況時,一個系統僅有一張呈現系統內部結構的類別圖,而且無論使用案例圖中有多少個使用案例。但是,每一個使用案例至少對應一張循序圖,呈現出系統執行使用案例期間,其內部的一群物件互動的運作情況。
    再者,類別圖通常不是一次就能夠設計完全,而是透過一個又一個的使用案例,以及一張又一張的循序圖,三者經過多次循環更新的歷程後,類別圖才逐步成形且穩定下來。

節錄自《寫給C++程式設計師的UML實務手冊》

前面,我們大致理解了,缺乏連接詞會讓文書不通順。接下來,我們就來看看,有哪些常見的連接詞可以使用吧!

常見的連接詞有哪些?
        首先,我們先來看看「維基百科」對於連接詞的說明,如下:

連詞(連接詞)

連詞又稱連接詞,是用來連接詞語、短語、句子、段落等的詞,表示被連接的語言單位之間的關係。連詞在句子中表逹不同的邏緝關係。連接詞和詞組的連詞,跟連接句子的連詞並不相同。

  • 表示並列關係的連詞:和、跟、與、既、及、而等。
  • 表示選擇關係的連詞:或、或者、還是等。
  • 表示轉折關係的連詞:但是、不過、雖然、然而等。
  • 表示因果關係的連詞:因為、因此、所以、由於等。
  • 表示遞進關係的連詞:不但、不僅、而且、何況、並、且等。
  • 表示條件關係的連詞:不管、只要、除非等。
  • 表示假設關係的連詞:如果、即使、假若等。
  • 表示目的關係的連詞:以、以便、以免、為了等。
  • 表示承接關係的連詞:便、於是、然後等。

來源為「維基百科」(http://zh.wikipedia.org/wiki/連詞)

在維基百科上,把連接詞分為:並列、選擇、轉折、因果、遞進、條件、假設、目的、承接關係,這九大類。不過,這九大類並不是固定不變的分類,只是為了方便我們理解並使用而已。譬如,《麥肯錫寫作技術與邏輯思考》一書的作者,就提出了自己的分類,如表13-1所示。

13-1:高杉邏輯連接詞表

其實,我自己也有慣用的連接詞,不過沒有特別去分類它們就是了。也就是說,如果您的文章或文件中,如果正好缺乏連接詞的話,您就可從上述的連接詞中,挑選一些自己喜歡的連接詞來練習用用看,保證您的文章會立即令人耳目一新喔!

記得順一下文句
當一個段落的文章內容完成後,一定要順一下文句,調整一下連接詞。最常見的情況是,習慣使用某幾個連接詞,所以接連用了好幾個相同的連接詞,這時可以善用同類型的連接詞來進行替換。
舉例來說,在下面的範例中,就連續使用了兩個「如果」。現在,就請您動手調整一下內容,會讓這段文句閱讀起來,可以更加通順且易於理解吧!

其實,角色名稱可以用來標示出物件是以什麼樣的角色參與這個結合關係的,不過如果兩類別之間只有一個結合關係時,通常就不會特別為兩角色命名。但是,如果考慮到實作狀況的話,當然也可以特別為角色命名,方便程序員按圖施工,或者方便軟體工具自動產碼。

節錄自Visual Studio 2010/UML黃金準則

如果,現在就讓我動手來修訂內容的話,我很可能會調整一下連接詞,然後再補上幾個標點符號,讓句子短一點,會更容易理解。修訂如下:

其實,角色名稱可以用來標示出物件是以什麼樣的角色,來參與這個結合關係的,不過如果類別之間有一個結合關係時,通常我們不會特別為兩角色命名。但是不過如果若是考慮到實作狀況的話,當然也可以特別為角色命名。如此一來,方便就可以讓程序員按圖施工,或者方便軟體工具依照角色名稱,自動產碼。

其實,角色名稱可以用來標示出,物件是以什麼樣的角色,來參與這個結合關係。如果,兩個類別之間,只存有一個結合關係時,通常我們不會特別為兩角色命名。不過,若是考慮到實作狀況的話,當然也可以特別為角色命名。如此一來,就可以讓程序員按圖施工,或者方便軟體工具依照角色名稱,自動產碼。

練習一下
俗話說的好:孰能生巧。所以,最後就讓我再留一個練習題給您,讓您有機會多多練習。這是我在報紙上看到的一篇校園反毒的報導,我把報導中的連接詞和分段刪掉了,留給您練習加上連接詞和分段,如下:

毒品在校園氾濫,讓不少學生受害,中小學老師普遍不認識毒品,在發現時,也未能及時導正,增加教師的毒品知能,教育部已辦理教師辨識毒品、增進反毒知能,能在發現狀況不對時,馬上進行輔導。民國100年度各級學校查獲1,810件藥物濫用,其中有1,548件是使用K他命、FM2、一粒眠等三級毒品。教育部表示,曾發生學生上課公然磨K他命,老師看到以為是調皮玩粉筆灰,也不知是毒品。以第一線接觸學生的導師最受重視,總計辦了6,500多場研習會,超過24萬人參與,希望可以協助導師辨別毒品。教育部軍訓處表示,校園反毒不只是師長的工作,家長也要加入,一同關懷孩子,避免誤入歧途。

對了,我把原本的新聞報導內容,放到本章的最後面,待您做完上述的練習之後,可以翻到最後參照一下原文。不過,這只是個練習,沒有標準答案,無須跟原文一模一樣。

***

    因為曖昧的句子很好用。寫作者根本不用思考整個訊息的脈絡,只需要排列句子就一路寫下去,真是太方便了。反正都在講同一件事、同一個產品,相關的句子總是接得下去,而且乍看之下還似乎有脈絡可循。
    對於寫作者來說,沒有比這樣寫文章更輕鬆的事了,所以忍不住就會這樣做。其實,當我疲累的時候,也會不知不覺過多使用前後意義不明確的曖昧語句,但是讀者可就慘了。

節錄自《麥肯錫寫作技術與邏輯思考》

到底為什麼「文句之間會缺乏連接詞」?是中文不容易表達連接詞,還是從小的作文課沒教過或沒學好,亦或是東方的思維和表達模式就是這樣,我實在是沒有深究。不過,我自己在生活上,倒是會特別糾正我女兒的口語表達。譬如,我女兒說:「媽麻,我肚子有點餓。」我就會說:「所以呢?」接著,我女兒就會回答說:「所以,我想要到樓下去找找看,有沒有什麼東西可以吃。」
所以,或許您也可以從此時此刻開始注意,自己在口語表達上或文字表達上,是否遺漏了連接詞,把它們撿回來吧!

校園反毒  24萬師學辨毒品

    由於毒品在校園氾濫,讓不少學生受害,不過中小學老師普遍不認識毒品,以至於在發現時,也未能及時導正,為了增加教師的毒品知能,教育部已辦理教師辨識毒品、增進反毒知能,能在發現狀況不對時,馬上進行輔導。
    根據統計,民國100年度各級學校查獲1,810件藥物濫用,其中有1,548件是使用K他命、FM2、一粒眠等三級毒品。
    教育部表示,曾發生學生上課公然磨K他命,老師看到以為是調皮玩粉筆灰,也不知是毒品。因此,將以第一線接觸學生的導師最受重視,總計辦了6,500多場研習會,超過24萬人參與,希望可以協助導師辨別毒品。
    教育部軍訓處表示,校園反毒不只是師長的工作,家長也要加入,一同關懷孩子,才能避免誤入歧途。

節錄自《大紀元時報》20121214