.NET Walker

有一個字叫做 target fixation，這個字不常見。 我在整理舊書的時候，從書架上掉出了一本書，target fixation是我在這本書上看到的。 不知道你有沒有過一種經驗，一開始學習騎車或開車時，由於太專注在要前往的方向，結果卻直接一頭撞上你想抵達的目標。這個字，差不多就是這意思 --> 由於過於專注在目標上，導致於駕駛者不自覺的增加了撞上目標的風險。 一般來說，它用在飛行器具、車輛的駕駛上，是一個專有名詞。但這本書"飛機上的27A"，把這個字用在人生。 你曾有過，太過於專注一個目標，導致於你忘了身邊其他的事情? 如果你是程式設計師、工程師，你一定有過這樣的經驗 --> 專注解決一個棘手的問題，似乎才過沒多久，結果天都黑了(或是天都亮了)。 --> 這現象有個專有名詞，這叫心流(Flow) 心流不是很好嗎? 當我們想專注的時候，是的。 但一直心流會很好嗎? 不。 你若有機會看到沉溺於賭局中，專注在機台或牌局當中的人，那也是一種心流。但，就算贏了賭局，往往也輸了整個人生。時間過去了，就再也不會回來，有時候，路過的美景，過去了就是過去了，若是過於專注在目標上，往往會讓你錯過身邊的風景。 我記得，我把這本書送給了一個好友，因為那時候我看到他全心投入工作中，犧牲了非常多個人生活的時間。這我是過來人，過去專注在工作、寫書、做系統、上課…不知不覺，十幾年過去了，目標達成了，但想想好像也犧牲了些路上的風景。 專注於目標很棒，但千萬別忽略了身邊的人與美景。 農曆新年前的最後一天，再次給自己這個提醒。

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

凡事都可行，但不都有益處：凡事都可行，但不都造就人。(林前 10:23) 前陣子有位好友特別到我辦公室，跟我討論他最近想要做的某個軟體產品。他知道我過去這幾年有非常多產品開發(我想估計是失敗的)經驗，所以他說想跟我請益一番。 一如既往，只要人到了我辦公室，我肯定熱情接待、滔滔不絕、知無不言。談過了他的想法與企圖，也給了一些建議，茶過三巡，我也就不客氣地分享了我最近想做的另一個資訊服務，話還沒講完，他拍案大讚，說到：『David你這個案子會成，要不要做? 我有興趣。』 他的熱情讓我愣了一下，我有點猶豫地說，我還在思考一些問題，像是…為什麼我目前沒看到市場上有類似的服務? 台灣那家知名的網路商城P公司，該是最有資格做這個案子的，不管是倉儲、物流、和我這個案子最關鍵的庫存品，都一應俱全，我不太懂他們為什麼不做? 朋友說了一句話：『P公司太大了，他們什麼都能做。什麼都能做，就代表什麼都做不了。』 他話才說完，我就明白了。 (有時候跟頻道接近的朋友聊天就是有意思，話不用講太多，彼此一點就懂。) 我明白了朋友說的意思，但也看到了我自己的限制。 這一直以來是我的問題，我意識到這個問題，但卻始終沒有去面對。 前陣子流行『斜槓青年』，你可以在網路上找到這個字的意思。但我慢慢發現自己實在斜槓太多的領域了(而且也不是青年了)。過去這幾年，我寫書(手上正在寫一本)，做企業顧問(目前一家進行中，一家洽談中)，同時也帶人做軟體專案(目前三個案子進行中，好在差不多都是結案階段了)，我也喜歡上課(下個月開始預計有兩個排定的課程)，另外每周我給自己的目標是產出三到五篇的貼文、blog文章和數個教學影片檔，為了提供給線上課程和電子書… 然後，我還一直很想做產品。 雖然盡全力把每一個手上的任務做好，但很明顯的，我發現瓶頸在哪裡了。的確，瓶頸就在自己身上。 問題來了，我要割捨掉哪一塊? 我太明白多工與多重目標所帶來的陷阱和限制。回頭翻自己的貼文，還有底下這兩張照片呢： 但怎麼當要去面對這些問題的時候，自己也變得難以割捨了? 管理方法的道理和邏輯永遠是那麼鮮明，但執行的困難卻往往不是不懂這些，而是在情感上的拉扯和限制。 剛開始工作的第一年我就發現，除非自己選擇放下，否則手上的工作 永遠 不會有作完的那一天的。而當人(企業)能做的事情看似愈來愈多，就愈是得克制每一件事情(每一個目標)都想去做的衝動。 我記得從...

If somethings difficult or painful, do it more often. 這句話似乎有點黑色幽默。你知道我在哪邊看到它的嗎? 是Azure DevOps的教材中。不可思議吧，剛看到的那刻我一頭霧水，它是怎麼會這麼不搭的出現在教材裡? 然後，我努力地搜尋，發現第一次出現這句話相關的內容，是在Martin Fowler的blog: https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 它讓我想起以前在某本書上讀到的一段話，『 如果你想成功，就拼命去做自己明知該做但卻不想面對的那些事情。 』理由很簡單，因為我們始終得去面對我們該面對的事情…早晚而已。 為何要 盡早且頻繁 的去做那些我們不想做的事情呢，Martin Fowler給了三個看法。分別是 Smaller chunks、Feedback、Practice。 越討厭的事情就要越早做，免得積壓起來變成一大塊，那時候你就更不想做了。而且，一小塊一小塊的去進行，比起特別空出一段時間一次做完，其實來的輕省的多。Martin Fowler提到Database migrations就是這樣，我覺得其實不只，根本重構也是。 (平常有掃地，過年的大掃除就可以輕鬆一點；每天做一點功課，就不用期末前拼命趕報告K書的概念…) 而一小塊一小塊地進行，更容易讓我們 即時取得反饋 (不管是來自外在 環境 的、或是來自 客戶 的)，這樣可以讓我們經常持續性的檢視自己的方向是否正確，如果把討厭的事情堆積起來，等到非做不可的那一天才做，那些會造成你卡關的問題常常來的讓你措手不及。 (平時不運動，等到發現自己身體有問題才開始運動，你的體能和身體狀況往往已經吃不消了的概念) 最後一件事情，就是『練習』。 確實，很多事情看起來很難(不然我們也不會想要逃避它)，但當我們去面對它，常常練習之後，它會開始變得容易，如此反覆進行之後，本來看起來很困難的事情，慢慢的你會越來越熟悉和上手，這時候原本的難度會開始漸漸消失，困難的事情也就變得不再那麼困難了。 藉由反覆練習，你會熟悉踩過的坑和需要注意的事項，久而久之將變成習慣，在外界的人眼中，你似乎是天生好手，但你知道，其實也不過是因為你常常練習罷了。 很有趣吧。 If somethings difficult...

當你有一定的年紀之後，話就會愈說愈小聲。雖然我清楚地明白這個道理，但每次發生在自己身上時總是印象深刻。 常看這個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...

還記得我在研討會常講的那個故事嗎? 某次我老闆急著趕去會場，由於正在準備接下來會議的主講內容，手上拿著稿件低頭攔車，因為快要遲到，他跳上計程車後情急地說：『快…開快點。』卻忘了計程車駕駛壓根不是平時幫他駕車的司機，根本不可能知道他要去哪。 只見計程車司機二話不說猛踩油門車子狂飆了三個路口之後，我老闆才想到似乎有點不對，問計程車司機說：『我剛有跟你說要去哪嗎?』 司機驕傲地回答：『沒有，不過，我確實有開的很快，對吧?』 最近開始認真讀那本暢銷的OKR(先前是有看過一些介紹文章，但只能大致掌握基本概念)，不過讀著讀著又開始覺得，近代幾乎每一本實用的管理書籍，都曾在書中以不同的姿態告訴你 目標 有多重要，而『認真地』訂出目標幾乎是一切管理的根本。 不管是 柯維 的 與成功有約 系列、 高德拉特 的 目標 系列、最近我很喜歡的『執行力的修練』、管理大師 杜拉克 的演講或著作、坊間流行的KPI和OKR...每一種方法論其實都在跟我們說同一件事情... 『若你沒有認真的訂出目標，就什麼都別談。』 這個道理其實大家都懂，但環顧身邊，有認真訂出目標的人似乎還真的不多。 的確，我們每個人或多或少都有(過)目標，但我們面對自己的目標到底有多認真呢? 我依稀還記得20多年前我的管理學老師在課堂上說：『你絕對可以實現任何 (他強調任何) 你想實現的目標，只要你「現在」把它寫在紙上。』他說『關鍵不在於你訂的目標有多麼大，而是你到底有多認真，你到底有渴望實現這個目標，願意為它附上多大代價...』 當然，那天全班沒人理會他說的話，當下我甚至有點懷疑他自己到底相不相信自己現在在說什麼? 20多年後，我唯一後悔的是當時寫下的目標太小。 當年他說，有一個非常簡單的指標，能夠衡量出你對這個目標有多認真。 不，不是你有多慎重的把它記錄在高價的筆記本上，也不是你每天把它拿出來膜拜的次數有多少。而是…你身邊和你最親近的人當中(朋友、家人、同學同事...)，有多少人知道你的目標? 有多少人能在不需要提示的狀況下，就能清楚的說出你訂的目標，這些人愈多，你的目標實現的可能性愈大...，如果你身邊還沒有這樣的人，從今天開始，把你的目標寫在紙上，貼在你的書桌前、房門口、座位上…讓每一個你身邊的人，都知道你的目標是什麼… 不知道為什麼，他當年說的每一句話，我至今還記得相當清楚... 20...

今天在改一個以前自己寫的系統。 愈改愈覺得，當初怎麼會這樣設計的? 很多寫法實在看不下去，只好重構一番，把過去的一些設計和架構做些調整和改善。我猜，只要你是職業(不需要是專業)的開發者，肯定也曾有過這樣的經驗。 我們常常覺得過去的東西似乎還有可以改善的空間，所以，系統就這樣在修修補補之中度日。 曾經我覺得這樣子不行，所以花了一些時間認真學習各種pattern、架構設計、框架開發...等知識技能，想說從此之後，應該能高枕無憂，在開發時做出比較能夠長治久安的設計。 結果呢? 跟你猜的一樣，並沒有。系統還是在修修補補中度日。這到底是為什麼? 幾年之後我知道，原因很簡單，因為環境在變，技術在變，需求在變，我們活在一個多變的真實世界，然而我們能控制、能掌握的變數實在太少，少到所有的預先規劃和設計最後看起來都變得可笑。 所以，敏捷(Agile)不相信計畫(Plan)，甚至誇張一點說，敏捷不相信有完美的預先設計(Design)。 但注意，這不是完全不要設計，而是，不管當時看起來怎麼完美的設計，你都要有這個心理認知--『 日後它一定會變得不完美 』。不管你做了什麼樣精細的計畫(Plan)你都要知道，這計畫未來一定會走歪，只要你是活在一個充滿變數與未知的真實世界中。 你不相信? 或許你會問，那為何過去的年代，計畫似乎是有用的，甚至有人手上可以有好幾套劇本，事情的走向總是被掌握在足智多謀、細心計畫的智者手中? 那是因為過去的時代沒有現今的科技與技術，資訊的傳遞也不像現在這麼迅速，當時的世界給了人們一個假象，讓人誤以為自己可以掌握些什麼，能夠控制些什麼，能夠讓事情的走向依照計畫，或是運籌在股掌之間。 也確實，當你手上的資源越多、運算能力越強大，面對的問題越簡單、變數越少、時間越短，那預測和掌握未來的可能性不是不存在。 反之，當你手上的資源越少、變數越多、你就會發現對未來的掌握度趨近於零，事事依照計畫走的可能性根本不存在。 所以我們乾脆不要計劃了? 開發時也不用做任何架構設計? 對，也不對。 對的是這個想法，預先計畫和預先設計並不可靠，這意味著你不能完全倚賴它。 不對的是這個行為，你不能完全不做任何計劃或設計，你只是不該再像是以前那樣鉅細靡遺地去設計，並要求所有人照著劇本走，期待規劃好了就不會再改變。 會不會很矛盾? 對我來說完全不會，因為這就是人生。 ...

做軟體開發很多年之後，常碰到有人問我，軟體公司是怎麼估算一套軟體的價格的? 用開發的人天數來算嗎? No, No, No…『人天數』是一個非常標準的 錯誤答案 。 如果你是軟體開發商，軟體開發的『人天數』可能是你的成本，但絕對不會是報價/售價。 那報價/售價怎麼定呢? 讓我先問一個問題... 對於買方來說，什麼叫做『買貴了一套軟體』? 或者反過來問，什麼叫做『買了一套划算的軟體』? 不好回答? 想一想底下的例子... 如果軟體開發商花5個人月為買方(你的公司)客製化開發了一套系統，然後賣你500萬，對你來說，這貴不貴? 其實我們不知道。因為貴不貴是相對於這套軟體能為你帶來多少價值而定的? (而非開發商花了多少時間) 如果你花了500萬，系統上線後，能每個月為你帶來50萬的效益，那我覺得這500萬算很值了。但...如果系統上線了，一年後都沒法為你帶回幾十萬的效益，甚至還讓你虧錢(請相信我，類似上線後還虧/花大錢的案例你在資訊界隨便問都一票)，那不管這套軟體廠商是花十幾上百個月，對你來說這套系統都是買貴了，一點都不划算，應該說，這軟體一點意義都沒有。 如果你同意這個思維，大概就能理解，軟體開發的報價不該是用人天來算，況且，一個軟體開發高手跟一個會寫程式的菜鳥初學者，兩個人『一天』的產出差異恐怕可以達十倍以上，但你有看過人天報價level差異化到十倍的水準嗎?應該從來沒有吧。 那有沒有覺得很奇怪，如果軟體不該用人天來計價，那為何打從你第一天進到這個產業，一直到今天，都還是會常常聽到人月或人天這個計價單位呢?   有一種可能是，我們其實不怎麼知道(不會、不敢、或不願)去評估一套軟體系統的『價值(Value)』。 很難理解? 其實這就如同大部分的公司其實很難評估一個員工的產值一樣。 若當公司不知道該怎麼(或不願意)去衡量員工的產值時，往往就只好拿 其他看起來很公平客觀的數字 (例如出席狀況和上班工時)來決定員工的價值了。而這正是一種非常古老落後且糟糕的方式。 久而久之，當員工養成習慣用『在辦公室出現的時數』，甚至是加班時數、配合度…來彰顯自己價值時，其實也多半意味著，手上根本沒有一張漂亮的成績單，漂亮到可以拿出來凸顯自己的存在對公司的意義。常常有人說，準時上下班是最基本的，這話一體兩面，準時出現在辦公室確實真的就只是『最基本的』。 時代變化的很...

2019/1/26 敏捷思維、敏捷人生 之一 從敏捷的角度看這個世界是很有趣的。 年紀越大，越覺得在這個變動的時代中，計畫導向的人生原來根本不存在，小時候聽過很多傳記故事，描述某人從小立志如何如何，因為這個遠大的志向，少年時開始磨練自己，按部就班實現每一個計劃，然後一步步走向成功... 後來才發現，原來這些傳記故事大多是虛構，或是作者事後諸葛的加油添醋。真實世界中才沒那麼容易『按部就班』，意外總是比計畫來的擾亂人心。有心理學家說，成功者喜歡把事情合理化，認為自己的成就源自於規劃好有計畫的努力。然而，這世界上更努力的大有人在，常常只是運氣沒那麼好而已。 所以運氣比努力重要? 錯，千萬別誤會了。 事實是，未來很難計畫，我們沒有人知道明天會怎樣，先見之明往往只是事後諸葛。人生當中唯一能做的，就是努力過好每一天，至於其他的，交給上帝。 『被討厭的勇氣』書中描述阿德勒的價值觀，他認為過去已經消失，而未來則根本『不存在』，你真正擁有的，其實只有今天而已。為了過去懊悔沒有意義，為了未來擔憂不切實際，唯一有價值的，是拼命把你的今天過好。 『 我們唯一擁有的，就只有今天而已。 』這是多麼敏捷的思維啊。(居然出自百年前的思想家) 永遠聚焦在當下這個sprint，每一天，每一周...累積出每一個小小的Win(這不就是潛在可交付產品增量嘛!)，然後，你就有機會活出一個精采的人生。 過去失敗的sprint無須留戀，每個月給自己幾小時retrospective很夠了，然後move on。太遠的未來遙不可及，過多的計畫或擔心離目標越來越遠，只是折磨自己。 唯一不可放棄的是 現在 ，還在衝刺的你，必須專注在這個Sprint，只要你能過好每一天，對得起當前這一刻的自己，未來的人生也不會對不起你。 原來真正決定你人生的，不是計畫，不是機運，是活在當下這個Sprint的自己... ------- 註1: 在Scrum軟體開發方法論中，Sprint指的是一個迭代(iteration) 註2: 潛在可交付產品增量(potentially shippable product increment) 後記： 和大家討論Scrum、Agile、DevOps時，許多人常會提到幾位作者知名的著作，像是目標系列的高...