2017-02-20

[筆記] 非型男飛行日誌 - PM的奇幻旅程

上週五有幸在趨勢聽了一場 產品經理的分享
講者Brian本身是工程師出身
他以幽默風趣的言語帶著大家進入成為產品經理的心路歷程
這場產品經理的由 0 到 1 真的太精彩了

產品經理 Product Manager, 大家熟知的PM
在趨勢並不是穿著火辣短裙的新鮮人辣妹
而是非常專業的資深同事

Brian就跟大家分享 PM其實跟大家想的不一樣

(其實在業界 聽到比較多都是PM與工程團隊的對立面)

但是PM要想的事情非常多 非常遠
負責
從無到有
從有到優
從生到死
的所有大小事

所以PM要牽涉的領域很廣 往往都需要各領域的交集
各領域都要樣樣通 (不僅僅只是略知一二)

之前小弟也有一種迷思
就是JM Project Manager ; PM Product Manager
傻傻分不清楚
後來經過Brian的分析 才了解
哇~
JM 看的是現在
以目前有限的資源 兜出資源 控制時程 把目標完成

PM 看的是未來
知道未來需要什麼 一直找尋機會並選擇對的戰場
發揮影響力帶動團隊 帶動改變

(怎麼聽起來 好像跟教練, 引導者, Lead 有87分像)

身為正確的PM 應該要有正確的態度
必須要
Positive Thinking
正面的雞婆
積極主動 樂於接受挑戰
主動找資源
聆聽與溝通

(怎麼聽起來 好像跟教練, 引導者, Lead 又有87分像)

最後
做產品 不能活在自己的世界裡

所以需要
大量的資料搜集與驗證
敏銳的觀察力
聆聽與溝通 (避免說得太多, 用詢問的方式, 延後判斷, 挖掘問題還是搜集需求)
訓練思考產生有影響力的想法 (強迫在資源不足時把事情完成)
永遠都要保持客觀 保持懷疑的態度
Start from WHY (Follow why you do it, not what you can do)

想清楚 為什麼你要這麼做 不這麼做

2017-02-15

Scrum Drawing Game 1.2 四小時豪華版


情人節的這天 我在趨勢開設了一堂四小時的Workshop課程
我都笑稱這是四小時豪華版的遊戲

Scrum Drawing Game

這個workshop我已經帶過了兩次
每一次都會再做些調整跟實驗
這次也不意外

[改變]
1. 授課方式從以往單方面傳授轉換成引導學員討論
2. Sprint個數從 4個增加為5個 但是大家總工時不變 一樣為40分鐘
3. 在Sprint中插入了Product Backlog Refinement (1分鐘)
4. 更多的需求變更 (改SPEC, 加新圖)
5. 如果PO來找User釐清問題 會提前將情報釋出給該PO (所以有來問的就能拿到情報 沒問的就沒有)
6. 團隊都有自己的Scrum Master
7. 從第3個Sprint開始 讓團隊自主管理 (總共15分鐘 自行分配每個階段時間)
8. 透過破冰遊戲(不可能的默契之Scrum篇) 找出本班級對Scrum最熟的人並成為各隊隊長
9. 透過 Token 來發言 (一顆軟質棒球)
10. 取消估算 讓遊戲單純一點
11. Retrospective 採用ORID方式 最後讓大家寫出回去之後的Action
12. 遊戲結束各組分享過程中最棒與最需要改進的事
本次課程以學員為主


[觀察]
1. 做Infra的人 往往是同一個人 這部分蠻可惜的
2. 完成Infra數獨約需要2個Sprint左右 但是效益不大 甚至還徒勞無功XD
3. 今天嘗試讓學員自己講出對Scrum的認識 但是感覺還是要有一些經驗才能說的出來
4. 自主管理時間 大家都就沒在管遊戲限制了 (沒做 retrospective, PO一直待在Team裡面講怎麼畫)
5. Scrum Master表示無力控制XD (因為大家一頭熱栽進去了)
6. 善於分工合作 這真的是Trender的優點
7. Story的粗細決定了Team的成果
8. 今天參與的學員 大部分居然沒有經歷過Scrum
9. 資源有限 有小組很快就把2張白紙用完了 只能在原地休息
做完了Infra 結果拿到什麼鬼啊XDDDD


[Retrospective]
1. 今天在遊戲後引導學員學習的方式 可以再加強連結
2. Infra的效益可以再擴大(例如 直接就給40%拼圖)
3. 今天時間控制很好
4. 繼續嘗試讓團隊自主管理
5. 應該先調查一下學員對Scrum的認識程度
    如果大部份學員都知道 Scrum 是什麼 引導討論可以多一些
    如果大部份學員不知道 Scrum 是什麼 就由遊戲過程來引導討論
6. PO在最後一個Sprint沒事做 下次塞別的任務給他們

最後的最後

哥今天不是講師 而是 SCRUM MASTER !!

2017-02-09

[筆記] 從限制理論看敏捷開發

今天參加 Agile Meetup 2017/02 聚會
主題是從限制理論看敏捷開發
講者是 William Yeh

我就來提提其中幾個點吧

[經驗主義 vs 理性主義]

敏捷的背後理論主要來自經驗主義
講求根據自身經驗去做修正
所以大神說的話 未必能套用在自己的團隊
但是經驗主義的極端就是 懷疑論
懷疑一切理論
懷疑一切教條

反觀 理性主義
用邏輯思考去推理什麼才是對的
所以理性主義的極端就是獨斷

敏捷的鼓勵失敗 從錯誤中學習 看似Open mind
但其實我也很擔心 Team或是老闆對敏捷失去信心及耐心

所以如果用理性主義去推理經驗主義的可行性
可以降低我們導入敏捷的錯誤機率

[樂高限制遊戲 workshop]

第一階段
假設有4個member 要實作6個feature
假設每個feature不可分割
如何在最短時間做完6個feature ?

這階段用排列組合就能完成了
我們直接跳到第二階段

第二階段
假設member技能不可轉移
於是工作開始出現互等的現象
這真的超符合現實情況的
QA 要等Developer 寫完程式 
Backend 要等 Frontend
Developer  要等 UX 畫出mockup

所以在planning時 其實不單單只是把點數相加
還要考慮各個工作的Dependency

[瓶頸處理9原則]
(4) 關鍵地方有損失 代表整個專案的損失
(5) 絕對不可以浪費瓶頸的時間
      e.g. 插件 不能讓現在處理瓶頸的人來處理
(9) 管理重點要在流量 非個別的產能
      有點像Kanban的WIP 要盡量流動

我這邊就不一一列了
但最主要就是找出 “瓶頸”
然後你就會知道 處理瓶頸是最重要的事
瓶頸才是影響專案進度的地方
其他地方就算閒置 就算delay 也不影響專案進度

[聚焦五步驟]

1. Identify 確認瓶頸
2. Exploit 決定如何充分利用瓶頸
3. Subordinate 其他一切遷就以上決定
4. Elevate 鬆綁制約因素 (學新技術或是加人)
5. Prevent inertia 避免惰性 回到步驟一 聚焦持續改進

根據William提的例子
假設瓶頸前期在UX 後期在Tester
那麼前期 其他人在閒置的時候
我們決定充分利用這個瓶頸 
於是只是調整大家的工作習慣
讓Developer 與QA提早與UX一起討論mockup
為了讓瓶頸專心處理
如果此時有插件進來 讓別人去處理
行有餘力再來思考 投資member 讓更多member學到UX 
能夠幫忙cover 瓶頸的部分

其實這個例子讓我想到之前在CM的時候
一開始我們也是在Sprint中設很嚴謹的 設計->開發->測試
原本也是有互等的情況
但後來我們在設計階段 就將Developer與QA一起來拉進來與UX一起討論SPEC
不僅釐清需求也有助於縮短開發與測試的時間

[總結]
用理性主義去推理經驗主義的可行性
來試試看 TOC 吧