不一樣的小黨契機

前幾天，到建國花市，剛好遇到綠黨候選人的宣傳腳踏車隊。這位候選人提出的口號：「藍綠都缺乏反省的決心與勇氣，選民應該用選票來表達不平...」。剛好也是前幾天，苗栗的立委補選，國民黨選輸了，與論一片告急與反省聲。如果真的就此懂得反省，對人民總也是好事。前天，沉默了兩天的苗栗縣長跳出來說話，說都是馬政府高失業率害的...(當初他不是還想蓋馬奮館??)
一般而言，大型的選舉，小黨難有立足空間。尤其是在奇妙的國會減半之後，小黨與無黨參選幾乎是不可能的任務。不過，也許，這次的補選，說不定會有奇蹟出現!!?? 真的很希望有奇蹟出現，給那兩個爛蘋果一些些教訓。真的不希望，每次選舉，非得只能想辦法從中挑個比較不爛而已...

為什麼要離開資策會?

為什麼要離開? 這個問題想過不知多少次!
今天看了棒球經典賽-台灣VS.中國
我們又輸了，心情真是超超沉悶
不過，在比賽剛開始時，我就先留了一篇文章，預測一下結果
文章在此：2009WBC-預留的文章
之所以留下這篇預測，是因為意外(也不算意外)發現，自己離職的原因跟台灣輸球的原因...是"類似"的哦!!

哪裏類似呢!?
「以人為本」VS.「共體時艱」
也就是，「以處理每個個人的問題為優先」VS.「以處理組織面對的困境為優先」

事實上，在 PMP 的課程裏，也曾討論過關於「衝突管理」在東西方文化與觀念上的差異! 這裏並不是說，「以處理每個個人的問題為優先」就是對的，「以處理組織面對的困境為優先」就是錯的。這兩種不同的觀念各有其時代背景，也各有其優缺點。問題只在於，當前是個什麼樣的社會什麼樣的環境；這世界在變，變到哪了? 人的觀念在變，變成什麼了? 問問看，現今台灣社會，還有沒有哪一位家長，會用「以國家興亡為已任，置個人死生於度外」來教育自己的小孩呢!!?? (這句話絕對不代表"愛國心"不重要，絕對不是這樣)。然後，我們的問題還不只是"習慣性"的使用「以處理組織面對的困境為優先」的觀念來執行管理事務，更糟的是，全然缺乏"共體時艱"執行之後的 "Lesson Learn"...

我們的棒球呢，很像哦!! 去年北京奧運第一次輸給了中國(京奧棒球-台灣首次輸中國)；然後中職問題不斷：米迪亞收手、中信鯨解散；在危機亦是轉機的呼聲中，又剛好不少旅外球員回注，剛好正是一個改革的好時機；卻在「共體時艱」的大旗下，出現了"特別選秀會"這種超有趣的小怪物。(在這裏，偷偷說一下：「"倪福德"，支持你，你沒有對不起任何人，是有人對不起你...曹錦輝，加油，不過，想衝撞體制，就要有倒在沙灘上的決心」)

這幾天還有幾個有趣的新聞：
1.撞球王子轉籍新加坡。為這件事，撞協還取消了他參加"廣州表演賽"一事...(吳爸爸，我支持你)
2.ESPN停播SBL賽事。SBL說ESPN"忽視"商業道德；不過，有位網友說的好，哪有人合約沒簽就要人家先播?? (不好意思，以前真的是這樣，我的前公司也是如此，合約還沒簽就先寫程式!!)。話說回來，只有59位觀眾的賽事，有多少賺頭呢!!??

民進黨的情形也很像呢! "團結"成了唯一重要的事。在「共體時艱」的感昭下，一切會引發衝突的意見都被...smoothing or withdrawal... (國民黨...懶得評...)

而我呢，也曾跟我的...前公司主管討論過"新"的「衝突管理」的想法與觀念，結果當然是，沒被接受。沒被接受的原因是：「眼前的困境都過不去的話，還談什麼未來!!??」。我是忍不住回嗆：「人無遠慮，必有近憂」。當然，一樣，不被接受。好啦~~這就是我離開的原因!!

司法主導的政治妄想

今天在看林濁水先生的書 - 「歷史劇場」時，裏面有一段話，讓我笑到不行。這段話是這麼說的：
　(政治)比諸球隊，行政、立法有如前鋒後衛，球賽開始，雙方馳騁全場，攻城掠地；至於司法則如守門員，負責(原文寫"只能")固守球門，如今(台灣的政治)前鋒後衛全數犯滿離場，剩下守門員衝到對方球門射球，主導球賽，真是荒唐古怪。

由於實在太好笑了，我的笑聲甚至大到引起他人側目....^D^
不過，我想這種情形並不是台灣政界獨有，幾幾乎是整個台灣社會的普遍現象。以我的前公司為例，主管層對於"政策的制定與執行"(立法與行政)，可以說是一整個的"無知"(註)。其結果就是，政策的推行全然仰賴稽核與處罰(司法)。當然，這兩者(台灣政治與我的前公司)的情形仍有不同，我的前公司前鋒後衛沒有犯滿離場，頂多只是"不知所措"而已；我的前公司的守門員也沒能跑去射門，因為稽核的標準與方式無法確立(稽核的標準與方式也是由我們"不知所措"的後衛所擬定...)。我們有價值觀的錯亂，而沒有(比較沒有)族群的對立，值得慶幸...嗎!!??

法律，是道德的最低標準。然而，我們正處在，道德觀全面"扭轉"的年代(不是淪喪，只是正在轉換)；在新的道德觀被"萃取"出來前，司法就成了價值判斷的唯一準則...只要守門員不陣亡，還有希望的啦~~~

註：
主管層對於"政策的制定與執行"的"無知"，其實也不能怪他們。人家可也是從荒煙漫草中，憑著過人的努力與毅力，爭得現在的榮景。只是，當初的小團隊，合著行政立法司法於一身；現在組織擴大了，應該將行政立法司法三權分開，又有誰懂地吶~~~
而且，一般而言，一個 10 人團隊裏，大概頂多只有 2~3 人是真的具有足夠的才能，能夠真的成為主管或領導者。然而，在台灣社會下，一人得道，總得雞狗升天；是以組織擴張後(或是取得執政權後)，總是會出現"雞主管" or "狗長官"的有趣現象。這一點，在「歷史劇場」裏，"好像"也有點到一些些。有沒有可能，在不改變台灣原有文化之下，改善這種情形呢?? 我還在想...

PMP Pass

今天早上，終於去考過了 PMP ~~~YA~~~
其實自己很喜歡讀書，也常涉獵一些管理類知識書籍，只是基於對考試的恐懼感(Plus懶惰)，始終未能跨出認證這一步。這幾天，努力猛K PMBOX，雖然覺得裏面的管理流程知識很有趣，卻也"不得不"承認，PMP 真的不是很有用!!!

之前就曾看過這篇文章：
「PMP證照是專案成功的保證嗎？」
裏面有一段話：「一個專案經理的工作，大概有70-90%的時間在協調溝通」
相信多數的人對這段話都能認同 (包括 PMI...吧!?)
然而，整個 PMP 44 個段階裏，屬於溝通的只有 4 個...另外，整本 PMBOX 400 頁，溝通管理只有 14 頁。假設，我這個專案經理必須花 80% 的時間在溝通上面，那麼，我也不過只是用剩餘 20% 時間在處理整個 PMP 裏 90% 的知識流程...真是有點...完全的違反 80/20 原則?

另外，在 PMP 知識顉域裏，有一堆的東東，"幾乎絕對"需要組織的支持與配合。例如：變更控制管理系統、人員配置管理系統、信息發佈管理系統...以及各式各樣資訊收集與計算工具(績效、財務、品質紀錄...)。如果一個組織還要讓專案經理用"溝通之外"的剩餘時間，再自己用 Excel、Word、甚至紙筆，去計算繪製 EV、PV、Pareto Chart...這個專案會成功才奇怪吧!!?? (除非是 1 人專案!?)

我想，把 PMBOX 割一半，用來對組織或公司做認證，是不是更有用呢!? 畢竟裏面有很多東西，似乎只要環境設定好，流程定義好，大多數的專案經理就可以照著做!? (反過來說，環境不配合，想照著做也沒用!?) 專案經理的認證重點，應該在於對專案管理的流程"概念"有充分了解，以求能快速"融入"組織的"硬體"架構環境；了解流程概念，以求在專案執行時，能快速且正確的"選擇"或"驅動"進入較好的流程階段，以達到簡化管理的目的。至於進入各流程階段後的執行細節、工具與技術，反而應該是組織本身需要去處理與建立的...!!!???

以上，考完 PMP 的有感而發。這幾天 K 書，我家貓咪總愛來跟我搗蛋。我看書，她要來玩我的書；我上線上模擬測驗，她要趴上我筆電...算了，總是考過了，還是感謝她的伴讀吧!!?? 好累...睡覺去...

高速公路的速限標誌

只有開過高速公路，高速公路的速限標誌應該不會覺得陌生(除了家裏太有錢，不在乎吃罰單的人)。通常，我們一定會先看到這個標誌：


對於大多數開小車車的我們，上面這個標誌，沒有意義，不用理他。重點是後面那個，在前一個速限標誌後面不遠處，還會有一個速限標誌：


這個標誌才是開小車車的人需要注意的東東 (有些路段速限 100，有些路段速限 110)。然後呢，我沒事常在想一個問題，如果我是一個不懂中文的外國人，拿著國際駕照來台灣租車出遊，上了高速公路，看到這樣連續 2 個資訊不同的速限標誌，我應該怎麼辦??

事實上，我們有很多交通標誌，常會附帶有"中文"的例外條件："禁止右轉"附帶"公車除外"；"禁止左轉"的標誌下面附帶"17-20時"，下面再加一行"(例假日除外)"...雖然我是本土台灣人，但每次開車時看到這種附帶資訊的交通標誌，都讓我覺得頭痛外加眼睛痠；車子行進中，看到"禁止左轉"時，還要再分神瞇眼看一下標誌下面那一排小小的例外條件字串，然後再描一下時鐘，腦海裏開始計算"現在"到底可不可以左轉；此時車子當然還在行進中，眼睛不但觀四面，更是要觀八方...

我個人認為，我們的交通部偷懶 (雖然這也不能怪他們)。當交通標誌之表意有不同的情形出現時，應該要能發明創造新的標誌，而不該只是用段文字描述即了事 (文字描述應該只適用在暫時性的情形)。不過，算了，別說政府了，就算是私人公司 (例如我...以前的公司)，也不會有這麼主動的 sense 的啦~~~

UML物件裏的Generalization

在 UML 裏，有一種關係叫 "Generalization"。一般而言，我們把這個關係當作物件「繼承」的表達。不過，在此之前，一直對 "Generalization" 圖示的方向性有疑惑：為什麼他的方向是從 "子類別" 指向 "父類別" 呢!?

很早以前，大概從高中剛始，自己對哲學就一直很有興趣，還曾一度想以哲學系為目標；只是因為自己對科學"更"有興趣 (也有未來出路的考量)，所以選了電子系。然而，自己對哲學的興趣一直沒有消失，所以大概從三年前開始，跑去洪建全基金會上傳佩榮教授的「西洋哲學」課程。這個課程，對我有很大的幫助；其幫助不是在人生觀或人生態度的建立，而是在「思考過程」的進步。是的，我特別強調了「思考過程」這個概念，這個概念表意著一個「活動」，而這個活動體現了我的「存在」...

上面那一段其實是廢話。我在學哲學的時間，跟我在學 UML 的時間差不多剛好重疊；這也讓我在學 UML & OO 時，有了一些與他人不同的思考視野 (也不知道是好還是不好)。針對本文一開頭的問題來說，一般多數的"華語"人士，大概都是這麼解釋：「祖先不知道子孫的存在，可是子孫卻知道祖先的存在...」(此段文句取自 "OCUP UML初級認證攻略"；另外，我大學時的 C++ 老師也是這麼解釋)。

一般而言，這樣說應該也沒錯，而且，知道怎麼用就好了，不是嗎?? 不過呢，在我上過哲學課程之後，我卻對 "Generalization" 有了些不同的看法。引述一段黑格爾 (Georg Hegel) 的話：「An idea is always a generalization, and generalization is a property of thinking. To generalize means to think. 」。我想，應該很少人知道 "Generalization" 在哲學領域裏所代表的意思 (大概也沒人像我這麼無聊吧!?)。這裏留下 Wiki 的連結：Wiki百科 - Generalization

我想說的是，正因為 UML 想表達的是 "Generalization" 而不再是 "Inheritance"，所以箭頭方向會從子類別指向父類別；從 "實體(implementation)" "抽出(generalize)" "概念(notion)"。而這樣也更能表達英美實證主義哲學，其 "由實體歸納出概念" 的思考方向...(上面這一段文句，我還不知道該怎麼描述比較好...)。好啦，我的意思就是，"Generalization"的方向，其實是有其哲學上的意涵 - 當然，是不是真的有這種意涵，我也不知道 - 反正，知道怎麼用就好了啦~~~~

不過，我也想知道，一開始的時候，為什麼是用 "Inheritance" !!?? 個人的猜測，一開始時候，也就是 "Inheritance" 的時代，物件導向的 "學術概念" 還沒很完備。一直到 Java 時代，也差不多是 "Generalization" 時代，物件導向概念與方法才算比較成熟，所以才把 "Inheritance" 換成了 "Generalization"。當然，直到今日，這些東東仍然不斷在演進，就像 UML 的版本仍不斷在更新。未來，這些概念的用詞，是否會再改變，我想答案是肯定的吧!?

PS:我個人其實不怎麼喜歡 "知道怎麼用就好了" 這一段話，這樣的態度，某種程度上的阻礙了學術的進步。不過，那是另一個issue了...

OCUP-UML 初級認證

一直以來，對於認證考試都有一種...微妙的心裡障礙。應該是一種恐懼感，亦或是一種不信認，還是只是讓自己發現自己原來不過爾爾的酸葡萄!!?? 用UML做系統分析其實也有好幾年了，一直很希望能將這個語言推廣出去，成為一個組織團體合作時的共有溝通橋樑。是呀，共有的溝通橋樑，有誰認真想過一群人在一起合作開發系統時，居然還需要有-除了母語之外的-其他的語言作為共有的溝通橋樑!? 其實，我也搞不懂，長官們是否有認真想過這個問題，是否也會覺得這很重要? 或是他們只是覺得這很重要卻又不是這麼重要。很重要，最好有人去 Survey；不是那麼重要，不值得讓組織願意動用資源去投資...所以最好有人可以只利用自己的時間 (不佔用組織資源，或只佔用一小點點組織資源) 的情形下，將這個好像很重要但又好像不是重要到值得動用組織資源去投資的東西推廣出去... 考認證，那是另一個層次的問題，也就是說，組織是怎麼個樣我已不想管了。雖然自己真的很討厭考試，還是得強迫自己屈服，總是得為未來在台灣這個文憑主義的社會中找新出路而打算。考試考上了~~YA~~公司快倒了~~哦YAYA~~

Espresso & OpenMind

因為喜歡喝咖啡，所以在辦公室放了一台 Espresso 咖啡機，每天泡咖啡。之前舊的咖啡機，是很便宜+簡單的蒸汽式咖啡機。這種咖啡機的壓力不足以煮出好的 Espresso，但打打奶泡卻還夠力。讓蒸汽管依著杯子邊緣、讓管口浸在奶平面下一點點、讓蒸汽沿著杯子邊緣衝入奶水中、讓奶水旋轉、讓奶泡混合均勻。為何要讓蒸汽管依著杯子邊緣呢? 主要"好像"是為了讓奶泡旋轉，而且看別人都也是這樣做...就沒去想太多了...

後來換了一台幫浦咖啡機 (la Pavoni)，這台咖啡機的壓力夠，可以煮出不錯的 Espresso & Cream，可是打奶泡的蒸汽之強度卻稍有不足 (果然是便宜貨)，用之前的奶泡打法，總是無法讓奶泡混合均勻。一天，一位同事問，"為什麼打奶泡時蒸汽管要靠著杯子邊緣"...嗯，好問題 (只要是那種...讓我發現那是平常的我所不會去想到的問題，通常我就當它是一種好問題)。既然 "用這台機器打不好奶泡" 是個我一直無法解決的瓶頸，何妨死馬當活馬醫。試著把管子往中間移動，哇塞，本來轉不大動的牛奶居然旋轉度變強了，奶泡的的混合度也變得比較均勻了... 說的也是，因為力矩變小了嘛!!

這篇文章不是要談論怎麼泡杯好咖啡，而是希望來思考一下：當我們遇到解不開的問題時，是不是只是因為我們習慣性的讓問題的根源總是被我們狹隘的視野給過濾掉 - 即便"他"其實一直在你面前遊盪!? 因為過去的成功經驗，所養成的做事與思考的習慣，是不是就是讓問題的解答難以浮現的死角暗箱!? (參考一篇有趣的網路文章"熟練的無能")

" 跳脫習慣" 與 "OpenMind" 其實有著類似的概念。"習慣"是一種流程的慣性養成，雖然我們會把習慣分成"好"跟"壞"的，但習慣的養成，原本就是因為實際經驗的"非失敗性" - 不管是"好"習慣還是"壞"習慣 - 也就是說，至少，在習慣養成中的當下，是"快樂"的。先不去探討有關人類 "習慣" 一詞的論述，回到前一段文章裏的一句話 "過去的成功經驗，所養成的做事與思考的習慣"，卻反而讓我們在遇到環境或事物變遷時，創造了自身未來發展的陷阱與障礙。

OpenMind - 打開心胸，第一件事：別再以為過去所以為是對的事就是對的 (笛卡爾 - 人，終其一生，至少要有一次，懷疑所有可以被懷疑的事)......話是這麼說啦，這可不是一件容易的事。在忙碌的工作中、在時程的壓力下，要能停下來、慢下來，重新省視自己 (群體、公司、組織) 每一項過程裏的每一個平常不會注意到的習慣 (包括行為與思考上的)，這可是要有一種..."豁出去"的決心 (列出你願意付出的代價)，才有可能辦到。所以呢，大多數的情形常常是，把"危機就是轉機"掛在嘴邊，卻在"不怎麼願意付出什麼了不起的代價"的心態下，讓"危機"的黑洞愈挖愈深，而"轉機"的大餅卻是愈看愈虛幻......

回頭看看，我們每次的反省檢討 - 不論是自身的或是團體的 - 所討論的反省項目裏 (如果我們有反省的話)，是不是有某一些"理由"，總是常常出現在"遇到的問題之原因"的清單上...該是停下來的時候了!!

詐騙電話

我其實常常接到詐騙電話，有時甚至喜歡跟對方亂哈啦 (反正花他們的電話費)。不過，今天接到的這一通有點不一樣，事實上，我還一度以為他們是真的，情形如下：

我先接到一通有號碼顯示的電話 (看到有電話號碼顯示，先安心一半...)，對方說他是北縣警官，前一陣子破獲一個詐騙集團，因為有發現我的偽照證件與個人資料，所以打電話給我要跟我釐清案情，這第一通電話之所以讓我覺得可能是真的，是因為大部份的時間都是對方在努力說明案情，對方也有問我一些資訊，例如我有哪些銀行帳戶...但因為對方沒有要求進一步的詳細資訊，加上我一時好奇心的作祟，居然一時笨笨的真的告訴人家我有哪幾家銀行帳戶。第一通電話結束前，對方還交代，這是偵辦中的案子，請不要對外公開。另外，他們會把資料傳給檢查官，檢查官會再打電話給我。直到這裏，我還只是半信半疑，直到第二通電話進來...

沒多久，第二通電話就來了 (真有效率)。這通電話是保密號碼，這時我才開始覺得怪怪，對方說他是書記官，要向我詢問問題，以釐清疑點。然而，對方卻只是很努力的圍著我的銀行帳戶資訊打轉，而我就用裝迷糊的方法說我人不在家，所以無法立即提供這些資訊。對方還要我趕快回家：「我們希望在第一時間排除你的涉案關係，如果你無法在第一時間釐清，我就必需發傳票給你，到時你得自己準備資料出庭應詢...」。天啊，我還真是豬罐頭，我一直到這個時候才確定我遇到了詐騙電話。人，有時候太好奇，還真的是很危險。我說：「不然你告訴你的辦公室在哪裏，我直接收收資料去你辦公室...」，然後對方就掛我電話...

不管是警方辦案或是檢查官偵訊，都不會用電話方式做詢問，一定會用正式的郵寄通知。這個我很早就知道了，卻還是因為自己的好奇心而掉入陷井，我想我真的是太大意了。最讓我悔恨的，是我不小心報出了我的身份證字號。第二通電話，那位自稱是書記官的傢伙，跟我核對我的個人資料，而我居然不小心不小心去糾正身份證號碼的錯誤 (我猜他有我一些簡單基本資料，但沒有身份證字號，結果我卻主動奉上)，我想我這下麻煩了...

這是我第一次打防詐騙專案 165，服務人員跟我說，第一通電話所顯示的電話號碼是竄改過的號碼。這還是我第一次知道，原來電話號碼顯示是可以被竄改的。只是因為我是接完詐騙電話立刻打給詐騙專線，所以他們有機會去追蹤來源~~~唉~~~加油吧~~~

陳總統有必要下台嗎-細讀李遠哲公開信後感想

1793年11月8日，法國大革命著名的政治家，羅蘭夫人，在斷頭台上，向著革命廣場上的自由雕像，留下了一句廣為傳誦的名言：「自由自由，天下古今幾多之罪惡，假汝之名以行」。
這樣的話語，聽在法國大革命人士的耳裏，自必是非常的刺耳(也許也有人罵她"騎牆"、"投機")。對當代革命份子而言，"自由"二字就是他們無可侵犯的核心價值。在這大義的旗幟之下，一切對於"自由"可能的牴觸或阻礙的人、事、物，運用任何手段、不計任何代價去剷除、消滅，自是理所當然的應該。對他們而言，這不是"假自由之名行惡"，而是為了自由的真義而努力。
1881年2月，巴黎公社以法國大文豪-維克多‧雨果八十華誕為名，舉行了盛大的慶典，六十萬人從雨果的寓所前遊行通過。而1885年6月1日，巴黎萬人空巷，從凱旋門一路擠到先賢祠，就為了替雨果送靈。維克多‧雨果，不但法國人將他喻為人類的文化遺產，更受到全世界的人所崇敬。他不僅是偉大的文學家，而且是偉大的社會鬥士，他所留下的思考精神，推動了整個社會價值的前進。如雨果的著作《悲慘世界》裏表達的悲天憫人的思想，或是《九三年》書裏所說：「絕對正確的革命之上，還有一個絕對正確的人道主義」。因為這樣的精神，人們才開始發現，追求自由，不值得無所不用其極；維護自由，不應該不計任何代價。
今日細讀了李遠哲院長的公開信，發現一些值得我們深思的重點。信是這麼寫的：「追求民主是台灣人民永不中止的理想，而廉政是民主政治的核心價值。如果陳總統與執政黨仍無意放棄民主政治的核心價值，無意背棄台灣人民對民主政治永不中止的理想，那麼就必需在"小我"與"大我"、"政黨"與"國家"之間，做出正確的抉擇」。看到這一段話，我忍不住會想問，「追求民主政治」是不是我們唯一的理想，而在"民主政治"之上，是否還有其他的核心價值? 讓我們這麼想，如果「在談論民主政治的追求之前，必須先維護國家主權」這樣一段話是正確的，「如果國家的獨立性受到侵蝕或剝奪，則民主政治將無以實現」這樣的想法是確立的，那麼，陳總統其實已經抉擇了"大我"-維護國家主權，而犧牲了"小我"-說謊與報假帳；執政黨也抉擇了"國家"-維護國家獨立，而犧牲了"政黨"-起訴即停權之黨紀的失效。從這樣的角度來看，陳總統真的須要下台嗎?
雨果的《九三年》是我最喜歡的一本書，書中的主角，郭文，領導共和軍海岸部隊，成功粉碎了保皇軍的進攻，並將保皇軍的領導人"朗德納克"，以及其殘部困於城堡裏。朗德納克捉了三個年幼的孩子為人質負隅頑抗。城堡被攻破，朗德納克從暗道逃走，而他的副官在臨死之前放了一把火，想將人質燒死。這時，三個孩子的母親眼見自己的骨肉就要葬身火海，痛哭哀豪。朗德納克動了惻隱之心，返回城堡，救出三個小孩，卻也因此被共和軍逮捕。就在朗德納克送上斷頭台之前，郭文感於他捨身救人的精神，私下放走了他。郭文犯了軍法，他將接受軍事審判。在本書第三部/第七卷/第三章，郭文接受審訓時說：「我做為司令，應當做出表率；你們做為審判官，也該做出表率」。審判官問：「你要我們做出什麼表率?」「判我死刑」。
郭文遵從了他自己的核心價值-純潔的良心，但他也選擇接受他所相信的價值-共和體制，即便這個體制有所瑕疵。觀看郭文的做為，再看看陳總統的言行，不難發現兩者之間價值高度的差異。這也是雨果之所以為人們所尊崇，而陳總統的路卻似乎越走越嘔、越走越難過。
"民主政治"是不是就是唯一的理想? "國家主權"該不該是最高的價值? 我們是否該認同，為了這樣的大義，割捨一些小善小德會是值得的? 我覺得不是這樣的，正如雨果所說：「每一個世紀都有他的使命，這一個世紀完成的是公民的工作，下一個世紀完成的是人道工作」，那麼，進入21世紀的我們，其核心價值與使命該是什麼呢? 我想，應該會是如李遠哲院長在『以色列─巴勒斯坦科學組織』召開的國際科學委員會議中所感受到的，「多元價值衝突的尊重、合作與寬容」。

Powered by ScribeFire.

別再回首看藍天

　每天的、每個時段、每個頻道，不斷重覆插放的連續劇，討論的批評的叱罵的看笑話的焦點話題，"回首藍天的駙馬爺"(也許可以當個暢銷小說的書名)，看了這麼多，聽了這麼多，想了這麼多，卻發現自己罵不出口，也笑不出來。如果，我站在他的位置；如果，我處在他的地位；如果，我就是他，我是不是會做出一樣的的蠢事，是不是會犯相同的錯誤？我會，天呀，我真的會，我就是那個被人罵的豬頭、被人笑的白痴、被人嫌的傻瓜蛋，我似乎已經看到，那個窗外的藍天！
　先不管有無違法情事，單就簡單的投資行為而看。如果我有消息、我有管道、我有快速賺錢機會(而且大概是合法的)，我賺不賺？也許，考慮自己的身份不好太過招遙，可是對於我父母的、兄弟姊妹的、好朋友的，如果我可以幫他們多賺一點點錢(不多不多，比起政府隨便一筆預算都少得多)，我做不做？更甚者，我的父母、朋友、兄弟姊妹，問問看我能不能提供一些訊息、給予一些幫助，我，幫不幫？有多少人知道，什麼是"內線交易構成要件"？又有多少人知道，證卷交易法第157條之1的內容是什麼？我又如何分辦，什麼算合法投資，什麼算違法交易？
　法律，只是最低標準的道德，只要是人所訂定的法律，就必定會有漏洞、缺陷；所以，在法律之上，需要有世俗道德的支撐。只是，在面對現今社會下，許多鑽法律漏洞的事件、走法律邊緣的"壞人"，所有討論焦點，似乎都指向單一的結論，"世風日下，道德淪喪"。"淪喪"？表示以前曾有，現在喪失了，是這樣嗎？相同的道德感可以套用在不同的時空上嗎？讓以前純樸的人們，來到現今的花花世界，就會過得比較好嗎？記得之前看到一篇報導，一位小姐走失了她的狗狗，因為張貼尋狗啟示而被開了張罰單。不少媒體以及其他受訪者，或多或少都表達了一些同情之意，認為法律的執行應該多一些人情。HOW？怎麼做？如果我是那個執法者，我怎麼做？這種無經驗可依無前例可循的鬼情形，我們要如何去找到執行的平衡點，我該如何辨別，什麼時候需要多一點人情？(就只看到沒有按照標準程序操作的鐵路維修工...)
　要說道德淪喪，不如說我們根本尚未建立該有的道德標準。我們的資本市場與民主經驗都還很年經，以人類來算，還只能當是初出茅廬的青年。所以，在這個事件上，我們不該只是把焦點放在誰對誰錯誰說謊誰該負責，而是可以從這個事件裏，討論我們可以從中習得的道德經驗。至少，我學到了一些東西，我也了解了一下什麼是"內線交易"，我也知道，位置愈高，愈要懂得自制避嫌；不只是當位者，還包括他的左右親信支持者，都要有同樣的道德感(一人得道，雞犬避遠)。這不容易呀，尤其是在台灣這樣重人情的社會...

開會技巧知識分享

前言：
開會是是組織溝通最常用的方法，然而多數的會議執行情形，要不就是變得太發散，要不就是變得太封閉，以致常會有”以會養會、越開越不會”的情形。以下分享開會的技巧與知識，期能增進開會的效率。

本文：
這裏將開會技巧分成三個不同的領域：”認清自我”、”責任歸屬”與”執行步驟與技巧”。”認清自我”與”責任歸屬”其實是一個組織在組成的時候就應該注意的問題，而這兩個問題其實也會貫穿整個組織的運作流程。很多時候，一個組織的運作如果不順暢，很有可能就是這兩個領域出了問題。對於會議的執行，其實也一樣，如果這兩個領域沒能釐清，會議的效率必定會大打折扣。以下就分別對這三個領域說明之。

1.認清自我
知道自己組織是什麼、知道自己組織的目標、知道自己組織想要做什麼，這些都是”認清自我”的基本條件。而在面對”會議執行”這件事的時候，主要需要認清的項目包括下列兩點：

(1).組織的情形
組織的情形又分成”人”與”環境”。”人”的情形指的就是組織成員的能力、經驗等問題，而”環境”的情形指的就是組織的文化。面對不同的的成員情形與組織情形，必須運用不同的開會技巧，才能達到應有的效率。這裏將成員的經驗與能力分成”高”與”低”兩種，將組織的文化也分成”開放”與”封閉”兩種。所謂開放的組織文化是說組織成員對於問題的反應踴躍，組織成員熱心於提出問題與意見；反之，封閉的組織文化則會有相反的情形，成員對於提出問題與意見的意願不高。將上述”人”與”環境”的情形組合起來，可能會產生以下四種情形：

A.成員的經驗與能力高+組織文化開放
如果成員的經驗與能力足夠，而如果組織文化又比較開放，則開會很容易因為討論的目標太多，造成討論失去焦點與方向。

B.成員的經驗與能力高+組織文化封閉
這種情形比較特別，通常是因為組織負責人太過專制才會發生，因為如果成員經驗與都夠，通常組織不至變得封閉。如果真發生這種情形，這個組織會有解體的可能性。

C.成員的經驗與能力低+組織文化開放
這種情形是比較好的情形，但因為成員能力經驗不足，會議負責人必須小心導引會議的進行，否則會議的進度可能會不如預期。

D.成員的經驗與能力低+組織文化封閉
因為成員的經驗與能力較低，對於問題的思考比較不易聚焦，開會時的討論容易變得沉悶，討論的結果可能只有宣示的效果而不易成為共識。

不管是上述哪種情形，會議負責人與組織負責人其實都是會議成敗的關鍵。在「第3節-執行步驟與技巧」時會再探討面對相關情形時，會議負責人與組織負責人的對應方式。

(2).會議的形式
這裏將會議的形式分為”開放式”與”收斂式”。所謂”收斂式”的會議，通常都只是在做最後的確認與宣示，因為目標與策略明確，可能發生的問題也少。一個會議會有效率不彰的情形，通常都是”開放式”的會議，這種會議的特色就是「目標與策略不明」。然而，多數的會議其實都是為了釐清問題或探尋方法，所以多數會議本來就常常是「目標與策略不明」，而這也是開會技巧所要面對的問題。
以本專案的某一次會議為例，一開始專案經理請同仁分享客戶問題的管理方法，介紹完之後，專案經理開始提出了一些問題。因為會議之前只有提到會議主題而沒有說到會議目標，而會議一開始就讓同仁進行分享，也沒有提到目標與策略是什麼，所以一開始對於這次會議的目的就不甚了解，在聽了經理提出的問題之後，更對會議目標充滿疑惑，所以忍不住提出這樣的問題：「會議的目標是什麼?」。經理的回答是：「我們的目標是希望找到好的方法幫助同仁執行運作」。這樣的答案是其實是有疑問的：與會同仁是否理解與認同這樣的的目標?
猜想，專案經理應該是沒有花足夠的時間處理會議前置工作；專案經理可能只是認為這樣的會議配上這樣的目標就已足夠，而會議本身只要開放大家討論即可，卻忘了與會人員裏尚有許多未來得及進入狀況的新同仁。這樣的開會效率其實是有限的，這樣的經驗分享的效率也會有所打折，當然，如果主管滿足於這樣的效率，組織同仁大概也沒什麼好抱怨的。(註1)


2.責任歸屬
在上述的文章裏有提到兩種負責人，「會議負責人」與「組織負責人」。組織負責人其實就是”主管”，而會議負責人可能是會議主持人，也可能是主管。這必須看這個會議的發起人是誰，如果發起人就是”主管”，則該”主管”就應該是責無旁代的負責人，即便”主管”是交待別人當會議主持人。
事實上，一個組織的文化跟主管本身有絕大的關係，即便是同一群組織成員，面對不同的主管也可能展現不同的文化情形，所以就算主管交待別人當會議主持人，也無法脫卸責任(除非這個主管不在意會議結果)。當然，如果主管能與會議主持人有充份的溝通，能夠讓彼此對目標與策略有足夠的共識，那至少可以均分責任。
在接下來的執行步驟與技巧裏，重點會放會議負責人身上。所以，會議執行前，責任的釐清與區別是非常重要的。


3.執行步驟與技巧
執行步驟簡單分為三個：會前、會中、會後。多數人應該都知道，會前的準備是非常重要的，可是多數人其實都不清楚”會前的準備”到底要準備什麼。這篇文章的主軸即是放在會前準備的技巧上。當然，很多人可能會因為沒有時間做會前準備，而只好直接依靠開會來解決問題，但卻造成會議的效率的低落。其實這就有點像系統開發時碰到的問題，因為沒有時間做好需求分析就直接開始撰寫程式，最後做出來的東西反而不是客戶要的….
在這裏，我們必須特別注意，會議負責人與會議主持人是不是同一個人。如果會議負責人與會議主持人不是同一個人，那麼在會議之前的充份溝通將是非常的重要。在以下的步驟說明裏，會先假設會議負責人與會議主持人是同一個人，所以只寫出會議負責人的執行重點。對於一個開會技巧尚未成熟的組織而言，建議最好先讓會議負責人與會議主持人就是同一個人。

(1).會前
會前主要的工作步驟有三個：資訊收集、分析與整理、目標與策略擬定。其實這樣的工作步驟跟系統開發是很像的：客戶訪談、需求分析、技術解決。想說的是，很多東西其實是”一法通，萬法通”，養成這樣的思考習慣其實比找到好方法更重要!!

A.資訊收集
資訊收集要做的工作其實就是事先的訪談(有點像客戶訪談)。正如前面所說，當一群人開會時，容易變得太過發散或太過收斂，這就是所謂的”小團體效應”(這裏的小團體指的是5人以上到30人左右)。為避免這樣的情形，事前應該先以2~3人的小小團體溝通為手段，一方面可以收集資料，一方面可以幫助要參與會議的同仁先行了解會議目標並釐清想法，以免到了會議執行時，或是提不出想法，或是想法太過偏離。這樣的小小團體的人數，建議不要超過5人，這個人數也是XP(終極開發流程)所建議的人數。

B.分析與整理
資訊收集之後，就必須進行分析與整理。這個動作可以幫助了解組織的情形，以擬定適當的會議目標與策略。這段過程注意的重點有二個：
a.了解組織情形
利用這段過程，可以了解組織成員對會議主題的經驗與了解程度，這些資訊有助會議負責人擬定適當的目標，並幫助有效控制會議的進行。
b.分析資訊共通性
分析資訊共通性可以了解組織成員對於會議主題上的認知的差異，並可從資訊的共通性裏整理出會議主題的關鍵鏈，這個關鍵鏈可為會議策略之主軸。

C.目標與策略擬定
首先，我們可以從所收集到的資訊，分析組織的情形，來決定適合的目標。這裏談的目標，其實包含”程度”的意念，亦即了解這次的會議執行所能達到的程度。這裏把程度分為三種：
a.如果收集到的資訊多，且共通性也多，那麼會議就可以用”達到共識”做為目標。
b.如果收集到的資訊多，但共通性少，那麼會議目標可能只能以探討共通性為主。這種時候，最好先將會議規模縮小，利用小小團體討論，先找出共通性。
c.如果收集到的資訊很少，尚無法有效分析共通性，那麼建議會議負責人事先做好會議內容，在會議上直接傳達宣示就可以了。(或是根本不要開這個會)

接下來，整理所收集到的資料，並分析出關鍵鏈，就可以擬定會議的目標與策略。所謂的關鍵鏈，可能是一連串的相依性的問題或意見，而這些其實是組織成員共通的問題或意見，會議負責人將這些串連起來，就成為會議進行的方向。接下來，再依據組織的情形決定執行策略。以下分二種情形：
a.如果組織成員資深的比較多，則會議負責人可以將所收集到的資訊直接付諸討論。
b.如果組織成員資淺的比較多(可能在資訊收集時會發現所能收集到的資訊不足)，這時候，會議負責人就必須注意問題導引。建議使用開放性提問的方式(註2)，導引成員思考與提問。事實上，如果在資訊收集時會發現所能收集到的資訊不夠多，建議不要直接執行會議，而應該增加多次的小小團體會議以提高效率。

(2).會中
一旦擬定了策略，會議就可以依策略執行。重點在於如果發現會議執行與所擬定的策略有差距 (可能是事前準備不足所造成)，最好能即時停止討論避免時間的浪費。也可以就地轉成小小團體討論，可能會有更好的成效。

(3).會後
會議結束後，除了留下討論紀錄外，最好也把討論的過程及優缺點記錄下來，例如會議是否有依策略執行，如果有的話，成功的關鍵是什麼? 如果沒有的話，原因又是為何? (如果有做好會議前置準備，這些會後資訊才有保留價值；如果沒有做好會議前置準備，會後這件事最好就算了…)

結語：
良好的溝通是一個組織能夠成功的最重要的關鍵之一，一個溝通不良的組織，幾乎免不了失敗的命運。期待這樣的知識技術分享，能幫助增進組織的溝通效率。

註1：
我其實並不認同「找到好方法」這樣的目標，個人認為，所謂的”好方法”會依目前的資訊發展情形、依成員的能力、依客戶的需要而有所不同。所以覺得，比起「找到好方法」，「找到”幫助同仁找到好方法”的方法」才是更重要的目標。

註2：
人的思考通常不可能真正的天馬行空、不著邊際，絕大多數的人的思考都還是會有所依附，然後再運用聯想的方式，建立自己對問題的思想地圖。所以，在會議進行中，資深同仁可以依附自己的經驗來提出想法；但對於資淺的同仁，則可能會先從其他同仁的話語裏，挑選自己了解的部份為依附，然後再以此為出發點來進行思考聯想(如果沒有挑選到可以依附的東東，大概就會想睡覺)。這時候，組織負責人的提問，很容易成為其他同仁(不管是資淺同仁、甚或是尚未釐清會議目標的資深同仁)的依附目標，結果意外的將整個會議導向了原本非預期的方向。這樣的情形原本就是人之常情，不是組織負責人聲斯力竭、大聲疾呼就會輕易改變的…


附錄：組織文化與組織負責人

組織文化的建立與組織負責人有極大的關係，就像之前所說，同一批人，在不同的主管面前，也可能會展現不同的文化。如果一個組織的文化比較封閉，而組織的負責人希望能有所改變，建議可以從下面兩點著手：

1.接受不成熟的意見
以資工所而言，多數的主管都有接受不同意見的心胸，卻沒有接受不成熟意見的能力(風險容忍)。理論上，所謂的主管，應該也是組織裏經驗與能力較好的人，所以通常組織成員所提之意見相對而言都會是比較不成熟的。這時候，多數的主管多會忍不住想要糾正。多數的主管可能認為這樣的糾正行為是讓成員有所成長的機會，也可能認為導正成員不成熟的意見，避免成員失敗是主管應負的責任；但事實上，這樣的行為對剛入行、有衝勁、缺經驗的人也許是有效的，但對其他多數人反而會造成思考與成長的抑制。
李世民是中國最成功的皇帝，他最有名的事蹟就是「廣納諫言」。但多數人可能只注意到他具有接受不同意見的心胸，卻沒有注意到更重要的是他有接受不成熟意見的能力。事實上李世民是非常聰明的人，他本人的意見很多時候會比他的臣子還要好、還要高明。然而，他的諫臣 魏徵 卻極力要求他去接受那些不成熟的意見。因為，如果主子時常糾正臣子的意見，那臣子自然會減少意見的提出，到時即便賞金封爵，也不會有人再提出諫言。

2.縮減範圍
當然，要接受不成熟意見，必須考慮到所能容忍的風險(畢竟是不成熟的意見)，如果組織本身沒有足夠的風險容忍能力，那就應該縮減執行的範圍。例如，想在一個多人的組織推行一個新方法，可以先分割小團體試行，然後再慢慢擴大(有點像雛形法或漸近法)。但是，這種方法的執行，其組織負責人必須要有很強的能力與控制力，必須有能力區分階段，必須要能清楚掌控各階段的情形與銜接，每個階段都必須要能完成完整驗證。這也意謂，比起”瀑布式”執行法，會多花上好幾倍的時間…

xtags library 使用上的BUG

我們要做一個 Web 介面供人員查詢資料檢核結果。原來的 Web 設計是用JSP讀取資料庫資料，然後 output 成 XML 直接回傳給 Client 的 Browser。而這個回傳的 XML 有標記搭配的 XSL，Browser 在讀取這個 XML 後，會去找到搭配的 XSL 以產出 Html 型態顯示。也就是說，將 XML & XSL 的處理交給 Client Browser。

這樣的方法發現一些問題，會有一些 IE Browser 無法正常顯示 (Mozilla Firefox 好像就沒這種問題)。我們推測是 Browser 對 XML 與 XSL 的支援上有問題 (可是找不出問題在哪!?)。後來，我們決定修改設計，將 XML & XSL 的結合，改由 Server 處理，所以我們在 Tomcat Web Server 上 加裝了 xtags library。

用 xtags library 處理 XML 其實很容易，只要在 JSP 程式裏加上一些 TAG 就好。

例 1 : 直接處理一個已存在的 XML File
<xtags:style xml="test.xml" xsl="test.xsl>>
</xtags:style>

例 2 : 內嵌 XML
<xtags:style xsl="test.xsl">
<root>
<childnode></childnode>
</root>
</xtags:style>

也可以這樣 :
<xtags:style xsl="test.xsl">
<%
out.println("<root>");
%>
<childnode><% =varible %></childnode><br /> </root>
</xtags:style>

然而，如果是用"例 2"的方法，會有怪問題
JSP 的結果會問隔性的出現 "IOException : Stream Closed"
也就是說，執行第一次會成功，第二次失敗，第三次又成功，第四次又失敗....

這個問題是 Tomcat 與 xtags library 的問題，目前無解。但可以改用以下方法來避開這個問題：
<xtags:parse id="myreport">
<root>
> <childnode></childnode>
</root>
</xtags:parse>
<xtags:style document="<%" %>"">


這樣就不會有 Stream Closed 的錯誤，也解決了之前 Browser 的問題....

應該有的心結

最近，客戶希望我幫忙整理一下系統文件，並且也為系統維護人員做一下教育訓練；他希望，如果發生一些問題，可以做一些簡單、初步的處理。其實，這件事他跟我提過好幾次，我同意他的看法，我也認為這是我應該做的事 (而且，如果做的好，還可以減少我的負擔)；然而，實際的工作執行進展，卻與理想差距甚遠。為什麼呢?

理論上，一個系統開發完成後，應該就會有系統文件的產出。所以，所謂的"整理一下系統文件"應該也只不過是把原來的文件做一下整理修改就好；很可惜，不是這樣的，我所產出的系統文件，大概只述說了系統 10% 的事實，而一份只有 10% 的文件，在經過一段時間之後，對我而言，其實用性可能接近於零。要了解為什麼會有這樣的結果，必須了解我的工作流程；不過，在解釋我的工作流程之前，我可以先預測客戶要我"整理一下系統文件"這個工作的最後結果：再做一份涵蓋度只有 10%的系統文件....

OK，下面開始用圖形的方式介紹我的工作流程。這裏不特別對圖形符號多做說明，因為，我好懶。反正，第一張圖是當接到一個工作時，決定執行策略的流程。我們幾乎都是走"分散"的路線，除非這個工作真的被細分到非常的小(1、2個小時)...

接下的第一張圖，就是工作的基礎流程。在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程。其中真實的工作模式有四種，也只有經過這四種模式，才會達到工作完成的結果。這四種模式為：[隨便]>顧名思義，就是，隨便了啦...；[決鬥]>就是時間很趕，所以，也有一點隨便了啦...；[真的做]>這種情形，幾乎只發生在程式撰寫的時候(不包括debug)...；[實作練習]>這是我這幾年最常使用的模式。[隨便]、[決鬥]、[真的做]這三種都很容易明白，所以我只對 [實作練習]模式做另外的說明。

接下來，我們來看一下[實作練習]模式。實作練習其是就是因為我們對某項技術的掌握度不足，卻又沒有足夠的練習空間與時間，所以只好用實際的工作來練習。這種運作情形，通常都沒有什麼好結果；比方說以我的情形來看，我的路線通常會變成：沒有把握->很煩->時程逼近->找人討論更煩->隨便啦...

為什麼"找人討論"會更煩呢，那就要看一下接下來的兩張圖。第一張是"準備找人"：

第二張是"討論中"：

有沒發現，我好像常常會進入[煩燥]模式。下面這一張[煩燥]模式的圖；也就是因為經常進入[煩燥]狀態，所以，其實我有一大半的時間都在"發發呆，做雜事"的情形下渡過。

最後，來看一下讓人更加無奈的流程，[下次再說]。這個流程本來就充滿不得已，而且，記住，因為之前的工作被打斷了，所以，就算想起來要從哪裏繼續下去，也都免不了的必須讓腦袋瓜從頭開始。差別只再於，上一次的工作，是否有讓自己了解工作要怎麼做 (有果有的話，可以快樂的進入[真的做])。

好了，回到最上面的問題，今天客戶要我整理系統文件，並且對系統維護人員做教育訓練...如果是要寫使用手冊，並且對使用人員做教育練訓，我大概還有 6成的把握。可是，系統文件到底該怎麼寫，系統維護人員到底該怎麼教，我怎麼可能知道 (有誰知道的，可不可以分享一下呀!?)。好吧，我想我已經進入[煩燥]模式了。我猜，最後大概還是會不得已的進入[決鬥]模式，隨便交差了事...

PS：我在第一張"工作基礎流程圖"的說明，有這麼一段話：「在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程」。大家不會想，既然是"子流程"，為什麼不叫"[XX]子流程"就好，偏要叫"[XX]模式"。這是因為，我一開始畫圖的時候，還不清楚我該怎麼畫才好，等到我畫到一個程度，我才發現到原來我的圖的結構會有這樣的階層性，可是，我已經懶得回去改字了。其實，我有一大堆的文件都有這種情形，甚至，我所開發的系統也有這種情形 (原本應該只是雛形，卻愈加愈大，最後還被趕鴉子上架)。這些東西，都會自然的、必然的被我丟到思想的垃圾筒...

颱瘋天

颱瘋天，被叫來加班
原因是塌非斯系統的產品發不出去 (塌非斯系統 Product 程式會當掉)。查了半天，終於找到了原因，以下說明之：
塌非斯系統有關產品的部分，我們有設計各相關產品的Template
在Template裏有各式 Tag，例:中心位置在北緯[lat00]度
上述由中括號 '[' ']' 包圍的就是資訊 Tag
程式找到資訊 Tag，然後會代換成正確的資料
例:中心位置在北緯[lat00]度 --> 中心位置在北緯21.5度

然而，當天發生了如下的情形：
1:　while (String.Pos("[") > 0)
2:　{
3:　　tagstart = String.Pos("[");
4:　　tagend = String.Pos("]");
5:　　String = String.Delete
　　　　(tagstart,tagend-tagstart+1); //將Tag的字串刪除
6:　　String = String.Insert
　　　　(value,tagstart); //將刪除的字串處插入實際值
7: }

上述是一個 while loop 的程式，在找出 '[' & ']'，並將中間的Tag代換。
下面說明一下，出問題的 Template 與實際資料

Template裏的某一行:
[its] [tyname_ch] [tyname]

上面那一行代換成這次這個颱瘋的實際資料時，應該會是:
三十午度颱瘋 阿珠 ANNCHU

然而，程式在跑的時候，卻是以下的情形
進入loop前：
　String="[its] [tyname_ch] [tyname]"
第一次的Loop跑完：
　tagstart=1
　tagend=5
　String="三十五度颱瘋 [tyname_ch] [tyname]"
第二次
　tagstart=10
　tagend=19
　String="三十五度颱瘋 阿珠 [tyname]"
第三次
　tagstart=15
　tagend=12
　String="三十五度颱瘋 阿珠 [tyname]"

第三次跑完時，String 的值沒改變
而且 tagstart > tagend !!!??

接下來，程式就進入無窮迴圈了
(我們的 code review，目的之一就是要避免可能的無窮迴圈)

接下來的問題是，為什麼會進入無窮迴圈!?
原來，"珠"這個字的前半碼，這個BYTE的編碼與 '[' 相同
所以程式第四行處理 "三十五度颱瘋 阿珠 [tyname]" 時
　tagend = String.Pos("]") = 12

........................

後來，加班，連夜趕工
把Template裏的Tag通通改成 '[{' '}]'
這樣子的雙位元處理，就不會有這種問題了...

這個事件給我們三個重要經驗

1.中文字的處理
中文字的編碼問題本來就是相當複雜的問題
像之前有同事的做法，將 BCB 的 AnsiString 轉成 WideString
(雙位元字串) 然後再來處理...事實上，也許我們可以考慮
統一使用 UTF-8 來處理字串問題 (包括資料庫的儲存)
大家思考看看吧!!

2.Code Review
這個就是另外提議的項目，可以把文字處理，當做 Code review
的一個項目。

3.客戶服務
這次的這個問題，真的是一開始設計時未思考到的問題。雖然
大多數的時候，客戶有提出的問題，可能都不是問題；或是說
大多數的時候，客戶其實也說不清楚問題是什麼。所以，這時候
乖乖來加班吧...

整合服務的初淺想法

網站、EMail、新聞、BLOG、相簿、行事曆、網拍，這幾個服務可以說是這幾年網路服務的主軸；然而，如果只是單以提供這些服務作為述求，似乎都會進入一個瓶頸:"只能搶免費會員，卻收不到錢"。未來，這些服務應該會走向整合，可是怎麼走呢!?個人覺得，應該會以一些前端技術(如AJAX)，讓使用者作自我發揮的個性化整合，而後端則是提供獨立的服務資訊，也就是走向SOA (服務導向架構)。開水這裏只是幻想一個可能情形，來試著思考這個所謂SOA的東東的可能方向。
　先假設一個情形：用WebMail的好處在於可以在不同的地方、用不同的機器，只要能上網，就可以使用；而缺點就是整體介面的使用上較不方便。如果是用一般郵件程式處理信件(如outlook)，是比較方便，可是就不能到處用。於是，開水想，用 FireFox 的擴充套件技術，配上 AJAX 技術，整合一個具有前端程式功能的 Web Mail 服務。下圖是用這個想法做出來的介面示意圖：
左上角是信件的資料夾，左下角還加上了一週行事曆，其他的操作就跟一般的 outlook express 一樣，真好! 如果要對信件作歸類，直接用滑鼠拖曳信件到指定的資料夾即可；如果要刪除信件，直接按delete；如果要看信，就直接 Double Click，如下圖：

　如果要編輯郵件呢!?就像 outlook 一樣編輯就行啦! 最厲害的是，用滑鼠從檔案總管直接拖曳"附加檔案" (使用Web Mail 要附加檔案是很痛苦的)。

　當然，不只這樣，現在的人可不是寄寄文字郵件就滿足的了，要就要"圖文並茂"；下圖是直接從檔案總管拉圖檔，而郵件編輯時，還可以有點像Frontpage，編出圖繞文效果：

　還有更厲害的，直接從網路相簿拉圖：
而且，只要配合Blog提供的功能(Post Mail Address)，就可以把這封E-Mail，Post 到個人的 Blog 上，真是太棒了....

　要作到上述功能，基本上就必須整合"EMail"、"行事曆"、"網路相簿"與"Blog"服務，實際發展起來，是有難度的。這裏面有三個不同向面的關鍵軸：(1).前端介面：例用如Web2.0或是AJAX技術，以開放源碼方式，建立個性化能量。(2).後端服務：由服務提供源提供具可整合性的獨立服務產品(也是可以賺錢的地方)。(3).中間媒介：這個應該就是建立某種XML標準，讓後端服務具有可整合性，而前端可以容易整合；然而，這個中間媒介也是目前最無所施力的地方(尤其是台灣中小企業居多的情形)；除非有人有力量領導中小企業整合發展(不要再在紅海裏廝殺)，不然的話....是不是應該會是"資訊化社會的推手"的責任!!??

Powered by ScribeFire.

前置需求分析作業

背景
　客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。

需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
　過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
　預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
　請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…

運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
　(1).先討論這件事的程度，意思是說，也許根本可以不理他…
　(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
　(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
　(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
　(1).系統需求分析 (這個步驟可能也會重覆好幾次)
　　將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
　　A.對四個面向分別討論已知及未知項目
　　B.連結各面向關係，檢視彼此衝突
　　C.重覆A、B動作，直到沒有疑慮
　　D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
　　E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
　(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
　(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…

參考事項－需求分析
　需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。

1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。

2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。

3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。

4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…

從實務到理論-2

在上一篇文章中，雖然強調了「第一步，先將自己的實務理論化」，不過卻沒有明確指出「實務理論化」這件事情，在整個論述裏所佔有之地位。所以，本篇補述希望試著說明所提之論述之整體架構意象，讓大家能對這篇文章有更深入的了解。

先談談這份論述所希望表達的事項。這裏其實是先假設，「從理論到實務」是很重要的 (或是說，不斷的改革與創新是很重要的) ，而為了這個很重要的事，我們 (公司或是個人) ，真實面對理論實務化之執行時，對於所遇到之障礙、困擾，反省檢討策略之執行改進方向之際，應該可以從更深層的原點而反思。或是這麼說吧：「如果我們反省檢討時發現，相似的問題總是不斷被發現，而相似的解決方法也總是被當成策略結論，那麼，很有可能，這個問題是來自於更深層的關鍵原因」。

另外，在前一篇文章「從數學而上」裏，隱含著一種「危機與轉機」的意念，而這個意念背後，其所想要表達的，即在於「觀念轉換」的重要性與困難性。觀念轉換本身就是一個意味不明之表徵；要轉什麼? 要換什麼? 怎麼轉? 怎麼換? 上述幾個問號，對於我們這群以舊有的「行為取向主義」之教學方式所教出來的學生，要求重新反思原有先備知識的建構過程與動機，進而從中推尋出資訊鏈結關係之可行的不同架構模式 (創新與創意) ，這幾乎可以說是強人所難。所以，說台灣人創意不足，或是說台灣產業不願投資研發，唯一可以根治的方法，大概也只能期待 "十年樹木，百年樹人" 了。

當然，這樣想太悲觀，也許可以試著找尋其他的方法，來幫助我們思考「從危機到轉機的關鍵轉捩點」。什麼方法呢? 假設，關鍵轉捩點之所以不易被發覺，其實是因為這個轉捩點被隱藏在資訊與資訊的鏈結之中：從一個資訊單體演生轉化成為另一個資訊單體的鏈結過程，我稱為"知識跳躍" (也許也可以稱為"成見"，只是覺得單就"成見"二字的原意，似乎不足以表達) 。如果，假設，"知識跳躍"之問題的解決，可以改善"觀念轉換擁塞"之情形，那麼，希望，"實務理論化"，可以幫助思考與發現我們的"知識跳躍"問題，進而幫助改善我們創新思考不足的情形，從而幫助我們找尋「從危機到轉機的關鍵轉捩點」。至於，什麼是"知識跳躍"，建議可以從"建構式數學"裏去思考答案，如果有機會，再討論吧....

從實務到理論-1

只要有人類的生活，就會有問題的產生；只要有問題，就會有人思考如果解決問題。於是，當人們在思考問題之解決時，或是在尋找改進的方向時，最初最原始的開始，一定是從實務處理上，做抽絲剝繭的分析，將問題發生的進程，切割成為各自小的單元体，然後再逐一找尋問題發生所觸動之關鍵因子，從而尋求問題解決或改進之方法。事實上，對應在程式撰寫，當發現程式有問題，不也是用相類似的方法除蟲嗎!?

好了，當問題能夠獲致解決，接下來的思考方向便是「如何將這個問題的解決方法傳承下去」。在過去，智慧還不算是財產的時候，多數人大都是抱著藏私之心，守著祖傳祕方，等著後繼有。到了現代，情形當然是大有不同，可是，有關「如何傳承」這個基本的問題仍然存在。寫下來，大概是最快最有效的方法了。其實，打從人類有文字以來，用這個方法所傳承下來的過去的知識與經驗，在在與我們生活有著切合的相依性。打從我們開始學習，從小學開始，歷史、地理、國文、數學，都是文字傳承經驗的確切實例。所以，寫文件，很重要...(不過，我討厭寫文件)

再繼續衍生下去，當我們處理了傳承的問題，接下來遇到的就是「如何有效的傳承」。我們從「寫文件」這件事來思考 (假設寫文件真的是有益的) ，「如何寫一篇他人看得懂的文件」、「他人是否能依照文件內之描述來處理問題」、「他人是否能快速的從文章裏找到所需的解」。寫作文，我們講求「起承轉合」。之所以如此要求，是因為這樣子的效果，最能夠迎合人類接收訊息時的情緒轉化，使得訊息的傳達與吸收，能得到最高效率 (有關學習與教育的問題，在很多知識建構主義理論裏，可以找到論証，這裏先不細說) 。回過頭來，不討論作文怎麼寫，而來討論一份「資訊系統技術文件」，從我們現行的作業裏，就可以找到我們的解決之道「文件格式化」。我想，我們不需要在這裏多做說明，為什麼文件要有標準格式；為什麼文件規定要有某某章節...(雖然，我覺得，很煩!)

我們再回頭來看，在上一段的論述中，討論「如何有效的傳承」論點時，我們舉了例子「文件格式化」。在這個例子裏，其實就隱藏著本文的重點論述：「文件如何被格式化」，或是這麼說「如何決定文件要有哪些章節」。假設，我們是時代的先驅；假設，我們是全世界第一家資訊系統開發公司；假設，我們是第一群發現與思考「文件格式化」問題的人。我們該怎麼做? 分析實務進程，切割領域單元，釐清個體關係，然後為不同的單元個體命名，而這些單元體的名稱，就成了文件章節名稱的基礎。

理論必需搭配實務，我想，這句話，大家應該多能心有所感。理論研究的起始，本就是從實務而生，即便有些理論是架構在其他的理論上而演生，其最原始的基礎，依然在於實務。對現代社會而言，「實務理論化」本身就是一種專門學問的研究。通常、一般、大多數人，多是只知如何用，而不知為何可以用 (反過來，一般人在面對理論時，則容易有 "知道 Why，卻不知 How" 的感慨) 。記得以前求學時，好像曾經聽過這麼一個故事 (我不記得是從哪裏聽到的了) --當年，孫中山先生在倡導三民主義時，曾提倡「知難行易」說，因為當時很多人反應聽不懂三民主義，所以不知如何執行。國父舉了這麼一個例子：「大家都知道錢可以用，但很少人知道錢為何可以用」。當初聽到這個例子的時候，我還真的想了很久，思考著錢為何可以用。當然，後來是有想通為什麼，不過，在這個例子的後面，值得我們反思的問題在於，我們的實務作業上，是不是有很多情形，都是知 How，但不知 Why?

「理論必需搭配實務」，所可以反思的方向，即是「實務是否可以理論化」。當然，在上一段的論述裏說「實務理論化本身就是一種專門學問的研究」，這其實是社會分工精緻化的必然結果。所以，真的想把實務經驗化做理論論述，不是一件簡單的事。畢竟，實務情形總是複雜的，幾乎不可能 (絕對不可能) 用單一的理論構面架構而成。所以，一個「策略規劃」理論，可以有五、有九說，相不相信還可以有十三說、八百說....如前面所述，理論的研究可以說是實務的分解過程，至於這項理論的論述是否足夠完整，則取決於實務項目的採樣數與有效性。所以理論不可能完整表述實務過程，正因為如此，一個人的實務經驗，才會擁有超越書本、超越文件、超越理論研究的終極價值。 (終極價值：在人類被機器淘汰前，都應該不至抹滅的價值)

再一次強調，理論研究的目的，本就不是用來取代實務，而是為了提高知識傳承效率、降低學習門檻、加快進入實務的速度，所產生的實務改進方向指標，這個指標，才是理論存在的目的。什麼是理論，而什麼是實務? 就現代角度來看，理論研究應是學者、教授所處理之事務，而實務則被認為執行者所擔負的責任。這個論點，個人覺得並沒有錯。當我們思考「錢為何可用」的時，就應該會發現，分工的細緻化，是這個社會不斷演進的必然過程。只是，這樣子分工的結果，容易導至"好高騖遠"的理論對上"表面功夫"的實務情形，就是我們現在這個樣子!!

好了，不管我們同不同意上一段論述的結論，我們都應該可以、懂得省思自己。我們問自己，什麼樣的理論是會讓人可以實務的理論：答案應該很簡單，有實務經驗的人所提出的理論。反過，怎麼做可以做到理論實務化：第一步，先將自己的實務理論化。

後記：為何要思考「從實務到理論」
假設我們收到一個客戶提出的需求，希望我們幫忙改進客戶的資訊系統。接到這樣的需求訊息，第一步應該會先考量：是要修改原有系統，還是要重新建立新的系統!? (假設我們已經確定必需接受這個需求) 。做系統開發的人，應該多有感觸，有時候，重新建立一個系統，可能要比修改原有系統來的有效率。可惜，這樣子的情形，不大可能發生在組織身上。假設，今天組織要有所變革、組織要有所進步、組織要有所成長，直接把人換掉說不定是最有效的方法，卻也是最難以實現的方法。化做個人來看，成年人學習效率一般都不如年青人，其中的最大障礙，其實是在於「既有成見」。二十世紀以後，受到胡塞爾的現象學、海德洛的存在哲學、高達美的詮釋學等等的影嚮，產生了有別於以往實証主義學習法的「建構主義」論 (有興趣者，建議可先看看皮亞傑的認知建構論) 。「建構主義提出知識是由學習者所自行主動建構的，而非被動的由外界灌輸；知識是建構的歷程，並強調學生先前或先備知識的重要性，主張學習者學習時，應整理統合新的與舊有先備的知識。」 (以上文章取自「科技與學習--理論與實務」一書，心理出版社--沈中偉著)。 上述文章所提的先備知識，其實也就是既有成見的原始相貌，而新舊知識的統整能力，其實也就是一個人學習能力的指標。所以一個年紀愈大的人，擁有的先備知識愈豐富，其新舊知識的統合自然就必需花費更多的時間與精力。所以，很多老師在面對成人教學前，常會希望學員能拋棄成見，將心思放空，就是期望能減少新舊知識的統合所產生的摩擦，以增加學習效率。只是，以現在新的建構主義理論來看，這是不應該也不可能辦到的。這就像是公司要學習一個新的理論技術，要求公司放棄現有的執行模式一樣，乾脆另外開一家新公司算了....

從數學而上

1.為什麼要談這些

為什麼會想這些問題? 為什麼我會想要思考數學的問題? 進入資策會的這些年來，為了因應資訊的成長與變遷，總是不斷的在學習新的知識、新的技術、方法。然而，跟剛進資策會的頭幾年比起來，最近幾年自己個人的學習成長，似乎出現了某種障礙與瓶頸。自己很無聊的去做了一些分析，發現，我個人所習慣的學習方法，是希望有人能給我範例，或是直接告訴我怎麼做，然後我再從中習得能力與經驗；如果是遇到不知該怎麼做的理論知識 (沒有適合的範例，沒人確切了解怎麼做)，會變得很難將其吸收成為屬於自己的知識並轉化成實作。於是，對於學習本身，漸漸變得不再有興趣；對學習的成果，也不再擁有成就感。學習，似乎只剩下應付，應付長官、應付客戶、應付績效。為何會變成這樣呢? 有什麼地方是不一樣呢? 是不是有很多人都有類似的情形呢?


2.我們的習慣、思考邏輯、學習文化

(1).為什麼談學習文化

所謂文化，指一群人，因為有著相同的語言，在時間的累積下，產生了相類似的生活方式、溝通與表達方式以及相同的願景等等… (2007/04 - 傳佩榮教授說：文化分三個層次：器物、制度、理念). 這一群人，對於碰到某個問題，可能會有著相類似的思考邏輯與解決策略；當要學習某項新知，可能會有著相類似的學習方法；當被要求執一個任務，可能也會有相類似的苦惱 – 希望有人告訴我怎麼做，或是希望有人能給我範例…

(2).為什麼談數學

數學是科學的基礎。對於如何解決一個數學問題所採行的思考方式，其實會反應在當面對生活問題時，所思考的解決策略方向上；而對於數學的學習與應用方法，也容易反應在一個人對於新知識的學習與應用方法上。所以，當我開始往回推，回頭思考我所受的基礎教育對我現在的影響時，我想到了數學。

(3).數學邏輯的差異：加法邏輯與減法邏輯

當我開始回頭思考我所接受的數學教育時，正好也看到了日前吵的火熱的「建構式數學」(也有人戲稱「賤狗式數學」)，因而也開始小小研究一下，這與我以前接受的傳統數學，有何不同。是的，的確是有所不同，而且，也許這就是我想找的答案。我發現，我是贊同建構式數學的，就像我其實贊同CMMI一樣 (我只是不贊同執行方法)。

建構式數學與傳統數學，其實有著基本的邏輯思考差異，這裏只先做簡單區分與說明：

A.加法邏輯 – 建構式數學
把東西一個一個加起來，然後得到結果。
例如：假設一隻筆賣8元，那麼付出8個一元就可以得到結果。

B.減法邏輯 – 傳統數學
把多餘的東西減掉，就可以得到結果。
例如：假設一隻筆賣8元，那麼只要付一個十元，找回兩元即可。
(減法邏輯數學用得最極致的，大概就是菜市場賣菜的歐巴桑，算數之快，真的令人咋舌)

(4).什麼是建構式數學

以下是轉載他人的文章====================================

「建構式數學」是根據國外的教育思潮「建構理論」研發而成，主要教學步驟為「佈題、解題、溝通」，教師的角色由教學活動的控制者，轉變為教學活動的協助者。教師的任務只在於協助學生建構自己的數學概念，並讓學生將建構過程紀錄下來，以培養學生和他人溝通及自我學習、反思的能力。主要有下列五個重點：

A.建構式數學主張讓學生自行解題，再適時引入數學語言做為概念的表徵。

B.鼓勵能容忍異己、欣賞別人。

C.養成主動探索問題、尋求解答的習慣。

D.隨著學生概念的發展，學生的智力及記憶也會有所成長。

E.教師可採用各式各樣的多元評量方式，不再只限於紙筆式評量。


建構式數學的基石在哲學思想層次上是很傳統的，並不是很新穎，至少在古希臘或更早就應該存在，雖然那時的人們可能沒有用這一個名詞。歐基里得的幾何學本身就呈現這種想法。就數學而言，在數學上面冠上「建構式」三個字是完全沒有實質的意義，因為所有的數學都是建構出來的。但把這個思想從哲學層次落到基礎數學教育的實踐，是比較最近的事情。它是強調，小孩建構數學的程序是他能學習且最重要的唯一面象，反對（至少不贊成）教師作價值判斷的引導。因此，對採行建構式數學的教師而言，如何在建構式數學的教學方式下，引導學生由自創式的計算歸結到直式計算規則，而又不會讓學生在學習上引起認知的混亂，這對老師是非常大的挑戰。顯然地，要全面採用建構式教學，至少須要具備底下的因素：

A.數學課程上課時數要多，遠比現有的上課節數要多的多。否則，教師只能在最簡單，最基本的算術規則或生活情境（學生較有具體經驗的那一部份的數學）作大量的建構後，只能花很少的時間去教導學生，較不熟悉或較困難的部份。

B.教學的班級不宜過大。

C.對教師在數學、其它相關連的學科素養（例如科學）以及教師的敬業精神有很高的要求。

End ====================================

這裏小小插播一下，「PSP」課程 (Personal Software Process) 的流程設計，其實就有點接近建構式數學 - 要求自主的反省思考，儘量不提供絕對的答案；每一個習題，都是希望學生能思考下一階段的進步。可是，在上這個課程時，發現自己還是習慣要求要有標準答案；而且，我也發現，可能就是自己的思考習慣不好，所以對一個習題結束後應該引發的反思，往往會花掉比撰寫程式還要長的時間，最後更會因為課程時間壓力，而放棄掉這段反省。在這裏提出小小建議，希望以後開PSP課程，能再縮減一半人數，讓教師能更容易去引導個別學生的思考方向，並且將課程時間再增加兩倍，讓上課的學生有多兩倍的時間來思考問題，這樣應該才能達到應有的效果。


3.不同思考邏輯的優缺點

(1).加法邏輯的優缺點

加法邏輯其實是在組合因子、元素，像堆積木一樣，把一堆稱為「理論」的積木，堆疊組合，然後成為某種結果。這種做法的優點其實就在於創意，因為建構的重點在於堆疊方法的思考過程，而不在於結果，所以允許不同的人，用不同的方式，組合出不同的樣子；其實這就是創意的來源。而這個方法的缺點，就是「慢」。因為要花時間思考堆疊的方法；而且，雖說要「容忍異己、欣賞別人」，可是其實有很多堆疊出來的結果不是我們想要的(也有可能是錯的)。這時候就必須多花時間，將這些不同的思考方向與結果，引導到正確的結果(或直接放棄??)。就如上述文章所說，教建構式數學的老師要多花很多的時間去引導學生。
有去過美國或歐洲的人，可能會發現，他們的店員算數速度很慢；經常在購物結帳時，花很多時間在算錢。其實，我們可以猜測，這些算數速度很慢的人，通常可能是邏輯能力比較差的人。所以這些人可能沒有能力 (或興趣) 去推導創立自己的算式，所以只好死抱著自己會的那一個算式，這樣至少可以得到正確的結果 (反正，錢的計算結果應該是固定的，不會因算式不同而有不同的結果)。

(2).減法邏輯的優缺點

減法邏輯其實就是在分解因子、原素，把人家已經做好的某個成品，拿來一塊一塊解開，然後再依樣畫葫蘆組起來。明白的講，其實這就是一種模仿能力，這也可以說明，為何台灣會是個「極厲害的仿冒大國」(現在好像要被中國大陸追過去了!?)。
減法邏輯的優點其實就是「快」。因為只要分解、找出某種既訂的流程，然後再循著這些既訂的流程(例如九九乘法表)，就可得到標準的答案。這也是為什麼我們的數學運算速度，普遍比歐美人士快得多。
這裏需說明一下，加法邏輯所用來組合的「因子」與減法邏輯所拆解出來的因子，其實是有可能不一樣的。而且，對於使用減法邏輯思考的人，因為已經知道結果為何，所以拆解的時候，通常也會思考更有效率的組合因子的方法，進而提昇效益。
事實上，使用減法邏輯思考的人，並非都沒有創意，只是相對而言比較少而已。然而，這也正是減法邏輯的缺點，也正是台灣人比較沒有創意的主因，其實也是目前的教改需要建構式數學的緣由。因為，我們的經濟已漸接近已開發國家的程度，我們已經沒有東西可以模仿了，我們的未來的經濟，如果不能創新、創意出自己的產品來，就有可能等著被淘汰，所以，我們急著使用建構式數學。
我們可以這麼說，理想中的建構式數學，是希望不要直接告訴學生有一個好方法(乘法)可以執行更快的加法運算，而是希望讓學生自己去找出更快的運算解法，進而產生屬於自己的乘法運算；並不是單純的禁止學生背九九乘法表，而是希望引導學生去推導、創造出自己的九九乘法表。而這種創造的力量，才是我們現在想要的。

(3).台灣式的建構式數學

之前說過，我個人是贊同建構式數學的，只是不贊同我們的執行方法。因為我們現有的政策執行評估、政策決策、以及直接執行教學工作的老師們，其實都是傳統數學下的產物。正如之前所說，要實施建構式數學，是要有條件的，而我們其實遠遠達不到這些條件。所以，沒辦法，我們還是用著以前的方法，以前的出題方式 (題目本身有變的比較生活，但出題目的方式與目標卻仍與過去相同)，以前的改考卷的方法硬著頭皮在執行。所以，我們依然習慣著要求標準答案 (很悲哀的，有標準答案，相對也比較公平；畢竟沒有標準答案的題目是很難打分數的)，所以當我們出一個題目「一隻筆5元，三筆共多少錢?」，而學生的答案寫著「5+5+5=3」時，這才是對的，如果寫成「3x5=15」就是錯的，因為，這才是標準答案。也因為如此，台灣的建構式數學，一點也不建構。這也無外乎會有許多家長及教育人士要求將數學改回來。

4.依我們分析的優缺點反思過往

(1).過往回憶

在剛進資策會的前幾年，很努力的學了不少知識技術，而且每次學到新的東西，就會想要立刻實際運用在實作上，當看到自己寫的程式在 Run 時，真的很有成就感。回想起來，那一段時間所學的東西，如 C++、Java、PHP、ASP、VB等程式語言，雖然有些是新的程式語言，但其實基本邏輯都很相似。相信一定有人認同，只要能對某個程式語言很專精，要學其他的程式語言其實都很快。另外，在學這些程式語言技術時，很容易可以在很多不同的地方找到許多範例，包括自己專案裏的資深同仁，就有很多範例可依循。話說回來，因為氣象專案過去多使用結構化分析法，比較沒有物件導向經驗，所以在學物件導向技術時，成效與成長就明顯比較慢。
不論如何，一開始的幾年，學習對我而言，是段很快樂的時光，也很有成就感。然而，最近的幾年，所學習的東西，已不在如之前那樣有效果。像是「品質流程」、像是「系統架構」、像是「風險評估」、像是「度量分析」、像是RUP、XP、UML有的沒的等等….這些東西相對起來都比較新，都是程式語言發展到某一種程度後，對於系統開發時會發生的問題所思考的解決策略，所以，這些東西，沒有什麼範例，也沒有什麼人知道怎麼做 (資工所還是台灣CMMI第一呢!!)。於是，我的思考邏輯出現了障礙，學習的樂趣漸漸消失。面對眼前一堆的積木，我唯一可以做的，似乎就是硬著頭皮去把這些積木堆起來 (我們組織現在好像就是這種感覺)。
如果，真的只是「硬著頭皮堆積木」，其實也未有不可，如果我們能夠「鼓勵能容忍異己、欣賞別人」，然後再花時間引導我們去歸結出屬於我們的答案，這樣其實是很好，而且很有創意也很有成就。可惜，很可惜，我們什麼都有 (有最多的東西叫「努力」)，就是沒有時間。所以，當我努力堆疊組合出成果時，面對的卻是來自各方反對的聲音：這裏不對、那裏不好、應該要這樣才對、我們要的不是這樣….長官的、客戶的、其他同事的….怎麼辦? 驗收壓力在即，只好硬塞。硬是擠成大家想要的標準答案，把多餘的角角砍掉，裏面有些空隙也不管了 (看不到就好)，也許還有些積木沒有能堆上去，管他的，放棄吧，當做沒看到 (以系統開發流程來看，這些被放棄的積木，通常會是「測試」，因為他在最後面)。為了績效、為了驗收，交差了事成了最後不得以的指標….~>_<~。
當然，有了一次的堆疊經驗，其實下次應該會堆的更快更好，所以，一次的失敗，沒什麼好難過的，對吧!!!! 不對，大錯特錯，因為資訊進步的速度很快、非常快、實在太快了。原以為我今年堆積木的經驗可以讓我明年堆的更順手一些 (空隙較少、要削掉的地方也較少、還可以放一兩塊「測試」的積木上去)；很可惜，到了隔年，積木變了；有一些的形狀改了，有一些被取消了，還有一些新增加的，更糟的是，最後要組出來的成品形狀也換了。我的天呀….~~~~~~>_<~~~~~~ !!

(2).CMMI

之前說過，其實我是贊同CMMI，就像贊同建構式數學一樣 (目前看來，我們的CMMI跑的跟建構式數學似乎很像，只是CMMI沒有家長會罵)。我，後天的思考邏輯缺陷，造成我在學習、實作CMMI流程時，有著更多的問題與無力感；發現，依我的現有的思考邏輯方式，到要能好好實作CMMI，應該必需比習慣「加法邏輯」的人多付出兩倍的時間才行。也就是說，如果歐美國家，從CMMI LV2到CMMI LV3 要3年，那麼，我們應該要6年才合理。我覺得我們必須多花一倍的時間，去調整我們原有的思考邏輯方式，才能真的達到我們想要的結果。想到這裏，原來很有興趣想看看「凌群」是怎麼通過CMMI LV3的，現在卻有種強烈的感覺，應該可能也只是會看到一個被砍削過的積木堆而已。
個人是這樣覺得的，我們的CMMI LV3是個硬塞出來的結果，這個積木堆裏有不少空隙，有些積木則被削過、砍過，當然，有些積木則被暗暗藏了起來，不讓別人看到 (尤其是稽核員)，我們呈現了一個標準答案，我們通過了CMMI。當LV3通過的時候，我記得我們的資工所PQA說了一句很有趣的話：「我沒想到我們的工程師這麼會說話」。這裏想反駁一下，其實，這就是我們的強項：找出標準答案，背的滾瓜爛熟，然後漂亮的通過考試；我們不是很會說話，我們只是很習慣背答案!!
講到這，突然對2006年通過CMMI LV5深具信心，真的。因為，到了考試前夕，我們應該有辦法找出標準答案、列出題庫，然後讓我們的工程師背的滾瓜爛熟，再一次讓稽核員訝異的發現，我們的工程師很會說話，然後再一次漂亮的通過CMMI LV5。帥吧、漂亮吧、台灣就是醬厲害。

(3).未來

沒有未來….這樣說也許太悲觀了。我的父親現在在大陸工作，因為他們的工廠應美商要求，整個搬到了大陸。也應美商要求，最近剛通過ISO 9002。很好玩，跟我們很像，也許真的是中國人的天性 -- 把文件做的漂亮漂亮，然後就通過了….不過，大陸有些學校也開始實施「建構式數學」了，只是，他們不像我們一下子全面實施，他們將資源集中投入，將所有的專家都丟到幾個學校去，而且不准家長抗議。當然，這樣不一定好，因為資源的集中，很容易就有不公平產生，會有很多地方相對沒有足夠資源從事教育。而且，這一批「建構式數學」白老鼠，在目前的考試制度下，也很難與其他傳統教學下的學生競爭。但，反正人家專制；雖然犧牲了一些人的利益，但也相對的造就了未來的希望。然後呢，台灣只好「順水推舟」、「水到渠成」的被邊緣化了….
其實，我們也是有未來，只要大陸方面因為經濟的起飛造成政治的民主改革 (只要變得民主，就會變得難以集中資源，就會出現像我們這樣的問題)，我們就還有希望。我們只要能好好利用我們的優勢(做文件、背答案)，領先佔據市場的有利位置，將落後的敵人排擠開外。接下來，我們可以等我們的「建構式數學」白老鼠長大成人，進入工作領域，然後真的開始創立屬於我們自己的創意，開創出屬於我們特有的未來….