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...
如果有覺得不錯的也請推薦啊~~