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 )

2017年2月1日 星期三

書摘 - 團隊領導的五大障礙



#克服團隊領導的五大障礙 這本書講的是如何在團隊間有效煽風點火的故事,如何讓團隊變成能高效運作與溝通的團隊,就是要有足夠多『建設性的衝突』。
(長官負責放火😂)

 本書主要闡述團隊五大障礙的模型:
  • 第一個障礙,團隊成員之間喪失信賴
  • 無法建立信任,就會衍生出第二個障礙:害怕衝突
  • 一旦缺乏建設性衝突,團隊勢必因此出現第三個障礙:缺乏承諾
  • 缺乏真正的承諾和共識,會導致團隊成員形成第四個障礙:規避責任
  • 當團隊成員無法互相要求,將製造有利於第五個障礙:忽視成果
把障礙反過來的正面模型則是:
  1. 團隊成員互相信任
  2. 團隊成員含不保留地投入有關理念的衝突
  3. 團隊成員承諾達成決策和行動計畫
  4. 團隊成互相要求,為消除計畫中得障礙負起責任
  5. 團隊成員將重點放在達成集體成果

團隊領導的五大障礙這本書前3/4的部分是以小說的方式在描述公司內部衝突的情境(最近看好多這種小說~XD),最後1/4 才是以重點要克服的方法與實行步驟。

雖然這些道理似乎可以通用在各種團隊,不過我覺得就如同本書的應用情境,主要還是用來建立高層管理團隊的合作(越往上層越難合作~:P),而許多方法的確也比較適合從CEO的角度去推行。


另外的感想就是,建設性的衝突根本是門藝術,裡面有太多反直覺,需要控制情緒的技巧在裡面,沒處理好就是引火自焚,所以就必須搭配 開口就說多話
(下屬要自己建立安全的對話環境😂)
(就算有信賴,要一直鬥爭也是很累的)


這兩本書搭配著看真是五味雜陳....




其中最有感觸就是這段話....高階主管的工作就是在鬥爭啊,並且是針對問題在鬥爭,如果主管都不能有效討論清楚,那要部屬如何適從?


2017年1月22日 星期日

在Scrum 團隊如何建立個人績效評估系統



也許想要在Scrum 團隊建立個人績效評估系統,這本身就是一個錯誤的命題,因為Scrum是以team為單位,看的是整體的產出,不過在一般企業又會需要對個人做績效考核(不管是為了升遷、加給、甚至解雇都得要有個依據)。而待過大公司的人可能都填過類似MBO,或是360評量的系統,但是總覺得形式大於實質意義,只是要給HR收集數據,但是對於公司營運和團隊成長真得有幫助嗎?作法跟Scrum的精神也格格不入......

所以我上網找了許多文章,看到這篇深得我心,這是ebay團隊的2012年的篇 blog - Now You See It: A Peer Feedback System for Scrum Teams



以下是我節錄的重點:
關於管理人員的迷失
But how about the individual’s performance within the team? I’m not supposed to micro-manage each person, but it seems the Scrum team becomes a ‘black hole’ to me, and I lose sight of each team member’s performance behind the ‘event horizon’.”

對於一個成功的公司和團隊歸納出一個framework ,主要分為四個部分:  
  • product success (which is shared by team members)
  • peer feedback (which distinguishes among team members)
  • self-development
  • management tasks.  
而這幾個部分裡面 team 之間的peer feedback 就變成對於個人績效評估的重要指標!在這邊他們做出了八個問題,其中1~6題都是對團隊所有成員匿名評分(包含自評),而每個問題又可以根據團隊的需求加以解釋:

  • Q1:  Communication — This is the foundation of human interaction and teamwork.
  • Q2:  Quality — One’s defect has a negative impact on the other team members, and ultimately on the overall quality and productivity of the team.
  • Q3:  Collaboration — We value building consensus and seeking win-win outcomes over just getting one’s own work done (i. e., “self-suboptimizing”:  focusing on one’s own tasks rather than considering the team as a whole).
  • Q4:  Continuous Improvement — By improving oneself and helping others to improve, the capabilities of the overall team increase.
  • Q5:  Role Sharing — The willingness and ability to share responsibilities bi-directionally outside of one’s functional silo makes the team more robust.
  • Q6:  Energizing — An individual can positively influence the team, especially in tough times, instead of finger-pointing and dragging down team morale.
------------------------------------
  • Q7:  Overall Satisfaction — “If you had a choice, would you continue working with this team member?”
  • Q8:  Other Comments

第七題和第八題就是bonus 題,此外最重要的一點就是

no question about how much a team member contributes to the team!
因為他們主張,假使一個Jr. RD可能產能比不上一個Sr. RD但是他的加入和貢獻可能跟膠水一樣可以幫助團對成長和運作更順暢,同樣的如果以個Sr. RD在怎麼厲害,但是讓團隊受傷或是產能降低都不是好現象。


如果只是單純的評分那效益可能還不夠大,這個系統最令我驚艷的就是長期追蹤的效果,我取出一張他們blog長期追蹤的圖表,可以看出每個人的狀況表現,甚至跟整個team表現的趨勢追蹤:




這樣就結束了嗎?不~他們一開始是先用surveyMonkey去收集資料,後來進一步寫了內部系統,然後我再留言串下面看到有人留言真得有公司因此開發了這樣的系統!下面是他們的介紹影片,看了真讓人心動



如果看不到影片請到:http://blog.team-sense.co.uk/p/tutorials.html

結論:

有工具和系統當然是令人著迷心動(我是工具控),但是重點還是方法,以及思考過這幾個問題:
  • 這個方法對團隊是否真得能產生幫助?
  • 我們想要達成的目標是什麼?
  • 想要解決的問題是什麼?




2017年1月13日 星期五

重讀目標體會TOC 與 Scrum 的關係




最近社群開了一個新坑 - 遛書幫,讓自己不得不把握時間看書和有所產出啊~~XD

仔細想想好像很久沒有好好把一本書讀完了,雖然買了很多書,但是每本書都東看一點西看一點,去年有用心看完的大概只有鳳凰計畫,還寫了篇心得 - 書摘- 鳳凰計畫(The phoenix Project ),裡面大量的用到高德拉特四書(仍然不足夠+目標+絕不是靠運氣+關鍵鏈)的觀念,加上之前常看到William Yeh 把TOC 和Scrum 拿出來一起討論,那時候感覺還沒那麼強烈,想想應該再回去重頭讀一遍,看完後突然有種通了的感覺。


Scrum 的Sprint 其實跟TOC的核心精神和方法很吻合,所謂的聚焦五步驟:
1. 找出系統的制約因素
2. 決定如何利用系統的制約因素
3. 根據上述的決定,調整其他的一切
4. 把系統的制約因素鬆綁
5. 加入四打破了原有的制約因素,回到步驟一


這不正是Sprint 的iteration 持續改善,而我認為Sprint 中最重要,也最難做的就是 Retrospective meeting,這邊就可以搭配TOC的工具做有效的討論問題,和找出下一個iteration 的改善action item,這也是我們這陣子持續在做和實驗的部分。

每次Retrospective讓團隊不停的問自己:
  1. 應該改變哪些事情?  
  2. 要朝什麼方向改變?
  3. 要如何改變? 



 瞭解了心法,接下來應該靠 TOC限制理論這本書找些技法了~

2017年1月7日 星期六

2017年跟著敏捷社群大師一起讀書



要說2016年有什麼特別值的關注的,我想就是敏捷社群進入了大推坑時代,就讓小弟鍵盤分析一下:

故事從David 這幾年持續邀請 Daniel 來授課開始,而這段期間燃起了不少人,其中關鍵我想是燒到了坑王 Yves 大大,Yves先是在他們公司推坑,然後獨坑坑不如眾坑坑,於是發起了許多團坑課程活動,於是 2016年 就成了大挖坑時代,有更多的活動,更多的講座,更多跨領域的學習對象,更多的推薦書,如同星火燎原般展開,因為火燒的太大了,更把一堆大大都坑殺串連在一起。

身為被坑殺的對象,一方面被坑的很爽,一方面又被坑的痛痛的癢癢的 (這啥形容詞...=_=)
所以就突發奇想,何不如拾人牙慧一下,把這些大大的書單都收集起來追蹤。

2017 年讓我們跟著這幾位推坑王大大來讀書吧,我會持續follow 各位大大的坑的~~XD

Daniel:



Yves大大

威廉大大

Richard大大

91大大

這邊的書單太恐怖了...需要消化一下~:P


另外值得一提的,91大大的 個人書單Kanban 更是值得學習,透過Trello 來管理看書進度,我也試著建立了幾本(但是發現書太多了...XDrz...)


至於我自己呢?去年最推的還是鳳凰計畫,可以參考我之前的文章鳳凰項目書摘,然後目前正在緩慢著看著相同作者的另一本書:Leading the Transformation

2017年1月2日 星期一

新年新目標 Udemy 2017 年初特價活動



新的一年開始不是就要互相推坑嗎~~~

根據萬維剛的菁英日課提到,2015年統計最常許的新年希望分別是:
1. 減肥
2. 時間管理
3. 存錢

但是能持續新年希望目標的人,第一週剩下75%,一年後剩下10%,所以要怎麼能讓新年計畫持續呢?就是要訂出一個會讓自己有點痛,但是又可行的學習計劃,並且徹底利用零碎時間。

什麼叫做有點痛?就是要花錢去學習,雖然網路上免費的資訊很多,但是你必須花時間搜尋和比較,甚至會看到錯誤的資訊,不如先找幫你整理好的資訊,直接找高手學習,等到學到一定程度在考慮自己收集資料。

之所以選擇Udemy就是他有許多整理好的入門課程,可以有效降低學習門檻,又可以學到業界真實的practice。第二就是每個章節都是一段小影片,你只要有時間可以隨時可以來一小段,甚至可以通勤透過手機觀看。

首先可以先參考這個: Learning How to Learn From Video Courses


趁著年初還有特價(不過似乎每隔一段時間就有一堆特價...XDD),來選一些不錯的課程吧。

========> 由此連結進去找尋所有300元特價課程 <============

下面是我整理一些我自己有買,或是覺得想買的課程:


商管類:


技術類:



通通300元~~~接下來就是要找人互相督促把課程看完~XDrz...
如果有覺得不錯的也請推薦啊~~