煉金師:綜合大成的能力
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囈語
- UML是輔助,不是限制。
- 腦海中的想像,永遠比UML的表達,來得重要。
- UML的表達是拋磚引玉,別眷戀眼前的圖,因為更佳的設計將破圖而生。
- 製圖期間的三不政策:不管UML語法是否正確、不管自己的觀點是否合理、不管專家說些什麼,一切等畫完圖再說。
- 充分且完整地表達所思,然後反思,即使不合乎UML語法也絕不罷休。
- 創意通常在超越UML語法而現身,但是為了讓眾人分享,事後還是得勉為其難地用UML來表達。
- 學UML像練雙節棍,耍的好,可以唬人;耍不好,會K得自己滿頭包。
- UML圖示少用一點,你就可以看到更多。
- 六祖慧能以手指月;UML是指,不是月啊!
- 如果UML不去重視本身過於繁雜的難題,UML很快就會成為難題的一部分,或者現在就已經是如此了。
- 對於我們無緣參與的專案而言,唯一的替代品就是UML圖與原始程式碼。
- 發現自己陷在UML圖坑裡時,千萬不要再往下掘洞。
- 陷溺於過多的UML圖示中,恐怕會一事無成,並且對結果感到失望。
- 多少次我們興高采烈地買了UML書回去,翻開之後才發現,艱深抽象的文字毫無樂趣又令人挫折。
- UML的妥善組織力,能使複雜的系統顯得比較簡單。
- 為了解釋複雜、理解複雜、處理複雜,學習UML,就有絕對的必要。
- 採用UML必然有風險和成本,但遠低於不採用所帶來的長程風險和成本。
- 以可預測性來替代變動性,可以讓UML從小卒變英雄。
- 趕快畫出下一張圖,用來麻醉腦袋。畫出下一張圖時,其實並沒有真的改變任何事。不過,當注意力轉向可視見的圖形時,已經增加了正面的能量和動力。
- 製圖只有兩個問題:一、知道自己在想什麼,但不知道如何表達;二、根本不知道自己在想什麼。
- 開始動手製圖,體內的某一部分就會不由自主地想著:「我沒有全部的資料。」此時,我們就會感覺好像遺漏了什麼,但又不確定是什麼,所以就名正言順的停擺了。
- 把畫不下去的圖找出來,什麼也不修,全部砍了,這種感覺很不錯。面對令你腦殘的方法之一是,勇敢刪除。
- 在我畫了什麼之前,怎麼會知道自己在想什麼?
- 如果沒有工具把圖畫下來,甚至可以感覺到腦袋根本不想深思。
- 有思考UML更清明的時刻,也有根本不該思考UML的時候。
- 頭腦並不擅長記憶、提醒等工作,UML能夠擺脫這些「低階」任務,讓我們專注於思考。
- UML要用的好,必須學會見樹又見林,且了解其中之關聯。
- 得出好圖的方法是,先畫出一堆圖。
- 有太多人愛畫圖而不愛改圖,這樣就等於放棄了吸收更多新思想和可能性的機會。
- 不要求去學太多的UML圖示,因為學到時往往已經過時了。
- 繪製UML圖時,先要知道自己在找尋什麼,然後再去找尋它。
- 建構UML模式不光是設計的藝術,不光是說服別人認同就夠了,而是創造出一種讓參與者想說出自己想法的情境。
- 達到效率,卻抹殺了創意,不要以效率來衡量建構UML模式期間的所有活動。
- 決定UML價值如何,是需求的假象,而非UML實際的價值。
- 當我們能從UML圖中的錯誤之處學習,錯誤才有價值可言。
- UML圖可以在一開始創造出讓我們的觀眾(使用者、夥伴、上司、顧客)了解我們,與我們建立理性溝通及達成共識的方式。
- UML圖比一連串的事實或資料更能在觀眾心中停留更久。
- 在UML專業技能上非常精通,既是優勢也是弱點。
- 對許多UML圖示,你只需要知道一點點就足夠了。
- 繪製UML圖不是在產出結論,而是一個收集資訊和創意的過程。
- 阻礙我們繪圖的障礙很少是由於缺乏技術性資訊,更多的是由於缺乏自信與勇氣。
- 透過UML圖打開自己的心扉,而不是封閉自己的頭腦。
- 學會讓UML圖跟隨你的思想,而不是讓思想跟著你的UML圖。
- 捍衛UML圖的表像是沒有意義的,應該捍衛的是你的構想。
- UML雖然是讓我們能做很多事情的工具,卻也可能使我們失去很多能力。
- 簡化UML圖是減少明顯的,增加有意義的。
- 面對複雜的UML圖示,只能簡單的選用。
- UML可以讓人跟人之間的溝通更明確、更聚焦,但是不可能取代人跟人之間的溝通。
- 不能帶來價值的UML元素,不值得花時間和成本去用它。
- 用得好,UML就像能夠改善體質的維他命;用不好,UML可能變成只會帶來熱量的垃圾食物。
練習照樣造句
請您再看到下面的內容,一樣是在《天才的五種創意方程式》隨意翻到的內容,直覺也可以改成「系統分析師與團隊」,留給您練習練習,看看能煉出什麼有創意的內容來。
觀察者與團隊
觀察者是團隊中的「創意良知」。他們的構想很完備,因為那是完全以職場的實際問題為基礎--真正的資訊、真正的客戶、真正的當務之急。他們以這些議題為基礎提出有發展潛力的解決方案。觀察者在職場能成功,因為他們是對周圍工作很敏感的觀察者,而且能做出獨特的貢獻。您會發現觀察者專注於研究、工程、策略與規劃、分析,及營運功能。
觀察者的好奇心激發了團隊的新構想。他們的好奇心激勵團隊進步;他們的問題經常會引導團隊前進。他們概念式的思考技巧成為指標。觀察者有獨到而重要的構想與團隊分享,團隊也會發現它們有前瞻性的貢獻極為珍貴。
節錄自《天才的五種創意方程式》
引發思考
IT人員要特別注意的是,不要只是透過照樣造句的煉金手法來產出隻字片語,更有價值的是,這樣的跨界連結可以引發我們思考更多。
再舉一個例子,一開始我之所以寫下這一段內容,是因為我正在自己的部落格(UML Blog)上鍵入《我沒時間討厭你-香奈兒的孤傲與顛世》這本書的書摘,剛好鍵入了-「廉價只能從高價而生,為了讓廉價時裝店生存,就必須先有昂貴時裝的存在。」這一段話。
有關時尚或注定消逝的新發明
我常聽人說成衣扼殺了時尚。時尚需要被扼殺,它生來就注定如此。
廉價只能從高價而生,為了讓廉價時裝店生存,就必須先有昂貴時裝的存在。數量並非多重的質量,兩者本質上截然不同。如果大家能夠了解、體會、接受了這一點,巴黎就有救了。
節錄自《我沒時間討厭你-香奈兒的孤傲與顛世》
剛好昨天跟一個專門開發APP的新創立小公司創辦人談話,他們劈頭就說:「我知道貴公司是通過CMMI認證的公司,非常重視文件的產出,可是我們團隊擅長寫程式,不擅長寫文件,所以…。我們團隊採用敏捷開發…。」
在我對昨天的那段談話還記憶猶新之際,恰巧又遇到鍵入上述那段書摘,所以就在電光火石的瞬間,腦袋自己就將兩者做了連結,如下:
腦海中直覺地做了這樣連結之後,我便開始檢視並反思自己這個一閃而過的念頭。然後,進一步思索,擁抱敏捷開發是否得拿CMMI當槍靶,以便能夠藉此大聲宣示不喜歡寫文件、不想要遵循繁雜的流程。而我自己的看法又如何呢?文件真的會扼殺軟體嗎?文件真的沒有存在的價值嗎?這其中可有迷思?
以上這些問題,當然不是此時我想要討論的重點,我只是在要示範並提醒IT人員,煉金手法不只可以煉出好詞句、好構想,也能夠提煉自己的思維,而且後者其實價值更高呢!
***
煉金師的技巧非常簡單實用,您有沒有很心動啊!最後,請容許我在引用另一本《學習要像加勒比海盜》一書說的話,IT人員千萬別只讀IT技術領域的書,而是要往別的領域的書籍中去找尋詞句和想法來煉金。
你不該只讀電腦軟體的書,到別的領域找解決我們問題的方法。
節錄自《學習要像加勒比海盜》