My Journey
OneDegree
IXT
Some thoughts after new Scrum model
以終為始
新 Scrum model 的目標是什麼？
至今解決了哪些問題？
現況
Abby
Beky
Dany
A
Vicky
Doe
Kiwi
B
Bond
Winnie
Ken
C
Abby
Vicky
Ken
A
Beky
Bond
Dany
Doe
Kiwi
B
Winnie
C
Story 甲
Story 乙
Story 丙丁
Story 戊
Story 己
Story 庚
解決什麼問題？
1.每張 Story 需要人力不等，調度容易
2.因應龐大的 RoadMap
3.每個人能懂更多、對系統全貌更認識
4. 找到黃金組合
問題背後的問題？
1. 每張 Story 需要人力不等，調度容易
2. 因應龐大的 RoadMap
3.每個人能懂更多、對系統全貌更認識
是不是 Story 切分顆粒大小的掌握度？
希望由上而下的控制、調度來精準預估
是不是希望提升產能，來增加交付？
每個人到底要知道多少？知識的邊界在哪？
4. 找到黃金組合
比較屬於單向 top down 的決策、控制
關於知識的邊界
每個人能懂更多、對系統全貌更認識
每個人到底要知道多少？知識的邊界在哪？
為什麼要懂那麼多？要開很多會欸
- 怕想不夠細
- 改 A 壞 B
- 上帝視角
- 追求完美
來自 NASA 的啟示
火箭 - 複雜系統的製作
航電系統
通訊系統
能源動力系統
回收降落系統
模組化拆分、介面隔離
IXT-web 的模組
介面相依
Library
Product
Application
Policy
IXT-web 的模組
以終為始，對齊目標
以 endorsement 出發，確定是為了正確搜集、運算使用者資料，一步步往上反問 Policy 必須要有什麼條件、Application、Product...
Library
Product
Application
Policy
避免討論失焦、偏離主目標
避免局部最佳化
IXT-web 的模組
介面隔離
使
用
者
資
料
審
核
模
組
使
用
者
資
料
搜
集
模
組
計價與收費模組
使用者理賠模組
關於人員異動我看到的潛在風險
傳教士變傭兵
Team Growth 困難
產能難以提升
Ownership 感降低，跨組難以維繫
溝通默契、培育，理解彼此強弱、幫助彼此，就跨組ＱＱ了
想要培育組員時、但已換組
栽培的任務大量轉嫁至 Line Manager
換組要交接成本、重新培養溝通默契
人員異動先降低產能，再透過集中資源來提升產能
世界上最長壽的城市？
世界上最長壽的企業？
企業
| 預估建立年 | 名稱 | 產業 |
|---|---|---|
| 578 AD | 金剛組 | 建築 |
| 705 AD | 慶雲館 | 建築 |
| 900 AD | Sean's Bar | 酒館 |
| 1526 AD | Beretta | 武器 |
| 1975 AD | 微軟 | 電腦軟體 |
城市
| 預估建立年 | 城市 |
|---|---|
| 8000-10000 BC | 大馬士革（敘利亞） |
| 7000-9000 BC | 耶律哥（巴勒斯坦） |
| 4000-5000 BC | 雅典（希臘） |
| 4000-5000 BC | 洛陽（中國） |
| 2000-3000 BC | 耶路撒冷（以色列） |
雅典擊敗微軟
為什麼城市永遠存在，公司相對快消失？
企業生產力隨著規模驟降
城市生產力隨著規模超線性增長
- 地方自治
- 鬆散的結構
- 各式各樣組織加入離開
－建築師、騎士、鐵匠、黑幫、商人、律師、工廠、表演者
市長
公司集團
- 政策
- 激勵
- 管理
- 由上而下的結構與指派
帝國會崩塌、
然而城市依然留存
- 及時應對
- 適者生存
- 隨時代演變而進化
城市
即時的擁抱混亂與不確定性
並且做出回應
從當代科學、管理學角度出發
1776
亞當.斯密 《國富論》
1946
彼得·杜拉克 《企業的概念》
2001
麥可·漢默 《議題制勝》
1911
F .W .泰勒《科學管理理論》
1990
彼得·聖吉《第五項修練》
同時也是 MIT 電腦博士、教授
IBM 電腦軟體工程師
就算從國富論算起，時間都算短
過去的一些理論僅適用於工業革命
或特定的脈絡、時空背景
擁抱混亂和動盪
從軍事領域借鑒的當代世界觀
VUCA
Complexity
複雜性
事件不相關
因果不確定
Volatility
波動
程度、規模變化速度加大
Uncertainty
不確定
難以用過去
預測未來事件
Ambiguity
模糊
不清楚
界線不明確
從軍事領域借鑒的當代世界觀
VUCA
能
多
準
確
的
預
測
未
來
對當前狀態的掌握度多高
從軍事領域借鑒的當代世界觀
面對波動，我們需要願景、指北針
面對不確定性，我們需要透過學習、增進理解
面對複雜，我們需要明確
面對模糊，我們需要敏捷地快速回應
面對不確定、做出更好的決策
不知道你不知道什麼
不知道一些已經存在的知識
知道一些你有不知道的知識
知道你要怎麼補足什麼知識
面對不確定、做出更好的決策
面對不確定、做出更好的決策
不知道你不知道什麼
不知道一些已經存在的知識
知道一些你有不知道的知識
知道你要怎麼補足什麼知識
感知
分類
回應
行動
感知
回應
感知
分析
回應
探索
感知
回應
探索、防止危機，找到新機會
透過實驗、事後回顧而成長
Good Practice
Best Practice
面對不確定、做出更好的決策
面對不確定、做出更好的決策
響應變化 > 遵循計畫
想要大家做的事 vs 大家實際在做的事
預期做這些事能產生的結果 vs 實際做些事產生結果
實際行動的結果 vs 計畫中預期的結果
一致性差距（校準落差）
知識落差
效果落差
當組織見到非預期的成果、不可見預期的成果，通常會藉由更多的控制來填補差距，此時很容易陷入微管理，要求團隊更多的資訊、期待獲得預期的承諾、規定縝密的解決方案，然而在這個時候卻是最糟糕的做法。 團隊無法感受到被信任、無法自主探索、調整，無法更專注在為客戶帶來價值。
為了實現企業願景、目標，人們將採取行動，此行動與組織高層的期待、計劃不一致時，為避免此現象，組織傾向過於詳細的指令、命令。
相對於過多、過細的資訊，高層更應該限縮方向為抽象層次更高的商業目標，包含策略性意圖的定義、業務目標。
被要求過多的細節來討論順序，通常也被視為「不信任」，不信任的緣故也很容易出在團隊目標與組織目標不一致。
響應變化 > 遵循計畫
延後決策、每個層設定對應層級的目標，
知道剛剛好的知識，作出適當的決策、溝通著重於「意圖」
個體清楚理解「意圖」，
並且自主決策該層級的行動
每個層級只決定下個層級的「目標」，
並藉由反向簡報來對齊目標
響應變化 > 遵循計畫
上
下
上
下
Why
What
How
Sprint Planning
Grooming
校準：Sprint Review (Demo)
反向簡報
響應變化 > 遵循計畫
知道剛剛好就好
讓適當的人來做適當的決策
組織上下有效的對齊、修正
包含由上而下的總目標、階段目標、小目標
所以分組的目標是什麼？
包含由上而下的總目標、階段目標、小目標
什麼是剛剛好？
擁抱混亂和動盪
加速組織的學習
- 漸進式學習
- Pair Programming （熟的帶不熟的寫）
- 根據領域的漸進式學習
- 替不熟的 Story 寫驗收條件（Accept
Criteria ） - Demo 不熟悉的 User Story
- 開 Workshop 、研討會（架構、通用元件）
- 前端社團
- 元件守護者諮詢師（Component Guardians）
- 架構代碼警察
- 實踐社團
擴大學習
- Discovery Sprint
- Product Refinement 1 / Product Refinement 2
需要更多時間、精力探索的 Story
所以現在的我們是什麼模式？
我們的產品內的優先順序有許多重要條目、且目標不一致（不明確）
團隊要開發、交付的功能有許多目標、導致團隊注意力分散
注意力分散讓團隊迷失，忘記真正的目標是什麼、最重要的是什麼東西？
產品團隊現在的模式，比起目標能帶來的結果（Outcome），更重視能盡量交付完成全部的功能（Output）
產出 (Output) 模式
所以現在的我們是什麼模式？
建構陷阱
當組織陷入用產出（Output）來衡量其成功，而不是用結果（Outcome）來衡量成功，這時組織會聚焦於開發很多不同功能、頻繁進行發布，更甚於這些結果實際能帶來的價值。
公司因此停止對使用者產生價值、開始流失使用者、市場，漸入崩壞，是為掉入「建構陷阱」
如果能更有計畫安排好「有目的性」、「穩健地」產品管理行動，方可使產品團隊更能聚焦、尋找到機會，最大化業務及客戶價值，從而逃脫 建構陷阱
目的性、目標、策略
IBM, BMW 怎麼做？
Abby
Beky
Dany
A
Vicky
Doe
Kiwi
B
Bond
Winnie
Ken
C
Abby
Vicky
Ken
A
Beky
Bond
Dany
Doe
Kiwi
B
Winnie
C
Story 甲
Story 乙
Story 丙丁
Story 戊
Story 己
Story 庚
IBM, BMW 怎麼做？
Abby
Beky
Dany
A
Vicky
Doe
Kiwi
B
Bond
Winnie
Ken
C
Story 甲
Story 乙
Story 丙丁
Story 戊
Story 己
Story 庚辛
Abby
Beky
Dany
A
Vicky
Doe
Kiwi
B
Bond
Winnie
Ken
C
How it works
How it works
問題背後的問題？
1. 每張 Story 需要人力不等，調度容易
2. 因應龐大的 RoadMap
3.每個人能懂更多、對系統全貌更認識
以終為始、實驗出適合組織模式、Story 模式
北極星、船長船員們的目標對齊
擴大學習、決策時知道剛剛好就好
4. 找到黃金組合
雙向 top down 、 bottom up