.NET Walker

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

前幾天聊到價值(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』這類的文章都很紅。標題看似一針見血，但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案，其實都隱含著一個假設前提，就是你的環境和他(作者)相同，然而你也知道，真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道)，因此大多數文章的作者，也不太會詳細敘述案情的成因與環境的背景，導致部分憨直的讀者以為，我照著做就會有一樣的結果，其實不...

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

Rick是專案團隊中脾氣非常好的一位工程師，和大多數的工程師一樣，Rick對於寫程式是相當有熱誠的，在開發領域算是有一定的年資，程式碼的品質堪稱一流，在專案中也時常擔任與客戶端進行技術問題或系統功能溝通的重要角色。 最近一陣子，我們發現Rick常常被突呼其來的電話打斷，隨著電話交談的時間長度，表情上的無奈越顯得明顯而清晰。同時，我們也發現Rick的程式碼開發品質與速度和過去相比明顯的降低了不少。 關心之下(非正式場合的閒聊)，發現Rick其實並沒有任何個人的問題，他只是專注地完成交付公司給他的任務，也就是專案開發的客製化功能設計，但由於客戶端的PM和User，在長期和Rick建立了良好的溝通默契與個人關係之後，開始跳過PM將一些小問題(真的是無傷大雅的小問題)直接請Rick進行系統的極細部調整。 也確實，這並沒有花非常多的時間，每一個調整動作都與系統整體的方向不衝突也不相違背，也就是說，這些問題即便依照正常程序經過PM來處理，這些修改依舊不會被PM擋掉，最終還是會發生，Rick也還是會著手修改。而User與Rick都希望能夠快速地解決這些小問題，省去一些行政上的繁文縟節，因此常常跳過雙方PM，進行了規格上的零星修正、UI的小調整或是Bugs的Fix。 發現這件事情之後，我請PM認真地把Rick找來，Rick很委屈的跟我說，他一開始認為這樣能夠 提高效率 ，並且提升對客戶的 服務品質 ，也確實如此，Rick總是擁有客戶端相當好的評價，甚至某些PM無法溝通的技術問題，由Rick出面協助溝通協調，客戶端總是比較能夠理解(或信任)。時間一長，這樣的溝通模式形成慣例，客戶也在專案中偶而私下請託Rick進行一些工作，但久而久之，Rick的時間開始被無法拒絕的瑣事所佔據，雖然後來推掉了不少，但開了先例，也不好意思每一個問題都直接拒絕，就演變出今天的結果。 這樣的情況，在專案工作中其實常常發生，不只發生在開發人員，偶而甚至發生在PM身上，儘管制度上我們都設計成必須要記錄每一個修正或程式修改動作，但實務上總是有一定比例的工作在檯面下持續進行著，不僅是甲乙方分明的專案，在企業內的MIS/IT也常常發生這樣的情況，越過主管的工作指派總是持續在發生著。 程式設計師也很容易依照個人關係，來決定事情的優先順序，PM也容易依照與客戶的交情，來決定規格修改的退讓或調整幅度，...

最近在撰寫Silverlight的文稿(書稿和雜誌稿)、範例、和一些課程教材的時候，看到Web開發技術的發展回頭對比台灣的開發環境實在有一些感慨。 先講第一個，話說從頭，有一陣子我介紹了ASP.NET上的MVC，MVC這個架構是個好的Pattern，可以幫助開發人員達成建構出有架構、便於更新維護、便於抽換的應用程式，問題是這是(只是)一個規範、一個樣式，所謂的規範就表示，你應該遵循藉以得到一些好處，但是有趣的是，規範這個東西在台灣不見得一定會被遵循，老實說我本來以為在全世界都是這樣，但是根據我的觀察，在台灣這個狀況比較明顯，反觀我在台灣以外的一些合作夥伴和團隊，對於 "規範" 這個事情的嚴謹度和遵守(你也可以說是死板)，超過了我的想像和期待。 我舉幾個簡單的例子: 1.估時程:我常常看到，為了爭取到某一個案子，在時程評估的時候，就已經放棄架構了，我們給了客戶一個若要遵循架構就根本不可能達成的預計完成時間。 2.當進度落後:當進度落後的時候更慘，本來SA,SD花時間想好的架構，可以因為進度理由一夕之間失效，更有趣的是，這個架構可能是先前花了兩三個月決定的，但是Developer+PM可以在一天內推翻。 3.當客戶要求不合理:一樣的狀況, 有時候客戶會有一些超越常態或是超越技術可能性的要求，為了成案，往往PM答應的莫名其妙，而怪的是，最後還是可以做得出來，天知道這後面隱藏了哪些可怕的東西。 剛講到MVC和所謂的規範，可能很多人對我說的 "規範" 的定義不清楚，舉個ASP.NET開發人員應該要知道的例子，有幾個我所謂的規範簡單的具體例子就是: 1.ASP.NET頁面(.aspx和.aspx.cs 或.aspx.vb)當中，不得有ConnectionString or SQL指令。(你應該寫在一個表(不管是資料表或是對照表)當中，以便於後續維護。(但是，誰敢說自己的.vb或.cs中沒有SQL指令碼?我看是一堆吧...) 2.ASP.NET程式碼當中不該有商業邏輯，只能有處理UI的Code, 也就是說，你應該要有一個Business object。 3.超過100行的Method或Sub, Function 應該再切割。 類似像上面這樣的說習慣也好, 說規範也行，是不應該被打破的，但是，有多少因為時程關係而破壞規範的例子? 多的慘不忍睹...

今天在公司開會的時候，一位作者好友透過MSN通知我Scott的BLOG上果然開始出現了Silverlight 3的消息，我一聽不得了，第一時間看了Scott的BLOG，大意是說，Silverlight 2在今年推出正式版之後，在一個月內，已經有超過100 million(哇哇，超過一億? 會不會太誇張??? 應該是很多機器overlap的重新計算了吧，像是我，至少裝了30次)機器安裝了Silverlight 2(不過，聽起來微軟好像對這個數字很爽的感覺^_^)。 而且，還有很多Sivlerlight 2使用在產品中的真實案例(嘿嘿，當然，內舉不避親，其中我覺得最重要的，就是K2的blackpoint，如果有人對這個產品有興趣，可以跟我聯絡)，足以證明Silverlight 2是一個可以真實應用的開發工具。 接著Scott趁勝追擊的說，將在next year推出下一個版本的Silverlight 3，令人興奮的部分是，在大家開罵了很久之後，終於，終於，可以在Visual Studio和Visual Web Developer Express當中以所視即所得的方式設計Silverlight了，Data Binding的部分也有工具(Wizard)可以設定，而不需要手動去下Code(剛好這件事情就是那天去參加好友的seminar後，在路上和他討論的問題，嘿嘿，沒想到他還真有先見之明)，另外加上對3D的支援，以及對H.264 video格式的support...總括一句話，就是功能越來越強就對了(老實說，就是Silverlight的WPF化)，然後Scott暗示大家趕快投入開發的行列，因為早晚有一天，Silverlight會把Fl?x幹掉(後面這句話是我自己加的...^_^) 看了這一篇BLOG之後，我挺有感概，技術變化得太快了，對於寫書的作者來說，會不會是一個很大的打擊呢?Silverlight 1.0的書才剛出，Silverlight 2.0就馬上Beta 1，現在Sivlerlight 2的書還沒出，馬上就有Silverlight 3的消息，是怎樣?拼進度嗎? 回頭想想，到底是哪個環節出問題? 是外國人太快，還是我們太慢? 老實說，我相信大家都沒什麼內幕消息，而且現在到處都是BLOG，訊息非常透明，要有秘密也不容易,也就是說，這些Roadmap是大家早已知道的，而且三...

　　在軟體業待了那麼多年，也做了不少的案子，當過甲方、也當過乙方，回顧過去，大小案子不少，但是有沒有哪一個案子直接跟客戶的獲利有關? 好像有，但是不多... 　　我們說服客戶買單的幾個重要原因(或是客戶找你買軟體、作專案的幾個重要原因)不外乎如下： 1.希望用了你的軟體之後，能降低營運成本 2.希望用了你的軟體之後，能提高效能(或產能)，或是加快工作速度 3.希望用了你的軟體之後，能解決特定問題 4.不得不買，因為舊版的軟體過時或太爛 5.對未來的願景有所期待，典型的狀況就是聽了很多電腦化的優點之後，老闆下定決心，將公司全面電腦化... 6.預算太多，消化一下 　　先不管上面這些期待(或是原因)是否合理，還有在導入軟體正式上線之後有沒有真的發生，你會發現，就算真的都發生了，也很少能夠幫客戶賺錢，最高最高的效益大概是幫客戶省錢。 　　沒錯啦，廣義的來看，幫客戶省錢也是某種程度的賺錢，特別是這麼不景氣的時候。 　　但是這也表示，客戶並非非要你的軟體不可，它不是無可取代的，不是不可或缺的，在企業軟體當中，乍看之下似乎並不多能夠直接幫客戶賺錢的軟體或專案，幾個在軟體界常聽到的解決方案：ERP、EIP、CRM、PLM、BI、DSS、SCM...等，絕大部分的軟體都是以節省企業成本的角度來考量，而非幫企業提高獲利。 　　但是回過頭來看，節省成本這件事情有點吊詭，因為公司在短期間內不太可能因為買了你的軟體或導入你的專案，就立刻降低成本(例如因為工作效率提高了，所以把公司的員工fire掉一半，所以財報上看不出效益，頂多生意可以越做越大...但是財報上短期間還是看不到效益)，反而會因為要導入新軟體，可能會增加工作量、聘用很多臨時性的工作人員，這又是一筆開銷... 　　等到軟體導入一兩年後，差不多可以幫助企業省錢(獲利)了，卻很少數據可以清楚的顯示，這一來一回之間，企業到底要花多久的時間才能換回當初的購置成本? 而軟體的變遷如此迅速，客戶的需求也如此多變，兩三年後這套軟體又要重新購置或是調整，企業是不是賺錢和到底是不是與導入了我們的系統之間有正相關，似乎很難得到一個正確的判斷... 　　是不是因為這個原因，所以我們也很少看到軟體廠商提出數據來佐證，因為XXX客戶導入了我們的產品，所以今年的業績成長一倍...或是YYY公司買了我們的軟體，所以今年EPS多了一塊錢...或是ZZZ公司成功導...

從事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，我待會解釋) ...