2017年12月9日 星期六

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



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

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),以及系統九大基模。

第二篇:系統思考 - (2) 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 感想,在這邊我先大略描述一下遊戲的內容與大致的流程,遊戲設計的角色,以及要做的工作。

2017年9月1日 星期五

鳳凰項目沙盤推演 workshop 感想


原本想要下的標題是 "紫衣教" 老司機們團報踢館鳳凰項目沙盤推演 workshop ~XD


話說這次參加鳳凰項目沙盤推演 workshop 的成員組成,除了少數不知道怎麼被拐來的人(還是有人連鳳凰項目書都沒看過就被拐來),大部分的都是敏捷界的老司機,粗略估算一下組成和經歷:
有參加過這幾種課程培訓的,參加這種workshop 根本就是小菜一盤,首先的起手式就是把工作視覺化,一開始就透過 Kanban 來安排工作,甚至還不斷的演進,每一輪都更新我們看板的格式,為了就是讓工作更加順暢。

2017年8月18日 星期五

【當個無能力的學習型主管】




【當個無能力的學習型主管】
當部屬的時候總是希望上司是個全能型的主管,一個智者的角色,不管任何疑難雜症都可以請教他,他總是會適時的提供指引和好的解決方案,有這種人的存在嗎?當然有!而且還不少呢,因為很多主管都是從自己最擅長的領域被升上去的,原本可能就是頂尖工程師,Top sales,最有創意的行銷人員...
那這樣問題在哪里?就是他會很累,下屬的成長也可能有限,他很可能會變成組織成長的天花板。

2017年8月10日 星期四

[經驗分享] 使用 Changelly 刷卡買以太幣/比特幣



這陣子都是用 minergate + changelly 的組合再做交易

只要有一般電腦,就可以透過 minergate 挖一些次等貨幣(XMR BCN FCN)再拿去換ETH or BTC

這幾天突然發現他開啟了新的功能,可以用美金線上刷卡換匯,立馬就試試看

原來他是跟indacoin 合作,indacoin 本身就有提供刷卡買BTC和ETH的功能
(中間會有個流程轉到indacoin 的網站)

根據網站的規定,它會依次提高你的刷卡金額上限:

For the 1st transaction with a new card transfer an amount between 30 USD
and 100 USD. The second purchase can be made in 4 days (200 USD Limit).
The third payment can be made in 7 days (500 USD Limit).
If your card account currency is other than USD, conversion will be
completed at a rate of your bank.

所以第一次我先小刷了50USD 買ETH,他的匯率顯示
1 USD = 0.00225998 ETH

換算下來 1 ETH = 442.48 USD.....驚呆了...這是什麼匯率!?
昨天匯率不是也才300多USD... 我有算錯嗎?
不過本著實驗精神,第一次還是當潘仔試試看...

當線上刷卡後它會有兩種驗證機制:

1. 會要看你填入線上銀行的 Pr-Authication Code
但是台灣的卡似乎都看不到也拿不到,半夜也找不到客服人員幫忙

2. 要你拿著護照和信用卡在鏡頭前面錄影,然後念indcoin verification

過了一下就有從新加坡客服人員(英文)打電話來跟你確認,我就說我拿不到驗證碼
請她幫忙,她就說ok 大概15min 以內可以驗證完畢,大概10min不到就驗證通過了
這就是第一次當潘仔的經驗

最後從Changelly 收到刷卡金額,到ETH confirm 大概經過一個半小時吧

排除掉刷卡匯率似乎有點誇張(這不是應該就是重點嗎XDrz..),Changelly 真得還蠻好用的

如果有興趣用用看的,歡迎使用我的推廣連結去註冊:

推廣連結:https://changelly.com?ref_id=7e5b1bf7cf1a

換匯的畫面就是如同下面的Widget 所示

2017年7月16日 星期日

OKR 要怎麼跟Scrum 搭配進行呢? (1)


第一次聽到OKR 的完整範例是從吳軍的硅谷來信中聽到的 Google 的目標管理法,聽完的感想是,哇~原來OKR 可以這樣使用,不管是目標和關鍵成果都很明確,是個簡單易懂的工具。對於個人是這樣,但是對於公司組織制訂OKR似乎就沒那麼簡單了...


對於許多組織來說,都會有訂立年度目標的習慣,也會根據年度目標來當作績效考核的參考,不過這對我們跑敏捷的組織來說是不太適用的,如同這篇文章有提到 : Agile Goal Setting: Using OKR to link Agile and Lean to company goals
But if your teams are working on 1–4 week iterations, getting out of the building to talk to customers, testing hypothesis and learning what works and what doesn't work, how can you use a static set of goals?    -  The answer is, you can't.

像我們以Sprint 為基礎在運行,本來就等於週週在規劃,週週都在Review,而且Scrum Team 本來就應該是以整個團隊成果來考核,所以績效考核這套跟我們有點格格步入,經過內部討論後,我們想乾脆就趁機開始試試看OKR。而本著敏捷學習試錯的精神,反正就先讓大家試試看,過一季後在來檢討一下,看看實行上有什麼困難和不順的地方,再當作修改的依據。

而團隊成員和我運行一季後遇到最大的問題就是:
個人Object 跟Sprint Goal 無法 Match 的狀況下,根本無法達成任何Key Result

這顯然有什麼地方出錯了?理論上 OKR 的制訂必須跟組織和團隊的目標一致,而團隊成員就依據討論出來的組織目標去思考到底我們可以對組織有什麼貢獻?並且訂出一些覺得可以對組織有貢獻的改善方案當作我們的 OKR,但這個問題就來了,我們個人的OKR 如果沒有排入 Backlog 那有什麼時間可以做呢?

(這邊就有個怪味道,是不是個人OKR 跟組織或  Team 沒有 alignment 呢?)

你真的了解OKR吗? 這篇文章也有提到,所有的OKR 都必須排入Backlog 才能被有效追蹤和執行,但是Backlog 不都是PO 在管理的商業需求嗎? 那個人建議的改善方案要怎麼排進去呢?


後來發現網路有不少人有跟我一樣的問題:
有人提到在Scrum team 跑OKR 對工程師來說會有些疑惑:
"company-level OKRs work fine, when it comes to group-level and individual OKRs, often developers get the feeling that the two systems are overlapping or even competing."

其中有一個人講的我覺得蠻有道理的,也比較像我覺得OKR與Scrum 用起來有點不順的地方:

Personally, I think OKRs fit better with pull based systems (e.g. kanban/lean) over push based systems (e.g. Scrum iterations).  Autonomy is key. Once OKRs are set, it's great to see the team define their own work to help achieve their own OKRs.


然後我看到說有成功結合Sprint 和 OKR 的就是直接把Sprint Goal 要做的User story 當作是RD的Object,那RD產出的KRs就是如何設計和開發這些功能.......這超奇怪的....XD

For example, let's say we want to release our recognition version 2.0 this quarter. This will be our OKRs. The key results will consist of the team member's sprints to achieve the goal. E.g. Redesigning the "Recognize" button, x amount of code reviews before push etc.

透過OKR 幫助團隊對齊


Agile Goal Setting with OKR - Objectives and Key Results 這篇文章中提到,透過團隊共享OKR可以達到 Reinforcing Alignment,這個觀點我認同,同一個team 對於同一個產品應該要有相同的目標和檢驗標準,不過這邊指 team 似乎不只是RD team還包含 BD sales  吧?

Objective: Successfully Launch Acme Product
Key Results:
  • 500.000 Daily Active Users of the free version.     
  • 8% conversion rate from free to paid customers.     
  • Net Promoter Score of 75%.     
  • Less than 5 critical or blocker bugs reported by users.     
  • Achieve at least 40% revenue share with 5 of the target content partners.

此外許多篇文章最後都會看到這個結論:
  • OKR gives autonomy to the team
  • OKR helps prioritize the product backlog

讓我開始重新思考我真正的問題是什麼,到底Scrum Team要交出的OKR是什麼? Scrum 會需要個人的OKR嗎?

首先 OKR 的確適合用在Lean 的環境,甚至可以用來補強,因為Lean 的重點就是驗證假設與學習,而OKR 正好用來定義 Success Criteria 的量化指標,在過去 Agile & Scrum 其實是沒有著重在Goal 與 Business Success 這塊的,它重視的比較是交付,要知道Product Deliver  與 Product Success 是有差距的,而且很多地方是RD無法着力的? 有個 OKR 教練 Christina Wodtke 提到:

Success is not checking a box.
Success is having an impact.
If you complete all tasks and nothing ever gets better, that's not success.

而參考自Riachard的文章 Scrum Master 的職責 - 引領團隊的流程,進而得以交付成功的產品,原始的Scrum 定義分工是:
  • Product Owner: Makes Product Success (讓產品得以成功)
  • Scrum Master: Makes Process Success (讓流程得以成功)
  • Scrum Team: Makes Deliverables Success (讓交付得以成功)
Team 的 OKR 只需要專注在 交付嗎?  此外 A Key Result is NOT something you do, it IS something that happened because of what you did,所以我們要造成什麼Happen?


假使單獨談 OKR 和 Scrum 應該都沒什麼疑問,但是合在一起看我就迷糊了~XD 而且看了越多文章問號越多~

講了那麼多到最後不但沒結論,反而造成更多疑問這樣好像不道德,浪費大家的時間...Orz...


Well 至少我可以分享給各位我看過的幾篇好文章,然後我會繼續研究思考這個議題~

Reference:

[1] What is the difference between MBO and OKR
[2] oreilly - Introduction to OKRs
[3] How OKRs Complement Scrum – and Why You Should Use Them Together
[4] Monday Commitments and Friday Wins
[5] OKR Mistakes (and how to fix them)
[6] OKR for Agile Teams
[7] Lean Performance’s Beginner’s Guide to OKR:




2017年7月15日 星期六

[萬維鋼的精英日課] 端粒效應 - 用科學法驗證古人名言



本週萬維鋼精英日課都在講這本書,端粒效應(The Telomere Effect: A Revolutionary Approach to Living Younger, Healthier, Longer )[Amazon 上火熱熱的新書],這本書的脈絡是研究人類衰老的原因,衰老主因是細胞不再分裂,而控制的因素是端粒體題的長短,端粒體每分裂一次就會變短,而是否能維持端粒體的長度取決於端粒體酶的分泌程度。

上面的部分都是純粹生化科學的研究,但是接下來的研究就扣回到許多宗教和心靈書籍所解釋的內容,比如說你怎麼面對你的壓力?

科學研究壓力會抑制端粒體酶的分泌,進而影響端粒體的長度(也就是影響衰老程度),但是人每天都會面對壓力阿!?那不就沒救了?根據這本書的研究其實面對多少壓力不是主因,而是你怎麼看待壓力,面對壓力有兩種詮釋方法:
1. 威脅,危機
2. 挑戰,機會

以第一種心態面對壓力,的確就會抑制端粒體酶進而減短端粒體(加速衰老),如果是第二種心態則不會,所以如何面對壓力和我們的心態原來有這麼大的關係,而且還是有科學生理依據的。
如果每天只會抱怨,面對壓力唉聲嘆氣,動不動說自己年紀大了,老了,那衰老則是無法避免的,這也映證了心理學大腦會接受自我暗示的😂
更有趣的點來了,怎樣可以幫助面對壓力,把壓力視為挑戰和機會,就是用第三人稱的角度對自己說話和激勵。

寶寶苦寶寶當吃補造句法

今天系統炸裂了,老貝不要害怕,就當作是定期演練,給老貝機會把系統弄得更強壯...(噁)

我想熟讀聖經的話語,並且放在心裡是比較實在的做法🤣
所以我們不喪膽,反而我們外面的人雖然在毀壞,我們裏面的人卻日日在更新。因為我們這短暫輕微的苦楚,要極盡超越的為我們成就永遠重大的榮耀。
-哥林多後書4:16-17

2017年7月2日 星期日

關於技術債的why what how


敏捷其實是面照妖鏡,能提早暴露出組織和團隊的問題,好讓團隊能及早進行討論,和思考改善方案(當然前提是有想要改善,有能力改善)。隨著專案越來越大,系統越來越複雜,技術債這個議題已經越來越不能忽視,因此最近團隊時常討論的題目便是"該如何償還技術債",但是如果直接基於這個命題來討論,我們很容易就直接跳到了how 的議題,於是各式各樣的爭論就出現了:

2017年7月1日 星期六

[得到]薛兆丰的北大經濟學 - 利息理論



得到的專欄越訂閱多,有時候比較忙略過了幾天,追起來就會有點吃力...XDrz..
與其聽過就忘了,應該要強制自己整理一下感想和筆記,這樣才會有真正的收穫,所以每個專欄的老師都會鼓勵留言討論。

2017年6月3日 星期六

[教學] 如何在利用MinerGate 在 Azure N系列機器挖礦



前陣子因為一個秘密專案的原因,促使我重新開始研究挖礦的技術,不過在這個時間點,如果不是用ASIC的礦機挖礦已經是沒有任何機會了,身為愛研究的臭阿宅怎麼可以這樣放棄呢!!所以必須要另尋他法,首先是先求挖的到東西,再求挖礦的效率,研究了一下目前市面上主要分成三種挖礦模式:
  • 不用ASIC挖礦機就挖不到東西 (如:比特幣)
  • 必須用GPU 運算資源的主流Altcoin (如:以太幣,萊特幣...等)
  • 仍然可以使用CPU 運算資源的其他Altcoin (如:門羅幣(Monero),DASH幣,Bytecoin..等)

2017年5月8日 星期一

[引導型敏捷領導力課程] 波浪分析法

圖片來源:ICA - “Wave” Analysis of Trends


燒腦啊,這兩天的課下來有太多東西需要思考和反芻的...

先把比較有趣和明確的方法紀錄下來,首先是波浪分析法,它的目的是要讓我們每個人能充分表達自己對於組織現況的看法,所以要注意的是讓大家都能"充分表達",沒有對錯,因為每個人的認知可能是不一樣的。



波浪分析法主要是把組織的現狀分成五種狀態:
  • 開始形成 (Emerging):行動逐漸確立,得到能量,學習曲線快速
  • 衝刺 (Swell):正值潮流,看見正面的效果,持續的學習流
  • 波鋒 (Crest) :產生最好的結果,但是僅存的創意不多,成長空間有限
  • 暗潮 (Undertow):即便在成功當中,仍會帶來問題之深層模式,一不小心就會被吸到海底
  • 漩渦 (Trough):運作的不順利,但是不清楚要往哪裡去,有焦慮感,感到混淆
 每個狀態沒有必然的先受順序,只是你覺得組織目前所處的狀態,運作的順序如下:
  1. 把這個圖片或是狀態具像化到牆壁上
  2. 為這個練習建立情境(Context) ,比如說我們是討論敏捷在組織推行的狀況
  3. 依照人數多寡,大概兩三個人為一個小組,先討論目前現況,並寫在卡片上(越多越好)
  4. 解釋波浪的意義,並且說一個小故事來解釋如何使用
  5. 團隊成員把它們的卡片作標記,並且放在相對應的位置上
  6. 把五個區域的卡變都讀過一遍,並且選出代表性的卡片
  7. 最後針對整個波浪作整體性的反思,看看大家有什麼ingights


在進行的步驟中根ORID的步驟很類似,一開始先用O和R 帶出大家的想法,慢慢才進入到I 的思考,最後再產生D 的總結和行動方案


下面就是我們這組最後的產出~~回去還想找整個team 一起走一次定更有收穫~:D



Update:

有興趣也可以看看當天其他組的心得記錄:

2017年4月15日 星期六

個人財務規劃 - 年度資金運用表


最近跟朋友閒聊時發現,很多人對於年度資金規劃和個人資產狀況的概念是一片空白,都是憑感覺在"理財"和"花錢"。縱使你有記帳的習慣,沒有搭配資金運用表來檢視自己的現金流狀況,你可能還是會遇到資金嘎不過來的周轉問題。

這邊先聲明,對於學企管的,學會計的這些根本都是皮毛的基礎常識,但對於大多數人可能根本沒這個概念,所以在這邊分享一下我學到的規劃方式。

這個表格是六年前上聯聖企管顧問陳宗賢老師的課 "年度計畫一學就會" 學到的,還記得那時候公司送我們去上課,希望培養我們這些中階主管維運中小企業的能力,雖然很多內容可能因為產業不同,或是時代背景不同,不一定適用,也很快就忘記了,但是我覺得財務方面的知識卻讓我很受用,尤其是這個年度資金運用表,從學到以後我馬上用在自己的資金規劃(把自己當公司經營),用到現在。

對於企業來說,現金流其實是最重要的東西,縱使你公司一直都在賺錢,但是卻忽略了應收帳款的票期(30 天?90天 ? 180天!?),甚至應收帳款都沒收回來,在意想不到的時間點就會發現資金周轉不過來了,所以這個年度資金運用表就是財務人員最簡單用來診斷分析公司現金流狀態的表格,以公司來說,要做好這個表格前提就是要做好年度預算規劃,年度收入規劃,以及本來就有做的會計記帳。

對資金得運用套用到個人也是一樣的道理,你可能收入很高,但是收入都集中在年終或是分紅的時候,這時候你認為你收入夠,但是卻沒有考慮到薪水和獎金入帳的時間,這時候周轉可能就會出問題了。

對個人來說要做好這個表格也必須有幾個前提:
  1. 要記帳 (知道自己每個月實際花費)
  2. 要做預算表 (知道自己何時會有什麼固定支出,甚至年度旅行)

如果你這兩個都做到了,接下來就可以開始填入這個表個,這個表格分為三個部分:
  1. 收入
  2. 支出
  3. 結餘 / 策略


收入的部分就很簡單:
  • 你的月薪/年終 (可以預期的固定收入)
  • 每個月額外的收入 (獎金,分紅,交易...等)
  • 應收帳款 (別人欠你的錢,代墊公司的錢)


支出的部分就需要搭配記帳和預算:
  • 每月的固定支出 (房租,存款,投資...等)
  • 每月的浮動支出 (生活費,需要搭配編列預算)
  • 年度的固定支出 (保險,各種稅...等)
  • 年度的計畫性支出 (出國旅行,採購敗家計畫..等)
  • 年度的額外支出 (紅包炸彈,罰款,東西壞了維修,衝動性購物....等)
在這邊要注意的是有些因為信用卡或其他因素並不是當月要付清這些費用,可能就要記錄到下個月付款。



最後最重要的就是這個結餘/策略表

上期結餘+收入-支出 = 本期結餘

每個月根據資金運用狀態即時更改這張表格,你就可以很快發現你可能何時會有資金缺口,以上圖為例就會發現年地會有一萬元的資金缺口,這時候就可以開始做策略規劃:
  • 上策 - 我可以增加收入嗎:
    • 我可以去兼差多賺一點錢嗎?
    • 我可以去要求加薪嗎?
    • 我可以想辦法增加被動收入嗎?
  • 中策 - 我可以減少什麼不必要開支嗎?
    • 固定花費中,手機費可以減少嗎?少吃點東西少喝點飲料嗎?
    • 減少衝動性購物
    • 原本規劃出國10天可以減少為5天嗎? QAQ
  • 下策 - 哪裡可以借錢:
    • 我有存款可以應急嗎?  (在這個表格都是一年度收入來規劃,不考慮存款喔)
    • 我可以跟誰借錢嗎?
    • 我可以透過信用卡以債養債嗎?

希望這個分享對大家有所幫助~:D
有興趣的可以從這個連結複製一份使用 -  年度資金運用表範本


2017年4月1日 星期六

Scrum Team 中關於插單事件的視覺化的感想


這個問題已經困擾我好一陣子了,照理來說遇到問題應該在Retrospetive 的時候討論,大家一起思考解決方案,但是如果沒辦法透過數字說話,一切流於"感覺",容易造成發散與責難的討論。

最後想出來的解決方法在 Richard 的blog 已經整理的蠻詳盡的,實體看板的再度邂逅插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )

我在這邊想要補充的是,相同的問題如果不透過實體看板,想要透過電子化看板(如:JIRA) 來凸顯問題,我嘗試過的方法與侷限性,下面是我從JIRA 上收集出來的數字,每一列代表一個Sprint規劃的工作事項,而紅色框框起來的部分代表是plan meeting 後產生的新工作(issue added to sprint after start time),這些工作可能是:
  • 插單 (change feature,new feature...等)
  • 營運問題排查與排解 (bug,fault...等)
  • Plan 時break down story沒想清楚,新增加的task




可以看出來嚴重的時候,可能超過一半的工作都是當初沒有預期的,但是光是用 issue added to sprint after start time 可能太廣泛,沒辦法真得凸顯問題(插單/營運問題),因為Plan 時沒想清楚後來再新增的task 有時候是必要的。

所以下圖是我嘗試以另一個維度來分析,就是task 的種類,正常來說一個sprint我們只會產生Story 然後會在Story 下開sub task,所以只要是非Stroy 型態(task,bug,fault...等)就應該是插單,所以依舊可以看出來非預期的數量很多。




電子化看板(JIRA)的好處是事後分析方便,但是sprint 發生的當下,與daily stand up meeting 卻不容易突顯出來,因為:
  • 大家可能接單就順手修掉了,沒有去系統上開issue,很多是我事後要求補填的
  • 電子化看板之前都專注在每個人要做什麼事,不是以Story 的角度來看,不容易凸顯問題
  • 電子化看板對大家來說只是記錄工作歷程,大家只會專注在自己的工作項目,不會看到整體,通常只有team lead 或是 SM,PO會去關注。

所以直到把sprint 的工作實體看板化後,大家才正式到這個問題,好像插單真得很多,也唯有這樣才比較容易把問題講開。


另外電子化看板不容易隨時根據我們的需求去group by,而實體看辦就有這個好處,我們馬上就可以針對各種維度的問題去group by,包含:
  • 哪些問題有跟PO討論過,哪些沒有?
  • 哪些問題是bug,哪些不是?
    • 那些是上個sprint 產生的,哪些是更久以前產生的
  • 這些問題哪些是插單?
  • 哪些問題是Team Lead 撿走,那些是Team member撿走
透過不同group by 的方法,就能有不同層面的檢討方式,詳情請見插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )