2017年12月31日 星期日

系統思考 - (11) 九大基模之投資與成長不足

圖片來源:Masarrat

9. 投資與成長不足 (Growth and Underinvestment)



描述

公司或個人的成長接近上限時,可以投資在”產能”的擴充上,以突破成長上限,但是這種投資必須要積極,並且必須在成長降低前,否則將永遠無法做到。

早期警訊

我們過去一直都是最好的,我們將來還會更好,但是我們現在必須儲備資源,不要過度投資。

管理方針

如果的確有成長的潛能,應在需求之前儘速擴充產能,為創造未來需要的一個策略。


投資與成長不足的CLD

下圖是投資與成長不足的CLD,我們可以觀察到左邊其實就是成長上限CLD,而要突破成長的上限則取決於右邊的投資是否能即時投入,否則終究會遇到成長的上限,甚至走向衰敗。




投資與成長不足就讓我想到磨斧頭的故事,一個年輕樵夫一直很努力的在砍樹,而他越努力的確砍的樹就越多,但是隨著時間,斧頭鈍了,砍樹的效率就越來越慢,另一個老樵夫問你怎麼不停下來把斧頭磨一磨呢?(投資),年輕的樵夫說我沒時間,我得更努力砍材....:P

系統思考 - (10) 九大基模之公共資源的悲劇


8. 公共資源的悲劇( Tragedy of the commons)

描述

公共資源的悲劇主要是從經濟學發展出來概念,當許多個體基於個別需求,共同使用一項很充裕,但有其極限的資源。起初,他們使用這項資源逐漸擴展,並且產生”增強環路”而使成長越來越快,但後來他們的收益開始遞減,且越努力,成長越慢。最後資源顯著減少或告罄。

早期警訊

過去充裕的情況如今以轉困難,我們必須更加努力已獲取利益

管理方針

透過教育,自我管制以及同儕壓力,或透過一個最好是由參與者共同設計的正式調節機制,以管理共同的資源。

系統思考 - (9) 九大基模之富者愈富

圖片來源:chronicle

7.  富者愈富/ 競爭排斥 (Success to Successful)


描述

兩個同時進行的活動,往往會因為有限的資源而競爭,這時只要有一個表現比較好,就會開始爭取到更多資源,產生正增強環路,同時排擠到另一邊產生負增強環路。

早期警訊

兩個使用同一資源的活動同時展開,其中一個蒸蒸日上,另一個則陷於掙扎求生的狀態

管理方針

針對共同享用資源的分配時,除了績效表現,也要考量整體均衡發展的更上層目標,有些狀況應該要將”同一”資源予以”區分”規劃,以減少不必要的競爭。

競爭排斥CLD

主要是由兩個互相競爭搶奪資源的增強回路組成,一邊增強就會削弱另一邊。



競爭排斥的範例:

在這邊我想到的一個範例就是工作與家庭,很多時候沒有所謂平衡,只有取捨,如果你把時間投更多工作,你再工作的表現可能會更好,進而會需要投入更多的時間,漸漸的在家庭的時間就減少了,而在家庭的時間減少,容易造成家庭失和更可能會讓你更不想待在家裡,花更多時間在工作上。






2017年12月29日 星期五

系統思考 - (8) 九大基模之競爭升級


6. 惡性競爭/競爭升級 (escalation)


描述

不論組織或個人為了勝過對手,造成產生對立情勢高聲的惡性競爭。

早期警訊

要是我們的對手慢下來,那我們就能停止打這場仗,去做其他事情

管理方針

尋求一個雙贏政策,將對方的目標也納入自己的決策考量。


競爭升級CLD






惡性競爭範例:恐怖組織威脅美國 (北韓 vs 美國)





另外常見的就是殺價競爭,兩間公司為了搶生意而不停的殺價競爭,為了就是等對方先倒下來...


系統思考 - (7) 九大基模之目標侵蝕

圖片來源:adamlowellroberts


目標侵蝕(drift to low performance)


描述

由於目標與現狀產生了差距,人們為舒解此一差距所帶來的壓力,可能有兩種方案;一是調整目標,另一則是採取行動來改善狀況,以迎合目標。通常人們慣於降低目標,而造成其目標逐漸腐蝕。

早期警訊

這個問題,只要我們把標準降低一點,就可以暫時應付過去,以後再嚴格一點,應該沒有問題。

管理方針

堅持目標,標準和願景


目標侵蝕CLD

通常遇到問題的改善方案都會有兩種,難的跟簡單的,而治本的方法通常都是難的,許多組織為了先快速解決問題,往往會選擇降低標準,最常聽見的就是先求有再求好,然後就標準一去不復返~XDrz...




目標侵蝕範例:軟體品質

為了讓產品可以更快release,更快上線,你願意拿什麼來交換呢?你願意附上多少的代價呢?(默默拿出工程師百寶箱)






2017年12月24日 星期日

系統思考 - (6) 九大基模之捨本逐末




捨本逐末 (shifting the burden)


描述

解決問題通常有兩種方法:快速治標,和長期慢速治本兩種方法,而使用一個治標的方法來解決問題,短期內可以快速見效,但是如果這種方法使用越多,一段時間後甚至會弱化侵蝕根本解的能力。

早期警訊

這個解法一直都很有效,為什麼說繼續下去會有問題?

管理方針

將注意力放在根本解,但是如果問題急迫,根本解會受到時間延遲的影響,在進行根本解的過程中,可以暫時搭配快速解來緩解症狀。



在捨本逐末的CLD中,其實跟上一個飲鴆止渴模式很類似,可以看到上下了種解法都可以解決問題,但是如果選擇了快速解就會產生副作用,甚至降低了根本解的可能性。


範例:



最常見的就是團隊中得危機英雄,當專案產生危機,許多公司都會靠公司裡面的英雄人物去救火,而不會想辦法強化團隊處理的能力,長期倚靠英雄救火久而久之團隊的能力就被弱化,也更無法靠團隊了力量去解決專案危機。




2017年12月16日 星期六

系統思考 - (5) 九大基模之飲鴆止渴


飲鴆止渴 (fixes that fail or fixes that backfire)


描述

一個對策短期有效,但是長期而言會產生越來越嚴重的後遺症,使問題更加惡化,也會對這個短期對策產生難以自拔的依賴。

早期警訊

這以前都有用啊,為什麼現在不靈了?

管理方針

眼光聚焦在長期焦點,如果可以的話甚至要完全摒除短期對策。除非短期對策只是用來爭取時間,用來尋求更妥善的解決方案。


範例:加班


飲鴆止渴算是最容易看到的基模,以加班為例,為了趕專案進度,大家最直覺的想法就是加班,透過加班的衝刺,短期內可以看到逐漸趕上專案進度,但是長期的加班卻會延遲的降低士氣低,最終還是會影響到專案進度。


進階閱讀

到目前為止我已經介紹了兩個常見的基模,現在可以來挑戰看呂毅老師的blog,裡面有提到許多看起來更複雜的案例,不過也不脫這兩個基模:

第一篇是透過CLD探討 sprint 與flow 模式的差異(其實就是scrum 與 kanban),呂毅老師從兩個面向來討論,第一個是透過價值傳遞的面向,在下圖中就可以看到 成長上限基模 (R1 & B1)。這個問題其實我們也遇到過,一直嘗試要把sprint 縮短,把Story size 切割,想要能盡快的交付產出,但是其實這是有極限的,因為還是得累積到一定的story 才能真得對客戶產生價值。


Organize time - sprint vs flow - 1.png

第二個案例探討的是持續改善,同樣是B搭配R的環路,一邊(B2 & R2 )是設法持續改善,一邊卻是進入飲鴆止渴模式(B2 & R3),差別在哪裡?差別在於什麼是長期解決的方法?什麼是短期解決的方法?什麼方法可能會產生副作用?


Organize time - sprint vs flow - 2.png


2017年12月14日 星期四

系統思考 - (4) 九大基模之成長上限


成長上限(Limit to Growth)

描述

一個會自我繁殖的環路,產生一段時期的加速成長或擴張,然後成長開始慢下來(系統裏面的人常未察覺),終至停止成長,而且甚至可能加速衰敗。

早期警訊

我們越是努力的跑,但是似乎都在原地踏步

管理方針

不要去推動增強環路,應該要除去限制來源

範例一:團隊成長



在這邊舉的例子是團隊的成長,首先我們先來看左邊的增強環路,當團隊產能越高,越有機會做出出色的產品,而做出出色的產品會帶動士氣,讓團隊做出信心更有產能,這是一個正向循環的結果,不過反之亦然,如果團隊產能越低,越難做出出色的產品,進而影響信心造成團隊產能低落。

接下來我們來看右邊的平衡回路,理論上加人不是應該會增加產能嗎?但這時有加入右上角的限制條件 - 文化衝突,當一個團隊沒有辦法好好處理文化衝突,和幫助新人融入這個團隊得時候,你加入越多人,其實只是造成團隊的混亂甚至會降低團隊的產能,而團隊產能更低時,團隊就越沒籌碼加人,或者也可以解釋成團隊就也不會想加人,因為加人沒好處。


這個時候的解決方法並不是處理左邊的增強環路(做更出色的產品,新的產品線),而是應該要來處理限制條件,如何降低文化衝突,讓新人更容易融入團隊,減少摩擦。


這個觀點其實在 Effective Engineer 這本書裡面也有提到,一個Effective 的工程師要專注在槓桿大的工作(也就是CP值高),其中幫公司建立一套完善的 on boarding program 來培育新人,幫助新人就是其中一個高CP值的工作。如何有效幫助培養新人,解決文化衝突的問題,就會是團隊能不能成長,產能是否能提高的重要限制。


ps. 其實在上面文字推導時發現為了能解釋CLD有多加了許多解釋,這可能就代表圖中得元素可能有少,把太多元素聚合在一起,這也是在畫CLD圖常會遇到的問題之一




2017年12月9日 星期六

系統思考 - (3) 九大基模之反應遲鈍的調節環路



系統基模是從系統動力學的各系統模式中提鍊出重覆發生的現象與結構,基模可視為最基本的系統思考工具,主要是由多個正負環與滯延所組成,接下來幾篇會依照第五項修練中提到的順序介紹九大基模,書中介紹的順序分別會是文字描述,早期警訊和管理方針,但是光看這些文字是不太足夠的,所以我會嘗試多加一些案例說明。

鳳凰項目沙盤推演特別版


今天終於拿到鳳凰項目沙盤特別版,其實就只是多了20幾頁,內容是講述沙盤推演版的遊戲目的要讓參與這可以體驗什麼和希望他們可以學習到什麼,不過衝著裡面還有我們參加活動的照片就一定要買來支持一下啊XD



2017年12月4日 星期一

系統思考 - (2) Causal loop diagram


 圖片來源:系統思考 (System One)

要學習系統思考,我想最大的障礙之一就是畫CLD (causal loop diagram)圖, 因為不是論是第五項修練系統思考 (System One) 還是 系統思考 (Thinking in Systems: A Primer) 通通都沒有針對這塊詳細解釋,裡面雖然有出現CLD,但是都沒有符號,也沒有解是要怎麼判斷是平衡環路還是增強環路,於是你會看到一堆沒有符號的 CLD圖,然後看著一頭黑人問號,雖然透過書中描述的文字可以推敲出可能性,但是很難讓人快速辨識出來,如果遇到下面書中的案例應該就整個傻眼了。



2017年12月3日 星期日

系統思考 - (1) 什麼是系統?



跟據軟技能的十步學習法提到,真得想要學會一個技能,就要去用他,去整理他,去教他,剛好最近集團內的Tech Sharing 輪到我,所以還是硬著頭皮來整理什麼是系統思考,希望藉此能更深入的瞭解,不過根據分享後現場的反應,我應該是講得太無趣,舉的例子也不夠活潑生動貼近現實,所以無法取得共鳴吧...Orz..

系統思考很重要,但是什麼是系統?要如何思考?其實就算看了以下三本書,我還是覺得懵懵懂懂得。

構成系統三要件

元素,連結,和目標(功能)。而目標是最不容易察覺,卻也影響系統最深的。




元素的種類分成存量和流量,在分享中有同仁直接引用系統動力學和數學的角度來討論,流量其實就是存量的微分(距離---> 速度--->加速度),這時候就會出現一個很有趣但是我也還不知道的答案,速度在一次微分時算是流量,但是在二次微分時,又會變成存量? 可以這樣解釋嗎?還是說流量應該只限於一次微分?




在投影片中我舉了幾個例子又引起了一個討論,關於廣告營收與點擊率的關係,營收究竟是存量還是流量呢?而點擊率只會間接影響營收,所以嚴格來說不能算是營收的一次微分(營收率?),畢竟系統思考算是系統動力學的簡化版,需要套用這麼嚴格的定義嗎?老實說我也不清楚。




不過很肯定的是系統思考所討論的系統是屬於回饋環路系統,也就是系統過去的行動結果會進一步影響未來的行動,如此一來才有改善的空間,這也是為什麼學習Agile 方法的人都需要有系統思考的思維,因為每個sprint 做的改變,都是會影響下一次的結果。




所謂的回饋環路系統包含四種元素:
  • 目標(決策)
  • 資訊(與目標的差距)
  • 狀態
  • 行動

由這四種元素就可以用來描述一種動態的行為,而系統思考就是透過這四種元素的組成去討論系統內發生的問題,以及該如何解決。接下來我會嘗試用幾篇文章分別介紹系統思考常用的 CLD (causal loop diagram),以及系統九大基模。

後續文章:







2017年11月26日 星期日

DevOps HandBooks - 第三章 The Second Way 建立安全的反饋機制



如果組織中有許多明顯的狀態(錯誤),但是大家都視而不見,或是明明都看到了卻都不敢說,這時候組織就是已經處於一種很不好的狀態,也就是一個問題因太過於龐大或麻煩,導致沒有人願意去碰,因此在 DevOps handbooks 裡的 second way 提到要建立快速且安全的Feedback loop ,其中舉的例子就是 Toyota Andon cord ,也就是當任何工作站的任何環節發生問題需要協助或是有異常狀況,該工作站的工人可以拉下警報器,整個工廠就會停止運作,直到team leader 協助解決問題。

核心概念:Keep pushing quality closer to the source

套用到軟體開發場景,可能是開發當中發現需求不明確,發現之前設計的瑕疵(or Bug),甚至是 production 上發現異常數值,異常狀況需要人排查甚至修復,那問題來了,這種中斷和干擾是 Scrum team 最不樂見的,那 DevOps 是否跟 Scrum 有衝突? 如果不是那該如何搭配呢?

更多討論可以參考在Scrum Community in Taiwan 的討論串,其中Steven 給的comment 我很喜歡:





2017年11月22日 星期三

如何從舊錢包領Bitcoin Cash

圖片來源:techcrunch


今天剛好在PTT 上看到這篇文章,特別感謝PTT網友:sweetorz 教學

教學適合對象:原本使用 Electrum 儲存BTC的朋友

步驟:

  1. 安裝個 BCH 錢包 (Electron Cash Wallet)
  2. 把你的 BTC 錢包 (Electrum Wallet )先轉到另一個錢包地址
  3. 備份原來的 BTC 錢包
  4. 開啟新安裝的 BCH 錢包軟體,匯入剛才備份的 BTC 錢包檔案
  5. BCH get


以下是使用 Ledger Nano S 錢包(Facebook 社團),用來存BTC/BCH 的步驟範例,適合使用Mac的朋友:

  1. 備份 Electrum#> cp -r ~/.electrum  electrum-bak
  2. 登入 Electrum
  3. Electrum 轉帳到 Ledger Nano S 的 BTC 錢包地址( 選 SEGWIT 鏈 ),並等待一個以上的交易確認
  4. 安裝 Electron Cash Wallet#> brew cask install electron-cash
  5. 匯入備份的 Electrum 錢包(electrum-bak/wallets/default_wallet)
  6. Electron 轉帳到 Ledger Nano S 的 BCH 錢包地址( 選 SPLIT 錢包 ),並等待一個以上的交易確認

Ps. 我的情況是分叉後剛好也是把Electrum 的BTC轉到Ledger Nano S,並沒有留意還有BCH可以領,但是Electrum 的錢包還存在,所以看到PTT上的討論喜出望外~XD


領到錢趕快到CEX去把它兌現吧!! 或者是再換成BTC (股利再投資計畫)也不錯~XD





2017年11月19日 星期日

一流的人讀書都在哪裡畫線?商業人士該讀的八大類書籍



一流的人讀書都在哪裡畫線? 什麼是一流的人?翻譯的原文是 "elite person",也就是所謂菁英,而作者所謂的菁英就是商業人士,所以這本書真正的書名應該是,商業人士該怎麼麼讀商業書籍。

這本書開宗明義也說道,讀書的目標不是在一年要讀多少書,而是讀了這本書有沒真得讓你有收穫,甚至只要有一具有用的話就能讓你獲利,唉壓~菁英商業人士還真得是將本求利,畢竟時間就是金錢阿朋友~XD


選書十一招

  1. 經理人類的書,作者要挑創辦人或中興功臣
  2. 從"作者簡介"分辨有沒有本事
  3. 作者要選"一流的變態"
  4. 向"顧問"取經準沒錯
  5. 別挑"門外漢"寫的書  --->也就是名嘴
  6. 不要被"書名"欺騙
  7. 選"專有名詞"較多的書
  8. 如果前幾頁就值得畫線,買了
  9. 書本要有大量的"資料"佐證  --> 就像論文要有Reference,代表言之有物
  10. "翻譯書"的好書機率較高
  11. 注意"條列內容"  --->這就是我正在做的事

作者提出來的十一招,我覺得的確蠻適合日本的場景,日本市場不小,每年出版的書非常多,所以書的品質差距就會很大,而其中比較熱門的才會翻譯成中文,不過就連這些較熱門的書中有需多看完就會覺得很"浮",也就是包裝精美,標題吸引人,但是內容看下去就覺得soso。比起來翻譯書還是看美國的好書機率更高,尤其是Amazon評價高的。


商業人士該閱讀的八大類書籍


作者把商務人士該閱讀的書籍分成八大類:

1. 會計金融
2. 策略
3. 行銷
4. 營運
5. 管理與領導
6. 商品研發
7. 統計
8. 經濟

那重新分類一下 2017年的書單,主要都集中在哪些類別呢?

1. 會計金融

2. 策略


5. 管理與領導


6. 商品研發

8. 經濟


作者有提到,不要寫書摘式的書評,而是應該從收穫,就算只有一行畫線,但是對於記憶力差的我來說,應該還是得想辦法把一些東西留下來,過幾年後再來看,也許會不同的收穫:
  • 原來我看過這本書 ^^||
  • 原來當初我是這樣想的

2017年10月27日 星期五

網路效應與路徑依賴,談為什麼要推廣敏捷文化



為什麼有這麼多大大努力的到處推廣敏捷文化呢?不是自己公司搞好就好了?何苦到處找人分享和討論呢?為什麼要辦那麼多活動呢?有些人不能參加活動,又為什麼要在網路上鍵盤推廣敏捷呢?(咦?) 在探討這些問題前,我們先來瞭解兩個經濟學的名詞:網路效應路徑依賴

2017年10月16日 星期一

薩提爾與麥肯錫菁英的思考習慣如何解決負面情緒



麥肯錫經營的思考習慣 這本書中主要在講如何避免在面對高強度的壓力下產生負面情緒,裡面提到了情緒 ABC:

A (起源事因) —> B (信念) —> C ( 情緒與行為)
A 是既存事實不會導致 C
真正促成C 的是B


而負面情緒則是由錯誤的堅定信念所產生,這在薩提爾的鬆動核心觀點(信念)有提到,對應的核心觀點的keyword就是:
  • 永遠應該怎樣 ...
  • 這必須怎樣... 
  • 一定得怎樣...
而書中建議的就是,從必須型思維變成願望型思維(有時也可以,不是絕對的,希望可以達到..)
如何從“必須型”轉變為“願望型” 五個步驟:

第一步,要肯定你的願望或者目標是有重要價值的﹔
第二步,要去否定絕對的要求,但它不是必須要實現的﹔
第三步,要考慮多種結果的可能性﹔
第四步,現實地評價壞的結果發生的情況﹔
第五步,就是盡最大的努力去實現最好的結果。


這與薩提爾的教練策略不謀而合:
  1. 觀察不尋常(有盲點)的行為模式
  2. 詢問/反映行為模式背後的核心觀點
  3. 探索過去學習的經驗
  4. 肯定此觀點"過去"對夥伴的價值
  5. 探詢此觀點"現在"對夥伴的意義 (想法/情緒)
  6. 詢問夥伴是否想改變
  7. 引導夥伴探索改變的第一步
  8. 讓夥伴整理鬆動核心觀點得時機 

差別在於薩提爾是在幫助夥伴改變,而本書的思維是幫助自己改變思維,進而遠離壓力下產生的負面情緒。



2017年10月10日 星期二

從法律經濟學的責任監管問題談 DevOps 間的關係



這題目是不是看起來有點太高深了,怎麼還可以跟DevOps扯上關係?

會有這樣的聯想,主要是啟發自薛兆丰的北大經濟學 - 法律經濟學單元,談論的主題是責任與監管問題,聽完的當下就突然覺好多東西似乎都可以用法律經濟學的角度來分析與解釋,因為在現實世界中很多東西都是 Tradeoff,不是非黑及白,但是總還是得做出判斷和抉擇,這時候法律經濟學的一個重要作用,那就是通過經濟分析,給我們的決策者提供可行性方案的比較和選擇。

[引導型敏捷領導力課程] 談管理、領導與追隨



趁著假日陸續整理和和消化之前上課的筆記,有許多東西值得好好回味和思考,話說引導型敏捷領導力課程的第二天,我們談到了管理(Management),領導(Leadership)與追隨(Follow hood),前面兩個詞相信大家一定都不陌生,畢竟這就是我們想學習的東西,但是追隨呢?到底什麼是追隨,在討論中我們不時的把追隨想成追隨者,也就是有人領導就要有人追隨,但是在一個Autonomy 的組織中誰是領導者?誰要追隨誰?如何追隨?怎樣算是好的追隨?

DevOps HandBooks - 第二章 The First Way 流程的原則



鳳凰專案這本書中一直提到卻沒有詳細說明的三步法(不知道翻三扳斧如何XD),作者故意留到DevOps Handbooks 這本書才詳細說明,這就是傳說中得埋梗。

第一步: 流程的原則 (the principle of flow)


所謂的流程談論的就是如何有效率的傳遞價值流程( Value Stream):也就是從 Business 端產生想法和需求,到 Customer 真正使用並且給予回饋(不論是金錢或是評價),所以第一部流程的原則就是減少 lead time,也就是減少從需求到部署商轉的時間。

書中整理出優化流程的步驟,也是我們每天努力改善的項目:

1. 把工作視覺化 

2. Limit WIP


這兩個步驟應該不用多說,之前在鳳凰項目沙盤推演 workshop 遊戲流程也有提到,想要深入瞭解可以參考"看板實戰"。

3. 減少Batch Size (single piece flow)

4. 減少工作移交的數量



圖片來源:The DevOps HandBooks


所謂Single Piece Flow 翻成白話文就減少批次處理的量,最好是一次做好一件事,只要做到這點就能減少工作移交的數量,越多工作移交的數量,就會需要更多的溝通和更多的文件。


5. 持續找出並鬆綁瓶頸


這也是鳳凰專案中不斷引用高德拉特博士的移除瓶頸的聚焦五步驟

1. 找出系統的制約因素
2. 決定如何利用系統的制約因素
3. 根據上述的決定,調整其他的一切
4. 把系統的制約因素鬆綁
5. 加入四打破了原有的制約因素,回到步驟一


既然第一步是要找出制約的因素,作者也幫忙列出 DevOps 常見的瓶頸產生處:
  • 環境建立 (不管是開發和營運環境)
  • 程式部署 (程式從git 拉下來到部署到Production 需要多少時間?)
  • 測試建置與執行
  • 過緊密的架構

消除價值流中得困難和浪費


除了瓶頸外,在整個價值流中處處都可能藏著浪費,等著我們找出來消滅:

  • Particaly Done Work(開發過程中的半成品,甚至是等待review 的工作)
  • Extra Processes(對於客戶與開發沒價值的SOP/文件/簽核)
  • Extra Features(傳說中得 Over Design和 Gold plating)
  • Task Switching(萬惡的Content Switch)
  • Waiting(等待指示或簽核,等待資訊,等待誰同意....)
  • Motion/ Handoffs (工作交流和換手的過程一些資訊很有可能跟著遺失或變質)
  • Defects(不正確/遺失/不清楚的資訊和產品產生,從發現到解決拖的越長越浪費時間)
  • Nonstandard or Manual work (工程師都知道重複做超過三次的東西都該自動化~XD)
  • Heroics    

最後一點 Heroics (action that is dramatic)特別值得拿出來講,書中舉的例子就是為了達成組織的某個(恐怖的)目標,某些人或某些team 必須承受一些不合理的行動,而這些動作甚至會變成他們每天的工作,每次半夜兩點部署新的程式到Production ,都會產生一堆新的ticket 要處理(那變少測試,那邊要微調,那邊忘了升級,那邊配合人員沒通知....)

結論


瓶頸和浪費不會消失,但是希望可以透過視覺化的方式加速發現的過程,並且透過系統化的方式減少甚至消滅這些浪費。這時候就要透過第二步 Feedback 來幫忙。

謎之音


要注意!上面輕描帶寫的列出許多要改進的地方,要注意的事項,但是隨便一項就可以做到死,要怎麼從Day1 就把這些概念Build in 在日常的開發中就是硬實力,不是靠嘴巴講出來的,是要靠做出來的。這也是為什麼直到Docker出現後,DevOps 的議題才如烈火燎原般燒開,他從根本解決了許多瓶頸,有興趣可以參考這篇文章: Docker and the Three Ways of DevOps Part 1: The First Way – Systems Thinking





2017年9月30日 星期六

超級數字課後心得



話說一直以來我對於財務報表都有著錯誤的觀念,以前會想瞭解財務報表都是因為玩股票,一開始都會從基本面分析開始,無奈怎麼看都是有看沒有懂,就算努力瞭解了每個科目單獨的意義,但是卻沒有辦法拼湊出一個全面的資訊,於是就會產生阿反正這都是落後指標,財報好股價也不一定好的錯誤歸因,於是要會閱讀財報的需求就消失了。

直到成為主管,常常得在會議中討論營運數字,需要透過數字拼湊公司營運狀態,這時候封陳已久的閱讀財報表需求再度浮現,剛好去年在網路上聽到MJ老師的課程多厲害多火紅,就一直很想報名,無奈課程每次一開出來就秒殺,只好先買本老師的書:用生活常識就能看懂財務報表這本書,然後在網站填預約單,如果有開課會第一時間通知,這次終於給我報到超級數字台北39班了!!

首先的反思與意外的收穫是什麼?

財報和基本分析不是用來看這個股票會漲會跌,也不是用來看進出場訊號 (勉強算逃生訊號),財報和基本面分析只是用來判斷這個公司值不值得"投資",或是更嚴格來說是這間公司在這個產業值不值得"投資"。

2017年9月24日 星期日

軟實力 (Soft Skills) 十步學習法



軟技能 (Soft Skills) 在書中提到了十步學習法,步驟分別是:

1. 瞭解全局
2. 確定範圍
3. 定義目標
4. 尋找資源
5. 創建學習計劃
6. 篩選資源
7. 開始學習,淺嘗輒止
8. 動手操作,邊玩邊學
9. 全面掌握,學以致用
10. 樂為人師,融會貫通

而我們又可以把這十步分為兩個階段,上半階段 1~6 屬於計畫階段,只需要做一次,而關鍵的重點流程則是 7~10:LDLT (Learning,Doing,Learning,Teaching)

計畫階段,其實最容易讓人迷失在茫茫資訊海中,所以我覺得還是透過Udemy 或是 Coursera 這種有系統性的教學,大概幫你準備好1~7的階段。

而7~10 這是一種iteration 的概念,透過邊學,邊做,邊教,才可以讓自己真正的學會,這時候我的感想就是加入一家對的公司對你最有幫助,你一天有三分之一的時間會再公司工作,如果在公司能有機會讓你不斷學習,實證,順便教人,這才是讓能力提升的最佳途徑,如果妄想在下班後利用自己得時間來努力,真得是會事倍功半。


這本書裡面介紹提到可以去他網站 (https://simpleprogrammer.com/ss-10steps) 看視頻,結果又是一門要價99USD的課,書其實只是宣傳品,網站賣的課程才是主力收入,這值得我們好好學習~XDD

2017年9月17日 星期日

薩提爾教練模式 - 教練與顧問的差異


在正式開始上課前,其實有很多東西都需要先釐清和定義清楚,剛好這點也是我覺得之前很容易搞混的,我們從外面請來的到底是顧問還是教練?然後應該預期得到什麼結果?


顧問和教練有什麼差別


2017年9月16日 星期六

薩提爾教練模式 - 主管的三頂帽子

圖片來源:dreamstime

其實去年就已經看過 激發員工潛力的薩提爾教練模式這本書,不過看完後的感想是好神奇,但是好難做到,有蠻多實行細節的疑問,剛好今年陳茂雄老師的薩提爾教練模式工作坊再度開班,在敏捷社群的老司機們揪團下立馬去報名,希望趁著這次工作坊能讓我對於薩提爾教練模式有更深一層的瞭解。

趁著剛上完課,趕快整理一下上課筆記,把適合分享出來的部分分享出來,所謂適合的部分就是解決我對書中得疑問的部分,不適合的部分則是需要透過老師實地演練的部分,因為就算我分享出來,可能對於大家不會有太多幫助,因為老師也有說:

  • 成人教育首重"體驗”(自己的經驗),這會比說服更有說服力,比解釋更容易記住
  • 要有疑問才會有收穫
剛好我帶著滿滿的疑問去上課,也帶著滿滿的收穫回來~

2017年9月10日 星期日

[教學] 如何在 Centos 7 上也能透過 MinerGate 挖其他虛擬幣



MinerGate 是我看了好幾間裡面,算是支援最完整,又簡單上手的,首先它支援在Linux 環境的 CLI 指令,可以很方便的部署到Server 上運作,甚至可以直接包成Docker image,此外提供各平台的GUI 介面的挖礦軟體,甚至手機上都有(這算力有用嗎....XD)
有興趣的可以參考以下資料:

在本篇文章,另外補充如何在Centos 7 上安裝MinerGate的 client。




2017年9月3日 星期日

鳳凰項目沙盤推演 workshop 遊戲流程



話說這本鳳凰項目 - 沙盤特別版在市面上買不到,只有授權的原廠才有賣,在開始介紹遊戲流程前,先解說一下這個遊戲的由來:

鳳凰項目 DevOps 沙盤是由歐洲著名沙盤遊戲研發機構 Gaming Works 的創始人 Jan Schilt 先生聯手《鳳凰項目》一書的作者 Gene Kim 先生,開發的同名沙盤演練課程。  鳳凰項目沙盤演練覆蓋了業務場景中所有的職員角色,尤其是那些從事 IT 開發以及 IT 運維工作並希望通過精益(LEAN), 敏捷(AGILE)和 IT 服務管理流程如(ITIL®)等最佳實踐來提高 IT 服務表現或通過 IT 解決方案為業務創造價值的 IT 專業人士。該沙盤同時也是為那些通過創建更好的協作氛圍並最終實現更高效以及更精確的 IT 解決方案部署的企業。


延續上一篇 -  鳳凰項目沙盤推演 workshop 感想,在這邊我先大略描述一下遊戲的內容與大致的流程,遊戲設計的角色,以及要做的工作。