星期二, 3月 14, 2017

打造當責影響力


如果你真的想做一件事,你一定會找到一個「方法」
如果你不想做一件,你一定會找到「一個藉口」


今天上了內訓課程- 「打造當責影響力」
講師是李河泉老師
原本上課的計劃是學著怎麼帶人,讓同仁有當責的觀念
反而是上了一堂怎麼帶小孩的課程,倒是滿實用的... 回家馬上試試

新人難帶,自己是共犯


學員有人反應常發現有新人不會主動做事
想指責,新人倒是很自然的回應:「沒人跟我說要做」

講師便提到觀念來自- 1.家庭2.經驗
在場多為人父母,請問你家的小孩會主動做家事嗎?為什麼會這樣?
小孩從小就知道他沒做,爸媽就會做掉,自然沒有負責的心態,出社會就同一個樣子
卸責是人之常情,就是要讓他扛起責任,沒人會幫他,他就會扛起責任

從負責到當責

高鐵清潔員快步走VS觀望走

為什麼要當責

責任三層次

1.卸責- 「找藉口」避免被怪是人的天性
一般人「逃避」、「抱怨」
成功者「改變現狀」

工作中,六種一般心態
  • 領多少做多少事
  • 那不是我的工作範圍
  • 有指示再做事
  • 該有人告訴我怎麼做
  • 下班該是我的時間吧
  • 為什麼他這樣也行
改要從心態改起
為最終結果負責- 團隊中,每個人都從get reasons轉移到get results
抱怨是本能,解決是本事

2.負責- 只做好份內工作
人該積極主動最主要的理由
  1. 薪水
  2. 自己
「所有人」指責「某個人」,卻「沒有人」去做「任何人」都可以做的事
「負責」與「當責」 比一比
把事情做完把事做完並做好
有義務採取行動有義務確保這些行動能交出成果
只對「自己」許下承諾對「自己」和「別人」許下承諾
只願意執行被交付的任務,沒有功勞也有苦勞成果至上,不管多少困難,一定要交出成果
沒有人認為自己不負責,只是認為那些非份內之事

3.當責- 每個人「多做一點」,為結果「盡責」

如何當責
不斷自問的態度- 我還能做些什麼,好超越我的環境,取得我想要的成果
沒人能強迫你做事,除了你自己
每次主動扛起問題的呆瓜,有一天才發現他是學最多的人

團隊

奧茲法則- 人沒有完美,看你如何組合團隊


動態競爭

把成果跟其他人比,而不是跟自己比

人生不是得到($),就是學到(經驗)

難題不是解開就是跳開,當一路跳開,最後剩的只有難題

把時間花在哪,成就就在哪

當責- 王牌法則


  • 當仁不讓,責無旁貸
    每個人都練習把自己的責任往外擴張,讓團隊完整的圓沒有缺陷。
    花公司的時間,做自己的事情=>花公司的時間,學自己的本領
  • 當然為最終結果負責
    團隊中,每個人都從get reasons轉移到get results

雪崩時,沒有一片雪花覺得自己有責任
--法國文學家伏爾泰(Voltaire)

當責- 團隊篇


3M當責文化,信件從董室會到收發室
盡責地把重要文件準時寄出
進一步確認對方收到

超越主管的期待,找到你的不可取代性
「累己」才能「累積」自己的實力

當責的最佳團隊(雁行理論)


借著V字隊形,整個雁群比每隻雁鳥單飛時,至少增加了71%的飛行距離
而顉頭的雁鳥最累,要交換時,會由誰來取代- anyone都可



星期四, 3月 09, 2017

CSPO課程心得


為什麼上CSPO
去年上了SCM課程,上完課發現「挺好的」(呂毅語氣)
學到滿多東西的,特別是Scrum每個meeting的Goal及Why
例如,講師詢問Daily meeting的Goal
自以為的回答「觀察每日進度及即時調整!」,又被追問那Why?為什麼要做這件事
才發現回答的都是What,回答不出來為什麼
Daily meeting的Goal是觀察及調整沒錯,但要知道目標才知道如何調整
目標到底是什麼 - 滿足這個sprint backlog item呀

被糾正觀念後,就覺得這課程真的滿不錯的
因此決定再來上PO的課程

學到什麼呢?以下做個筆記
Origin of scrum
The new new product development game
只給日期,時間到了要有Shippable product
其他讓Team自己決定(Cross-functional/Self-originated)
雖然之前SCM就有聽過了,但再聽一次,總是refresh一下Scrum最核心的精神

Empirical process (野雁)
開發Product如同野雁南飛一樣
做一段,檢查一下(Inspect & Adapt)
離目標多遠,需要調整以更接近目標
Scrum很多Practice就是要這事兒發生, ex. daily scrum, burn down chart, ...

Sprint中,PO需要參與嗎

  • Product Backlog Item(What)
    • PO的職責
  • Sprint Backlog Item(How + What)
    • Dev的職責
也就是Sprint中,Dev有需要再問PO,PO不用插手Dev
PO關心What,不是How


Demo meeting改叫Review meeting

回到剛的Daily meeting的Goal是要完成sprint backlog item
而Demo meeting的Goal呢?
除了demo外... 應該要Inspect與Goal的差異
因此應該叫Review meeting比較合適

Scrum framework 欠缺Why
Why是離Goal的差距,因此Review meeting是PO Inspect & Adapt的時機

再看各個meeting的重點 - 以終為始
說很簡單,但實做才發現自己都漫無目標的在做
雖然有inspect,但都沒在與goal比較,只是求局部最佳
Goal不是只有指如期完成,而是如期交付最適合市場的Product,也就是說最後交付的Product有可能已經不是當初定的Goal了

換位思考
這次上CSPO最大的感受... 就是每個問題的答案都跟我的想法有出入
甚至有時聽不太懂講師在說什麼,上SCM還沒差這麼大
後來才意識到我還在用developer的角度思考
我只想著要把MVP做出來,而PO想著是有Business value的feature
而且... 做出來要能feedback到之後的sprint

為什麼!?調整產品的走向呀~~
我還是只能想到自省會議的改善項目(Deliver的部份)
PO要想著Discover的部份

PM的價值在於Project成功,PO的價值在於Product成功
課程中有討論Product Owner與Project Manager的不同
點出兩者職責的不同,因此重視的東西便不同

「PM的價值在於Project成功」
這句話真是有fu
感受到過去被PM壓榨的fu
感覺上PM只在乎有沒有如期交付,但不會深入討論有價值的feature
只會逼著developer交付,把develop team當可以置換的人力
成功都是他的,失敗都是別人

但什麼才是對的,Project成功了,但Product失敗了,這能叫成功嗎?

PO應重視Business Value

課程中有玩Business Value Game,這跟之前玩的Kanban Game滿像的
遊戲裡有些可以改善開發效率的feature,很直覺的就應該先擺在前面先做

但遊戲結束後,才發現分數並不高
因為遊戲故意設計重點在Business Value(有做完才算!!!)
所以要評估如何讓Business value最大化
這裡的陷阱在回合有限,做完改善後,遊戲(專案)已經結束了
改善的項目是沒有business value的!!!

因此PO常不理develop team的改善需求
雖然現實也是這樣,但對PO還是有很多抱怨

事後討論,這類型的改善,應該在每個sprint一點一滴的做掉是最好的

這遊戲真厲害,一次讓兩個角色搞明白(呂毅語氣)

Product Version
影片 - IDEO Shopping Cart
影片提到如何在幾天內重新設計Shopping Cart(重點當然是在如何進行重新設計)

  • 收集客戶問題,想辦法解決
    • 不要自己想,太花時間了
  • 看客戶怎麼用,自己也下去玩

Excise: Spec Writing Game
分成兩組人,一組寫文件,一組實作

  • 題目
    • 左邊是題目,右邊是我們的成果 XD
  • 規則
    • Timebox : 10分鐘
    • 兩組人只能透過文字(件)溝通
    • 不可畫圖(當然!!!)
    • 可以修改文件
      • Writer可以觀察實作者的情況,再修改文件
      • 實作者不可提問


結果
太晚給Spec,有疑惑來不及修改文件
忘了把文件拍下來... 不然大家可以來畫畫看...
記得文件寫左上角的六角型直徑1.5公分
但Writer看我們畫完,才發現.... 他們是要寫半徑1.5公司... 所以大小差很多

上方的星星跟下方的甜甜圈則是連文件都來不及寫...

心得

  • Writer會想把文件一次寫清楚,但花太多時間且有認知落差,發現實作誤解再調整文件
  • 越早開始,越早修正認知落差
  • 能當面溝通或畫圖描述都是很直接的幫助 => 用文字(件)不一定是最好的方法
又是一個一次讓兩個角色搞明白的遊戲(太強了)


Story是Delta,不是Baseline
透過Acceptance Test留下活文件