.NET Walker

  有時候在客戶端做顧問服務，也會有意想不到的事情發生。 先衝進來的是個二十多歲的工程師，臉上的表情忿忿不平。接著走進辦公室的是年紀稍長的專案經理，從服裝可以看的出來他的個性比較沉穩。   兩人似乎沒注意到我正在和這家公司的老總(其實也是我朋友)開會，年輕工程師迫不及待的發言，接著是專案經理的辯解。 由於事出突然，老總也沒把我當外人，示意員工可以把話講完，我也就在一旁稍微聽了一陣子。爭論的內容其實稀鬆平常，專案管理中的一些需求與規格上的認知差異。但雙方你來我往，談著談著議題升級到了彼此的誠信問題，接著各種往事舊帳出爐...讓我頗為訝異的部分是，才幾分鐘的時間，雙方可以如數家珍般的，把兩人之間的恩怨情仇迅速的陳述了一輪，彷彿是在進辦公室前早已經在心裡默背好了的講稿一般，可見積怨之深... 我在旁聽了一陣子，覺得其實也沒什麼大問題，雙方的論述都有道理。而且事情發展到最後，純粹只是立場不同的差異而已。倘若是換了角色，估計彼此都能夠理解對方的做法。但麻煩的是，討論到了後面全然是意氣之爭，大家言談中似乎早已經不在乎最終的結論是什麼了，而是執著於想爭出個『對錯』，工程師覺得專案經理總是頻繁的調整工作優先順序，開會時常常推翻了上周會議中才做出的決議。專案經理則覺得自己只是反映用戶端真實碰到的問題和需求，反過來指責工程師沒能設身處地為用戶著想... 聽起來似乎先前已經為了這些問題爭論非常多次，也耗費了不少的時間。既然立場不同，也談不下去，只好跑來這裡想得到一個仲裁。 我看了老總一眼，心想他怎麼會有精神去管這種瑣事? 果不其然，他耐心聽完之後，拿我當藉口，讓兩位員工先出去，說是等和我開完會之後，再來協助解決這個爭議。 我看著兩位員工步出辦公室，問他：『你打算怎麼解決?』他笑著說：『解決? 不，那才不是我該做的事。』說著， 一邊拿起電話，看起來是撥給那個專案經理。 只聽到他跟電話的另一端說：『Eric，你年紀比較大，Samuel是你的team member，你們合作這個案子也有半年了吧。』等對方應完話，他繼續說到：『我不會介入這個問題，我希望你去解決，我只給你一句話......』頓了頓之後，他說：『小朋友愛計較是非對錯，成年人則看重利弊得失。』『你身為PM，本來就必須周旋在客戶與內部團隊之間。試著成為橋梁，而不是變成問題的一部分。至於中間的分寸，得靠自己拿捏。』說完之...

人有見識、就不輕易發怒．寬恕人的過失、便是自己的榮耀( 箴言 19:11 ) 周末，去參加中學的同學會，結束之後大夥兒散場，因為老同學住在家裡附近，理所當然的搭他的順風車回去。就在準備上交流道的路口，後方一台B開頭的名車或許不耐等候，開始閃燈喇叭齊鳴。 我看到老同學瞥了後照鏡一眼，手反打入了低速檔，我立即把剛才忘了繫的安全帶扣好，心想接下來可要精彩了。要知道當年這位同學，可是率領我們一票人夜騎九拐十八彎的領頭狼，後來買了幾台名車之後，國道競速也時有所聞，即便人到中年，估計也是寶刀未老吧。 正當我身心狀態都預備好了，卻見老同學方向盤一個拐彎，把路讓給了後方的來車，只見後方BMW引擎喇叭輪胎聲大作，從我們車旁呼嘯而過。我心想，老同學這是身經百戰之姿啊，顯然是要讓對方輸得心服口服，所以打算從後方追趕是吧? 停了兩三秒…咦? 沒有。 偷瞄了老同學一眼? 嗯? 沒有反應。 『沒準備教訓對方一下嗎? 這不像你啊~』我忍不住開口揶揄一番。 『我現在開車可是心如止水，不動如山。』他笑著回答道。 『怎麼說? 是受了甚麼教訓嗎?』我一幅幸災樂禍樣。 結婚前，我女友常跟我說:『開車時幹麼跟其他車子比快比狠，除了逞一時情緒，還有什麼意義?』我當然聽在耳裡，沒放在心裡。 後來，有一年夏天，颱風剛過，路上很多被風吹倒的樹枝，當天急著要到公司，路還不很好走，開著開著，後面一台車也像是剛才那樣又是喇叭又是閃燈，我看了當然火大，立馬緊急煞車，停下來準備跟對方理論。 下車才走沒幾步，後方駕駛還沒來得及反應，我就發現他猛按喇叭的原因了… 原來我後保險桿勾到了一大串將近半個車身長的樹枝，顯然是被颱風吹斷的，似乎被我車子拖著跑了好一陣子。我一看當下沒了情緒，先把樹枝給拉開，然後跟對方駕駛打了個道謝的手勢。(原來後面的駕駛還是一位老太太) 回到車上，我一邊開車一邊思考，我想到的不是誤會了對方覺得不好意思(當然也有)，而是，我發現原來人的情緒可以變化的那麼快，前一秒鐘我還想下車理論個輸贏，但下一秒後我立刻沒了情緒，為何會有這差別? 我意識到，其實是我對事情的『認知』造成的。 我沒看到部分的事實(樹枝纏在保險桿上)，但卻看到了對方駕駛按喇叭和閃燈(這也是事實)，我自己把這行為 解釋成對方很不禮貌 ，就是要跟我輸贏。因為我這樣理解這件事，所以導致自己心情不好，衝動到下車打算講個道理，甚至...

當你有一定的年紀之後，話就會愈說愈小聲。雖然我清楚地明白這個道理，但每次發生在自己身上時總是印象深刻。 常看這個blog的人應該都知道，我不太喜歡CLI( Command-Line Interface)，除了因為現在的圖形化介面其實大多都做得很完善，加上我從小討厭背指令，實在記不得要完成某個動作的時候，該在鍵盤上敲下什麼…而且更主要的原因是，我經歷過那個只有CLI沒有GUI( Graphical User Interface )的年代，那個時代的工程師天天跟黑底白字（或綠字）的螢幕為伍，花上數小時在鍵盤上敲打著別人看起來完全沒有意義的文字… 我也不例外，副作用之一當然是練就了超快的打字速度…但其實頗為辛苦。所以當GUI出現的時候，我和很多那個年代的工程師一樣，是大聲頌揚大力鼓吹的，並且對CLI棄之如敝屣。 一晃眼30多年過去了… 最近這幾年，CLI居然又成為主流，我在心理上其實很難立刻接受。（你會發現人的既定印象與觀念有時真的很死板，一旦形成後，無法改變到難以想像的地步）我始終認為，只要在有設計良好的GUI的前提下，我根本沒什麼理由需要跟以前一樣一天到晚用力敲打鍵盤! 直到… 最近因為上課的關係，需要實現『金絲雀佈署』，這導致我常常需要一口氣建立兩三個Web Site Slot，並且在不同的slot分別各自佈署網站(這還只是暖場)。然後，為了實現金絲雀，我必須要先在第一個網站佈署新版，然後透過Web App的traffic management改變流量，把10%流量導入第一個站台，依此類推，直到最後一個站台佈署完新版… 第一次，我用Azure Web UI用到覺得很Ｘ。 當我發現，過程中我少做(或做錯)了一個步驟，導致設定配置有錯誤的時候，為了讓整個Lab環境乾淨且順暢一點，我發現我得要重來 >_<。 佈署到第三輪之後，我開始覺得這樣在網頁上用滑鼠點來點去實在不行。 就在這一刻，我竟然毫不猶豫的打開了powershell: 其實過去就安裝過了azure cli，所以我隨手把建立網站的指令打了進去，不夠確定的話還可以請AI神燈阿拉丁幫忙查詢(在上面，有看到嗎，哈)…後來發現，我與其這樣一行一行打，不如用VS Code編輯。接著開了VS Code，想到印象中有一個azure cli套件，可以有intellisense的功能，還可以在VS Code裡面直接r...

Only the Paranoid Survive - Andy Grove 還記得葛洛夫嗎? Intel的創辦人之一。他說的這句話，台灣大多翻譯成『唯有偏執狂得以倖存』，乍看之下很難理解，也不太容易關連到日常工作或生活當中的情境。 為什麼我會突然想到這句話? 講個故事。 適逢農曆過年前，由於過年時候必須要往返南北長途開車，所以過年前理當去車廠保養一下，因為一直都在原廠保養，從來沒發生過什麼太大的問題，也剛好在定期保養的時間內，農曆年前又一堆課程、專案，所以預約保養的時間拖到了小年夜的最後一天。 想說換換機油什麼的，應該很快。 沒想到坐在休息室大廳，咖啡都還沒喝兩口，師傅跑出來說：『先生，我跟您解釋一下車子的狀況…』心想，不妙。師傅說：『OO這邊，和XX這邊，有這些問題，另外OOXX應該要換，但…』『最麻煩的是，車子的水箱幫浦漏水很嚴重，這個問題比較大，如果開長途，恐怕有些危險…』 『好吧，那這些換下來要多少錢?今天會好嗎?』我心裡想，錢能解決的問題都是小問題。 『恩，但是，我們這邊現在沒有料件』師傅說。 『那能不能幫我調調看，是不是其他廠有零件可以換?』我問。 師傅為難的說『恩…就是都問過其他廠了，現在剛好都缺貨，要…年後才能夠幫你調料。』頓了一下又說『但，這個問題蠻嚴重的…』 我立刻問『你是說，車這樣沒法開長途嗎?』 師傅回答：『恩…就是你要常常看水箱是不是空了，我們剛才檢查你的水箱是全空的…如果溫度…如果有亮燈，你要立刻停車。』師傅還補了這一句『這問題蠻麻煩的，如果有貨我一定會建議你立刻換…』 『所以說，我目前也沒法做什麼?』我問。 『我們可以把剛才OO和XX這幾個問題先處理，OOXX先換掉…』師傅說。 『那好吧，我在這邊等。』我回答。 回到休息區，越想越不對勁。上網一查，水箱幫浦不貴，但如果掛掉或漏水，確實風險蠻高的，對安全很有疑慮。 怎麼辦? 過年行程已經定了(訂金也付了)，現在改搭高鐵(沒票)或租車都來不及。而且就算下去，沒車也挺不方便的。 剛才一邊喝咖啡一邊打開電腦螢幕上寫到一半的code已經沒法吸引我的專注力，我心想，我要怎麼解決這個問題。 -------------------------------------------------------------------- 先停在這邊，如果你有耐心讀到這裡，我想問問，如果是你，你怎麼解決這個問題?...

前幾天聊到價值(Value)，給我點時間，讓我細說從頭。 這幾年做案子下來，發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行，談價值卻很吃力。你可能覺得疑惑，需求訪談不就是談需求嗎? 為何會扯到價值? 回答這問題前，先幫我想想，一個軟體的需求是為了什麼? 沒錯，需求是為了實現價值，功能則是需求的具體表現。 舉例來說，一個電子商務網站可以有各式各樣的功能，但核心價值要嘛是銷售、要嘛是服務，OK，這個你一定懂。 但大多數的SA或技術人員，受過了多年的技術訓練，談功能很拿手，各種工具、圖表、道具順手捻來毫不手軟，客戶看的眼花撩亂但也很開心，因為看到這麼多功能(工項)被列出來，腦袋裡自然而然幻想著，當這些功能實現，需求『自然』就滿足了，而需求被滿足，價值『自然』就實現了。 但真的是這樣嗎? 做那麼多年的軟體之後，你肯定知道，不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值，根本可以是兩回事。 然而很多客戶(和廠商)死不信邪，以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...) 然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求，然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...) 每當我們要求跟客戶談需求時，試圖把焦點拉回價值(而不是一直停留在談功能上)，一開始客戶都很不習慣，因為這仿佛很抽象，廠商自己也擔心，因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成，這...似乎有點難? 對，但就是因為這很難，所以久而久之，我們把價值放一邊，銷售時就拼命暗示客戶你有某種需求等著被滿足，而要滿足這些需求，則要做出這些功能，只要你買了這些功能，一切就搞定了。 然後，最初期待實現的價值呢? 恩...沒實現嗎? 不要緊，下一套軟體我們再來談... ------------------ 相關課程： http://www.studyhost.tw/NewCourses/ALM 電子書： http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

這幾年做教育訓練、顧問服務、和系統導入，發現一件有趣的事情。 有幾次碰到一些客戶(有商業公司、非營利組織、學校…都有)，在開會或課程之後私下跟我說，希望我們在提供建議的時候，可以『直接』告訴我們的team member，這件事情該怎麼做，而不用花太多時間告訴我們這些事情的原則，或是背後的邏輯或原理。因為team member只需要快速地得到答案，加上事情很緊迫，他們也沒有時間去學，說多了徒增困擾(這句話有個潛台詞，建議讀者細想，很有趣…)，顧問(講師)直接告知做法之後，我們就可以比較快進入下一個問題(議題)。 可能有人看了上面這段話不明白意思，我舉其中一個比較具體的例子。 有一次碰到一個軟體開發的資安問題，我花了幾個小時解釋為何程式碼這樣寫不行，為何這有可能帶來風險，從這樣的程式碼我們可以得知外包的開發人員應該有哪些問題…，幾個小時下來，我發現，客戶唯一關心的事情只有一個: 那現在這行程式要怎麼改? 直接告訴我就好。 至於其他的，大夥兒絲毫不在意。 這類的例子最近層出不窮。由於樣本數雖然多但我沒徹底研究，因此目前我無從取得確切的證據，證明背後的原因是什麼? 但推敲之後，能猜個大概。 可能是因為這年頭大家都很忙，碰到問題，只想快速知道答案。而網路的便利性讓許多人變成只願意(也似乎可以)迅速的取得結果，久而久之，慢慢地不願意也沒耐心花太多時間深入理解問題背後的成因。 也就是說，大家並不真的在乎(到願意付上代價、例如時間)來面對問題、或學習解決問題的能力。 許多人變得只想知道，當下眼前這問題怎麼解決。 『告訴我解法就好，其餘的我不想多知道。』似乎已經是網路速食時代的寫照。 這是最近幾年碰到的，以往，大概十年前，這情況比較不常發生。但不用我說大家應該也知道，長久下來這(對企業、或團隊)會導致什麼結果。 再加上，網路時代很多流傳文章，標題長這樣：『OOO的原因原來是XXX』、『解決XYZ的N種方法』、『想要OOO就得XXX』這類的文章都很紅。標題看似一針見血，但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案，其實都隱含著一個假設前提，就是你的環境和他(作者)相同，然而你也知道，真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道)，因此大多數文章的作者，也不太會詳細敘述案情的成因與環境的背景，導致部分憨直的讀者以為，我照著做就會有一樣的結果，其實不...

如果說35歲是一個開發人員的分水嶺，那對我來說，站在這個分水嶺的前後，寫程式這件事情，也開始有了一個非常顯著的差異。 說句話，我相信大多數的程式設計師都會同意：『要動手寫程式很容易，但想要寫出好程式卻很難。』 身為開發人員，在35歲以前，我幾乎都在思考怎麼把程式寫得更好，但我發現，過了35歲以後，我卻天天都在研究如何能把程式寫到能賣的出去。 乍聽之下，你可能覺得這樣的想法很現實，甚至可能很市儈，開發人員應該對自己的工作有熱忱，動不動談錢，這不是很俗氣嗎? 對開發與技術的愛，才是技術人員一直以來持續不懈的動力，不是嗎? 對技術要有『愛』這件事情，我還有場分享，記得嗎? 對，但那場分享裡面，我發現我忘了說，對技術要有愛，這只該用來期許自己，不能拿來要求別人。 畢竟每個人生來不同，開發人員對技術的愛，可以是自發性的，埋首鍵盤螢幕與書籍，只要有愛，即便廢寢忘食也是樂趣。有時，突然搞懂某個卡關的領域，頗有朝聞道夕死可矣的豁然。 但這一切，都只是對自己的期許，你不能這樣要求你的同事、你的夥伴、甚至你的部屬，強迫他們跟你一樣，只對技術有愛，其他都可以放棄(一句相忍為國，是不能當飯吃的）。同樣的，你對自己開發出的產品有愛，這天經地義，(如果沒有才真的有問題)，但你也無法要求用戶(客戶)、老闆，跟你一樣無條件地去愛你寫出的成品。 用戶才不在乎你開發這系統時用了哪些頂尖的技術，實現了什麼理想遠大的框架，用戶只在乎你的系統對他有沒有實質幫助? 產生了什麼價值? 用起來的爽度如何？ 容我說一句，再怎麼頂尖的技術都會過去，套句現在流行的說法，那是假的，暫時的。只有用戶在用你開發的程式的那一刻，系統對他產生的價值，才是真的。 回到最前頭說的，如果說35歲是一個開發人員的分水嶺，那對我來說，在35歲以前，我幾乎都在思考怎麼把程式寫得更好，但我發現，過了35歲以後，我卻天天都在研究如何能讓程式賣的出去。 很市儈? 錯了，是否曾想過，要怎麼樣才能叫作把程式寫好？怎麼定義好這個字? 事實上，你的程式要寫到能夠賺到客戶的錢，那才是一種肯定，才是一種對程式的品質和功能的肯定，才是一種對程式價值的肯定。肯定從不是來自於你用了甚麼技術、寫了幾萬行、加班到深夜幾點…從不是。 如果開發出的系統對客戶無法產生價值，無論你寫了一千行、一萬行、甚至是十萬行，往往唯一能夠產出的經濟效益，僅只是幫...

前幾天，看了一篇 文章 ，看完之後我立即在FB上分享，原因不僅僅是因為文章中描述的雖然以設計界為主體，但根本120%符合台灣軟體專案外包的現況。我本來想節錄其中讓我很感慨的幾句話，但我回頭再看一次 文章 ，發現我不用節錄什麼，我推薦讀者整篇重頭到尾讀一遍就對了。 接著，我想說說我的感受。 最近十年，我剛好身兼文中所說的幾種工作，資訊軟體開發的教育訓練、雜誌專欄文章撰寫、書籍出版、同時也在業界接案、甚至擔任顧問，台灣軟體專案發包的低價、浮濫…等問題，跟文中說的完全一樣，我們非常明白這件事情。(因此看完之後，我沉思良久) 但如果說，我們在接案時跟其他人一樣，必須被迫用較低的價格來接案，這只說明了一件事情，就是『客戶覺得我們不夠專業』，我們不夠優秀到讓客戶願意用比別人更高的價格，來聘請我們為他服務。簡單的說，就是如此而已。 你說市場行情，沒錯，市場行情是一回事，但對於追求專業的我們來說，我們總是期許(要求)自己所做的每一項工作，都有著比他人高的品質和效率，這意味著，我們期許自己比其他同業要來的專業，果真如此，那在價格上應該要比一般"行情"要來的高一些才對。 如果客戶不願意用比市場行情高的價格，來聘請我們，那顯然該檢討的不是客戶，而是我們自己。我們是否曾在客戶面前彰顯了自己的能力? 我們是否讓客戶感受到十足的值得信任? 客戶和我們溝通的過程中，是否就能夠體會到所謂的專業? 是否與我們對談本身，對客戶來說就已經是一種收穫? 如果不是，那表示我們還必須努力。 當然，容或有一些客戶 對專業沒興趣 ，只希望用最低的價格拿到堪用的成品，但這本來也就不是我們想要爭取的對象。 最近十年，軟體或網站開發比起過去容易非常多，隨便一個學生或是上過職訓的SOHO，都能夠拿起開發工具寫code(沒什麼好怨的，我們自己都帶過這樣的教育訓練課程，也都在台上跟學員說，你看，你看，就這樣，很簡單吧…)。 但，如果只是把程式碼寫出來，讓網站可以動，那顯然無法彰顯你的專業。 在這個業界待了五年、十年、甚至二十年，和剛畢業的學生有何差別? 當破壞行情的份子在業界用極低的價格承接專案的同時，我們能否清楚地跟客戶說明，為何我們值得比較高的報價? 軟體開發或網站設計為何不僅僅只是寫代碼? 一個優秀的系統還包含了哪些要素? (穩定性? 延展性? 安全性?) 好的專案管理該如何凸...

前一陣子到某家公司進行教育訓練，談的是專案管理與ALM。席間，有位學員問到：『Scrum鼓勵溝通，但要怎樣才能夠讓成員凝聚出團隊氣氛，讓大家真的進行溝通，並且引導同仁往持續改善的方向前進呢?』 我很能理解這個問題，因為卓越的工程師普遍喜歡自己一個人埋頭寫code，對解決技術問題都有自己的一套想法，但要習慣性地跟其他人一起合作，有時似乎還挺困難。這位提問者是公司的主管，他嘗試過讓這些團隊成員到外面上溝通的課程、訓練團隊成員溝通的技巧，甚至把溝通這件事情當作績效指標，結果…不出你的預料，完全沒效。團隊成員好像更不喜歡講話了。 回答這個學員的問題前，我先跟這位學員說了一個我最近在一本書上(關鍵18分鐘)看到的一段故事。 書籍的作者有次造訪一座部落平原，搭乘著老舊的火車，乘車過程中，他看到有一頭雄偉的獅子 · 蹲伏在山丘頂的岩石上，看得清楚極了。 作者問列車上的管理員：『這麼巧，竟然能夠遇到獅子出來 · 這樣算是相當幸運的吧?』 『那頭獅子一向都在那裡，牠總是坐在岩石上。』對方這麼回答。 『真的? 你們用什麼辦法 · 讓牠一直待在那裡???』作者問。 管理員笑而不答。 學員們疑惑的同時，我接著說了書上的另一個故事： 『曾經有一位主管向HR顧問抱怨他們公司的接待人員不夠熱情，看到有人走進服務櫃台卻沒有表現出友善的態度。顧問實際上瞭解了狀況之後，發現根本不需要讓接待人員接受任何額外的教育訓練，也不需要複雜的績效制度，只需要把接待檯前面像是郵局櫃台一樣的那個售票窗口的玻璃移除，同時降低櫃檯的高度，服務人員的態度立即有了明顯的改善。』 真的有用? 是的，因為人們非常容易受到環境的引導和暗示。 接著，我把我們某個專案團隊的照片開給他看，並且問：有沒有發現，和一般的辦公室比起來，位子和位子之間少了什麼? 沒錯，少了隔板。 如果你一邊鼓勵團隊溝通，一邊卻讓每一個團隊成員都坐在像是城堡一樣高度的Office Partition座位中，那溝通是不容易發生的。反之，把隔板拿掉，讓team member面對面，眼神可以隨時看到對方，如此一來，團隊成員之間的交流會自然而然的形成，不需要額外的教育訓練與獎勵制度，不需要導入績效管理。事實上，最有效的方式，就只是一個環境的改變而已。 同樣的，在實施敏捷開發的許許多多做法當中，最不需要的就是導入KPI之類的績效制...

  每一場Session，都應該有自己的主題曲。   今年的 MVP Open Day 我第一次分享關於開發人員生涯規畫的主題，這也是從事資訊工作這近25年來，第一次比較完整的整理我在資訊專案或是相關工作中，擔任不同角色時的心情。同時也總結了我對於開發人員相關工作的感想。   其中很多內容，是不太可能在網路上看會後投影片就可以感受到的，我相信今天陪著我在現場的朋友，肯定可以理解我想表達的意思。   也因此，除了謝謝大家今天的參與，我先把底下的連結和影片分享給今天陪我度過一小時的朋友們，謝謝大家共同的投入，讓今天的這場Session圓滿的令人開心...   ref: 你為了什麼寫Code呢??? ref: 重要的事情先做 ref: 專業主義的秘密 - 練習 ref: 關於 如何快速增進程式功力... ref: 持續地改變是必然的趨勢...     ref: 對我的人生有重大影響的幾本書 ref: 力挺你的夢想 ref: 再看New Mondeo的CF與軟體開發人員         (沒有來現場的朋友，可能不明白我這篇分享的意思，不要緊，下次，希望在會場見到你) 2014/4/14 udpate... 現場復刻版video

在台灣(其實在很多其他地方也一樣)資訊人員成功(或是獲利高低)的關鍵幾乎都不是技術能力，或許技術能力是一張門票、或是入場券，但是真正讓人成功的因素，往往不是人人都有且可以迅速學習而得到的技術能力，常常左右你成功的因素其實是一些觀念和習慣，特別是工作上的習慣。 很幸運的，在過去我念書的過程中，有兩年的時間我讀的是管理，而學校的圖書館充斥著相當精典的管理書籍，特別是這些書都不難看，很生動的讓人愛不釋手，你往往會有捨不得翻完的感覺。 我不常分享這些書，今天突然想到，列一下清單，算是留個紀錄，如果以後有時間我會逐本跟大家分享，讀書一直是一個很好的享受，如果你能夠給自己留一點時間，不妨泡杯好茶，或是煮杯咖啡，好好享受讀書的時間，至於哪些書，我都列在下面，每一本書都對我人生(特別是工作)有很大的影響，希望對你也有幫助... 【與成功有約 系列】 《柯維七書（與時間有約、與成功有約、與幸福有約、與領導有約、與青春有約、與影響力有約、與生活有約）》天下文化著，天下文化出版。 【目標 系列】 《目標－簡單而有效的常識管理》高德拉特等著，天下文化出版。 《關鍵鏈－突破專案管理的瓶頸》高德拉特著，天下文化出版。 《絕不是靠運氣》高德拉特著，天下文化出版。 《仍然不足夠：ERP加TOC的企業電腦化新境界》高德拉特著，天下文化出版。 【乳酪系列】 誰搬走了我的乳酪？ 禮物、峰與谷 [ 史賓賽．強森 ] 世界是平的 【狄馬克系列】 最後期限：專案管理101個成功法則 Peopleware： 腦力密集產業的人才管理之道 (Peopleware: Productive Projects and Teams, 2nd ed. ) 【棉花糖系列】 別急著吃棉花糖 萬一吃了棉花糖 【派屈克 藍奇歐尼 系列 】 總裁的迷惑 — 健康組織的四大準則(The four obsessions of an extraordinary executive) 開會開到死(Death by Meeting) 團隊領導的五大障礙(The Five Dysfunctions of A Team -–A Leadership Fable)

從事IT行業多年，我一直有一個深刻的感覺，資訊科技日新月異，要能夠掌握足夠的資訊技術，並且讓自己能夠在業界不至於被淹沒甚至能夠在眾多的強者中異軍突起，所需要花費的精神和時間有時候已經讓人喘不過氣。不管是哪一個領域，MIS、SI、Vender site、User Site、Consultant、Trainer我大多都有扮演過這些角色、或多或少也都能夠體會不同角色中的辛苦。 不過也可能是因為IT相關領域(特別是Developer)所需要涉獵的知識一直在變和增加，這些部分已經讓人耗費心力，使得IT人員在一些基礎的管理技能上，顯得有些缺乏。說真的，我認識的IT人員很少不是聰明人(意思就是大多數都是聰明人...我真怕現在很多人看不懂這樣的中文寫法...)，我覺得大家都很Smart，但是往往由於缺少了一些基本的管理知識，在專案中常常變成無頭蒼蠅，忙碌，卻不一定能夠產生預期的效益。 關於這部分，我最近和一個同事提起，對於IT人員，不管是系統開發人員，或是MIS、你要妥善規劃你的時間，有一個很關鍵的技巧，就是把重要的事情放在前面， 重要的事情先做，一直是時間管理當中很重要的一個部分。 不知道你有沒有讀過一本很不錯的管理書，作者把事情分為四種，急迫但不重要的(P2)、重要但不急迫的(P3)、不急迫也不重要的(P4)，即重要又急迫的(P1)。 我記得我以前曾經提過這個觀念，這個觀念對我有非常大的幫助，我一直想找時間與大家分享，回頭想想這四種事情，你會先做哪一種? 你在哪一類的事情上你花了比較多的時間??? 一般人P1一定會先做，這個毫無爭議，典型這類的工作是：家裡失火、急病住院…不過這些事情都不常發生，更具體一點的 工作 像是明天要交付驗收的專案、下午會議要用的報表…等，都屬於P1的範疇。 P1類型的工作往往不會佔用你絕大部分的時間，但是如果你發現自己手上每天的工作全都是P1，這表示你每天都在救火(我就看過這樣的MIS部門和專案公司，我可以肯定的告訴你，你絕對在這家公司待不久，搞不好這家公司或這個部門自己也撐不了多久，碰到這種公司，我會建議你趕快準備104…)，如果手上的工作大部分都是P1，不用懷疑，你(或你們)的時間管理絕對有問題。 P1類型的工作，我認為在正常的公司當中一週不應該超過一、兩件，每件應該也都要能夠在三小時內解決。(否則他就不是P1，而是P3轉換成的P1，我待會解釋) ...