Kenming’s 鮮思維

在職場上，好多人看起來都好忙，可是，我又發現到，好多人也不知道在忙什麼。為什麼會很忙，因為大部分的工作者，會同時被交付好多件工作，卻又不容易分辨，工作的優先順序，與輕重緩急，所以很容易把事情處理得很複雜，當然就會非常忙碌了。

但是，真的是當你能對工作作很有效率的優先順序分類後，你就不會忙了嗎？ 我是覺得，非常懷疑！！

對於時間管理的範疇，我一直不以為然的是，許多人會以為採取了某些號稱高效率的方法時，就可以提昇工作效率，這就如同，你以為提升如記憶訓練後，你的學習能力就會提升。

從方法、工具來提升效率與能力，這根本是本末倒置，見樹而不見林的。你要問我，那到底什麼是根本，答案真的很簡單，完全都是 取決於個人的心態。

就先以學習為例好了，許多軟體人員，對於看軟體設計書籍(尤其原文)普遍存在排斥與恐懼，覺得這些書籍是屬於專業技術的書籍。每次我面臨有人問我如何有技巧地看這些書籍時，我總是反問，對於看漫畫、武俠小說等，你會煩惱這些問題嗎？ 沒有啊，看這些是很輕鬆、愉快啊，甚至要你熬夜把一本愛情或科幻小說一口氣看完，也沒問題啊！ 那麼，看軟體設計書籍，為何你要先擔心看的懂或不懂，為什麼你無法把這些軟體設計書籍看成是看漫畫那樣地輕鬆以對呢？ 有那麼難嗎？
(對於技術性書籍，內容若我看不懂，我總會有最好的 『藉口』 ，那是作者寫得爛，不是我看不懂。)

還有呢，到底如何定義什麼叫做「看完一本書」？對我而言，我只要把書的封面看過，而就能從封面，延伸關連相關的主題，口述表達三個鐘頭以上，那我就認為，這就算看完一本書。嘿，甚至連大綱、序文都不用看，我仍認為，這也算看完一本書。

所以呢，這根本是無關聰明才智的，這純粹是與心態有關的。若心態一直是依循傳統的價值觀，那麼，很容易會被受限、會被束縛，因此而會產生恐懼、沒有自信心的。

同樣的道理，當回頭檢視工作時，為什麼你會覺得工作很多？ 這仍然是心態上的問題．．．

因為，現實的工作環境，上司就是給你這麼多、客戶所交付的時程又是那麼短、人手又不夠．．．
我常聽到的理由是這些，你要問我換成是你，要如何解決這樣的問題？答案是，我根本也不能解決啊。
但是，我根本就不可能是那麼忙碌的你，因為，一開始，我就不會去找忙碌不合理的工作啊。

其實呢，根本關鍵是，我並不是從眼前的工作來決定我該如何做事，眼前的工作僅是過程。正確地說，當我決定好 5~10 年的中、長期目標與個人的價值觀後，我才會衡量眼前工作是否能與我的目標與價值觀契合，若不能配合，那麼，你為何要待在這樣的工作環境？ 因為要生活？ 那麼，你為何不換個適合你的工作？ 找不到？ 那麼，你為何不充實與提升你個人的價值，甚至，創造屬於你自己的環境？

好吧，因為有太多現實的理由，不得不讓你待在現在的工作環境中，那麼，停止對工作的抱怨，試著從其它地方找到回饋。那裡呢？ 學習找到對工作的熱情；或者提昇自我價值，而能換取更多實質的報酬。還有一種比較消極的方法，就是，有技巧地推掉多餘的工作。嗯，我看過幾個科技國防役，很聰明，很會躲工作，卻又能看起來表現得不錯，嘿，評價比較獲得主管肯定的，反而是這些不忙的人。 :p

許多人都會煩惱現在所處公司在工作上的不愉快，覺得與理想悖離。我蠻奇怪怎麼有那麼多人抱怨工作的不愉快？ 怎麼會認為公司有責任要負責你個人的理想？ 反過來說，你應該早要認清，個人的理想，不會是與公司的經營劃上等號的。真要有理念符合的，那可真的要感謝，如此幸運可以與許多理想志同道合的工作夥伴。這樣的話，更不會有工作繁忙這樣的問題了。

一直強調的是，現實的工作都僅是過程，過程是為了讓你更能接近你所設定的目標；過程的甘苦，都還是過程；過程不順，充其量就只是個小石頭絆住你而已，實在沒有必要為過程以及工作上的細節太過煩惱的。

許多朋友看了「棋靈王」漫畫與卡通後，不會下圍棋的，也逐漸對圍棋神秘奧妙的黑白世界，開始感到興趣。不過，圍棋是一門非常奇特的領域，若在小孩子的階段(尤其是 10 歲前)，沒有學圍棋的話，任你如何的聰明才智，幾乎(可說是沒有例外)無法成為一流的國手。

不過，圍棋的規則卻是非常簡單，瞭解規則，大約不需要半個小時，若只是想沈浸在對奕的樂趣中，學習圍棋是很輕鬆愉快的。

我是在五專時期就已經深深著迷於圍棋的黑白世界裡，到現在為止，我的圍棋書大約有 ２００ 餘本，可謂不少，當然，花在圍棋書的錢，算算就知道了，也不少錢了。現在我的棋力約業餘 3~4 段，當然，未來的目標是蠻希望能成長至業餘六段，所以一有空閒，我仍然會研究圍棋與打譜。

當然，我只是把圍棋當作是業餘的嗜好，不過，學了圍棋，你總會希望棋力能長進，棋力成長的過程，在贏了你經常下不贏的宿敵後，那是最大的喜悅與成就感。

圍棋與軟體一樣，是最重視蹲馬步的基本功，佈局、中盤、官子、死活、定式與打名家的棋譜，是增進棋力的不二法門。在以前，你當然只能透過圍棋書籍，就如同我一樣，買了 200 多本，才能有各種專題的討論。現在呢，有更形各色的圍棋學習軟體，幾乎可以取代書本，甚至，提供的內容，在質與量上，更是數十倍於書本。

為什麼呢？因為，圍棋的電子棋譜與各種的練習題，都是被儲存於國際標準的規格，稱為 SGF (Smart Go Format)，其實也只是一般的文字檔，可以說就如 XML 格式一般的方便、高可攜性。

我這裡是要推薦一套大陸朋友所寫的棋譜打譜與管理軟體，稱為「圍棋助手(Go-assistant)」。

這套軟體實在有夠優秀，作者非常有心，不僅圍棋的打譜功能完善、支援簡體、繁體的顯示(即使棋譜是簡體，你也不需轉檔，該軟體自動幫你轉成繁體)外，最重要的，內建的棋譜資料庫，實在是不可思議．．．的多～ 88|

內建棋譜的資料庫分為兩大部分，一為棋譜庫；另一為教程庫。

棋譜資料庫收錄的對局，包括古、今名人們的對局及其解說，有 45,000 局之多；而教程資料庫，這是大陸的用語，其實就是教學資料庫，包括佈局、中盤、官子、死活、定式、手筋 …等，其教學的部分的詳解，也有 6,800 局之多。

太完整、太完美了！ 隨時你也可以加入你自己的對戰譜或是個人收錄整理的棋譜至該資料庫內，事實上，圍棋助手的首頁上，也常有網友們踴躍上傳整理的棋譜，只要下載回來，加入資料庫即可。

這麼棒的打譜與棋譜管理軟體，註冊費才收約新台幣 $700~800(我忘了多少)，內附的教學與棋譜，就已經遠遠超過我多年來所購買的 200 多本圍棋書的內容了。

作者很大方，你可以先下載回來安裝試用，然後將安裝後的序列號複製再 Email 給作者，作者即會先給你註冊碼，你再匯款過去。我還第一次看到有採取如此信任制的方式來註冊的。

我很早(應該超過 3 年了)就已經註冊該軟體了，不過註冊碼早已不見，連註冊資訊也沒有備存，但我寫封信請作者順帶查查是否有我的註冊資訊(其實，我並沒有指望，只想問該如何匯款而已)，沒想到，還真有我的註冊資訊，雖然過了這麼多年，仍然免費無條件寄送給我註冊檔。

對於優秀的軟體，作者又如此的大方，特此強烈推薦想學圍棋或是希望能更增長棋力的棋友們，應該購買。對作者是一種支持、鼓勵，對自己又能從其中得到學習圍棋的樂趣(對了，圍棋助手還可以透過網路雙人對奕)，僅花個吃一餐牛排的費用，何樂而不為～

圍棋助手的首頁： http://www.go-assistant.com/

POC, Proof of Concepts, 從字面的意義來解釋的話，即為 『概念性的驗證』。

既然是需要驗證(Proof)，所以 POC 是一種 『解決方案(Solution)』，是針對 『概念』 所提出的解決方案，而架構的 POC，目的即在於擷取出最精要、核心的解決方案(Solution)，以作為解釋架構的概念依據。

我與 Ringle 聊到 POC，他原來對 POC 的認知是對客戶所提出的一種解決方案，所以主要滿足對象是 『客戶』。不過，對於架構的 POC，我不太認同對象是客戶，我會以為，會希望能透過某種概念性的解決方案，而對架構有整體、全貌性的認知者，那才會是架構 POC 的對象。

所以，誰負責撰寫架構 POC？ 我認為是 『架構師(Architect)』，誰想瞭解及驗證架構 POC？我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後，再來是瞭解其呈現的具體樣貌是什麼樣子呢？底下是架構 POC 具化的幾個可能樣貌。

• 解決方案所需運用的相關技術(Framework, Pattern …)。
• 利用 UML 語法建構概念模型草圖(Sketch)，以表達某一解決方案。
• 利用模擬(Simulation)的方式提出解決方案。
• 可以被執行的原型 (Prototype)。

我個人傾向利用可以執行的原型(Prototype)來作為架構 POC 的具體樣貌，因為：

• 架構師以 『原型』 做為與開發團隊與利益關係人的溝通、達成共識的橋樑，然後才著手執行。透過原型，大家比較容易對概念(Concept)產生共鳴，並致力改變尚未成形的東西。
• 原型協助架構(Architecture)的建立，讓大家能容易看到整體、更具宏觀的角度來看待複雜系統。並因此而避免一頭就栽進種種的細節(Detail)。
• 原型可把目標清晰地描繪出來，並且讓每個利益關係人(Stakeholder)都更容易提供意見，進行改革。

而且，架構原型可以：

• 在架構落實以前，讓團隊成員能自由表達看法，並進行討論、提出建議。
• 讓團隊成員隨時表達意見，有機會影響你正著手進行的方案。
• 不斷加快前述兩個步驟(一般稱之為「快速建構原型」)。

對了，架構原型除了比較容易協助團隊成員一窺系統的整體全貌外，對系統內部的結構(Structure)分析與設計的呈現，也能有一番基本的認知。

所以，架構原型的內容，我會擺上表達整體系統的使用案例模型；實做兩、三個具代表性的使用案例，並畫上概念性的類別圖與循序圖；同時，我還會加上與 .NET or J2EE 等平台相依的細部類別與循序圖；實做面，確實可以產出可以執行的程式碼與測試碼；最後，我會利用簡單的 UI(User Interface) 作為執行畫面的呈現與說明。

原型，並非是 『粗糙』，或是 『應付性』 的，它是一個框，是可以被驗證的，但並非僅利用外表美美的圖形使用者介面來對系統作概念性的驗證。架構原型，反而不是重視圖形介面，它要強調的是一種對系統的整體觀與結構觀。至於圖形介面與企業流程的功能，反而不是那麼重視。精密與細節、正確性的工作，是對系統的整體有了正知與正覺，往正確的大方向走後，才確定要做的細節性工作，可以把它作對。人們，尤其是組織性的團隊，最常犯的錯誤是：「把不必要的事情作太好」。

本星期六(11/26)所舉辦的 9th_UML系列講座，簡報教材已做成 pdf 格式提供下載，歡迎下載參考(參加本次講座的學員煩請自行列印教材，本次講座因報名人數眾多，不克列印書面教材，僅提供電子光碟檔)。

請至：http://www.hsdc.com.tw 【檔案下載區】下載檔案(.rar 壓縮,pdf格式)。

*** 若不刻前來欲索取講座光碟者，請參考： ***
http://www.hsdc.com.tw/modules/tinycontent/index.php?id=6

講座時間：2005/11/26 (星期六) PM13:10 ~ PM 17:00 (3.5小時的講座時間，並留半小時供學員提問)

講座地點：台北市建國南路二段 231 號(和平東路口) / 文化大學教育推廣部

P.S. 請加入 HSDc 網站會員後始可有權限下載(註冊會員程序不到 30 秒即可完成註冊)。

本次的教材內容 ．．．

1. Hibernate 3 極限運動 -Part II — 101 軍曹 林志浩 (Tommy Lin)
　• (35%) OO Modeling Workshop
　• (65%) Make Your Fine-Grained OO Model Come True By Hibernate

2. 寫一份有效的 SAD 文件 — 王克明(Kenming Wang)
　• SAD, 軟體架構文件的內涵。
　• 藉由 RUP「4+1 View」架構，說明開發者的角色與產出。
　• 關於架構 POC(Proof of Concept) 的意涵與內容。
　• SAD 的樣版(Template)與簡單範例。

P.S. 本次 SAD 附件內，含完整架構原型(Prototype)的設計文件與可執行程式碼，包括了–

• 住院出院管理系統
  • UML Diagrams and E-R Model
• .NET 完整可執行程式碼
  • Code List and 執行畫面

前幾日，接到 iThome 技術編輯的 Email，希望能與我們 HSDc. 團隊針對專案管理，尤以開發工具的應用上，如何從軟體開發過程省視整個ALM(Application Lifecycle Management)，並探討開發人員/團隊如何應用相關工具以實現ALM的議題上，來接受採訪。

這樣的主題，我是特別有興趣的，所以今日與該技術編輯約在中和四號公園旁的「咖啡因」，我是最喜歡邊喝咖啡、邊暢談相關軟體相關的議題。

因為 Ringle 也剛從埃及度蜜月回來，也順道一同邀他一起來參加。該位技術編輯姓張，還是清華大學物理研究所畢業，呼，學歷高，談吐應對也彬彬有禮，不過我一直是蠻好奇的，學物理又是如此的高材生，捨物理的研究而就 IT 產業的技術編輯，還真不知道這樣的選擇是好或不好？

與該技術編輯的訪談中，我發現到，嗯，他似乎也被軟體業界的許多 『現象』 給迷惑住了，他一直以為會有所謂的 『聖盃』，(我是稱之為銀彈，Silver bullet)，可以協助以及簡化專案開發與管理上的許多 『痛』。

嘿，我總覺得，有些道理，再簡單明顯不過，但是，為何在軟體業界內，總是會存在如此這麼多的 『茫點』？ 怎麼會有人相信有 『聖盃』 ？

經營者及管理階層總想靠所謂的 『制度』、』規範』 以及 『好用』 的工具來 『圈住』 開發人員，這樣的模式在硬體代工產業是行得通，為什麼？道理很簡單，硬體代工產業下的 『Worker』 可以忍受不合理的工時與不愉快的環境，因為最起碼，他確實享受到如配股、年終分紅的高所得待遇。

但是，軟體公司，當你走向 『制度化』 的管理模式後，』個人』 的特質是越來越被淡化，而講究的是整體團隊的 『產能』。我可要特別強調，是 『產能』，而非 『團隊知識』。從經營者與管理階層的角度來看，這是最樂見其成的。但是，從 『Worker』 的角度來看時，當你的工作只是持續作重覆性的工作，而沒有成就感時，你需要另外一個回饋，也就是，實質高所得的待遇。 而根本事實是，國內軟體開發人員的薪資普遍不高，多數軟體公司甚至視加班是合理的常態，卻很少看到哪家公司有支付加班費的。

就整個採訪的過程中，我經常就類似這樣業界普遍常見的 『現象』 來反問該技術編輯(他似乎有擔任過軟體開發相關的角色)。有趣的是，我發現到，後來反而我問他的多，他問我的少，還真不知是誰採訪誰了。;D

基本結論是，若不回歸到 『人本』 的開發團隊，而去外求制度、流程與工具，我一直認為那是 『本末倒置』，絕對無法解決複雜本質的根本性問題。

有趣的是，幾乎每家軟體公司的經營管理階層都會說：我們是很重視、照顧人才的。

嗯，只要問問看實際擔任開發職人員兩個最基本、單純的問題就好了：

1. 你對你的工作有沒有成就感？
2. 你領的薪水是否滿意？

只要能滿足以上其中一個條件就好了，這樣的話，建議你，請繼續待在現在的環境，這並不容易找得到的

P.S
其實，訪談了好幾個小時，其中有些更細節性與敏感機密性的話題，就不方便提出來。不過，我可是認同好的相關專案開發工具與製程，確實是可以協助 80% 重覆性的工作。但是，剩下的 20%，才是影響專案成敗的主要因素。那是屬於抽象、創意性的軟體設計範疇，絕對是工具或方法論所無法取代的。

我們家蓁妮，連續第三年代表育才國小四年級組參加資訊月電腦繪圖囉。;)

這次的主題是「海洋樂園表演秀」，看到我們蓁妮利用小畫家畫出來的作品，應該是以今年初我們至花蓮海洋公園參觀的海獅表演秀為藍本，用色很豐富，人物的表情、與海獅的樣子，端的是生動活潑。

前兩年，我們蓁妮的作品均得到優等獎，今年，看看是否能更再上一層樓，取得前三名的佳績囉～

ˇ 蓁妮的 93 年度(三年級)資訊月電腦繪圖作品：「二十四孝」。

ˇ 蓁妮的 92 年度(二年級) 資訊月電腦繪圖作品：「可愛的貓咪」。

*P.S. 後記*
這次我們家蓁妮又得到全國資訊月電腦繪圖的優選獎，雖然仍沒有進入前三名，但仍蠻感欣慰的。 :p
http://www.infomonth.com/kid/showCaseCP.asp?wid=CP4001&kind=4