年度計畫
整理分享給同事，關於年度計畫的思考脈絡： 人事物時, 需求方向
事情
年度計畫看的是 #事情 為主體，
也就是公司要達到的目標。
任務的進行方式，就是專案，
#專案 講究具體的動機、預計成效
結論理應只有兩個：#開源、#節流
物指的是 #系統，具體的 #架構、或者 #服務。
會落到 Infrastructure 的東西，
要維運、要顧的，成本就是這裡。
系統會有依賴，#內部系統依賴、#外部系統依賴，
依賴 背後隱含的是 #組織依賴，以及 #溝通路徑，
也就是溝通成本。
管理系統的依賴，是技術管理者必做的任務，
不管是內部依賴、還是外部依賴。
人，
從一個人、一群人、很多群人
也就是個人、團隊、到組織。
人的存在目的是要搞定事情，
也就是任務。
年度計畫的主體是 #任務，
主軸都圍繞在任務狀況。
依照任務的狀況，討論資源 (人) 需求
確立系統的影響範圍
以及外部協作單位的對口。
但實際上人事物三者，
最難改動的是 物，也就是系統
調組織不難，
調整任務目標，也不難
動張嘴就可以。
但系統，大家都聽過 Legacy ...
十年、二十年都在那裡
然後人和事早就面目全非。
真正有魄力
應該要從系統下手
除非有固定在做架構重構 XD
Code 有重構就偷笑了 XD
常見問題
1. 把 #專案 當作 #系統
系統像是台灣地圖
台灣有多少縣市
代表多少個服務
縣市不會整天變來變去
六都升級也不是天天有的
當總統、行政首長搞清楚有哪些行政區域
是基本功課
如果是新建的國家，
就要劃分清楚這些行政區域
所以專案的需求，無論顆粒度大小，
可能影響單一系統
也有可能影響多個系統
專案 != 系統
系統可能十年都還在那裡
專案則是短期 (<3m) 的任務
常見問題：
- 搞不清楚台灣到底有多少縣市
- 搞不清楚專案的數量到底有哪些
- 搞不清楚這兩個東西的關係與關聯
影響：
- 專案看起來就小小的一個，但系統的範圍實際上很大，
- 工程師做到死，但 PO 完全搞不清楚他在忙什麼
- 專案管理會亂七八糟 ...
- 架構絕對是亂成一團
解法：
- 技術主管要與 PO 好好對齊專案與系統的關係。
2. 搞不清楚系統的內外部依賴
依賴關係的管理是技術管理的基本功課
也是技術管理者的職責
這些資訊理應在系統的 config 會有很清楚的資訊
同時這也代表著當需求進來時
就應該知道影響哪些依賴
而依賴就代表組織關係
專案管理就應該做好協作的準備
如果是內部依賴於其他系統 (團隊)
那就要做好內部協作準備
常見的問題：
- 技術管理者搞不清楚依賴狀況
- PO 更不會知道
- 專案開始進行了，被依賴的單位不曉得有關係，造成插件
解法：沒啥好說的，做好該做的 #系統設計 (System Design)
技術管理者做不好這件事情，應該沒資格上那個位置。
3. 任務的屬性重要性的區分與判斷？
需求來源是有方向性的 2，分 #內部需求 與 #外部需求
#業務驅動 屬於外部需求，跟業績有關 (#功能性)
所以通常優先序也高
屬於 #開源 需求，直接跟業績掛帥
技術驅動屬於內部需求，跟業績無關 (#非功能性)
但跟 資安、架構、維運、成本、風險有關
這種東西背後的成效都是 #節流 #降低風險 #提高生產力
年度計畫中的任務
都會有功能性與非功能性
依照組織的特性
比重也會有落差
思考
用表格整理計畫的時候
第一個縱軸擺的東西就是主軸。
第一軸擺系統，代表以系統為主體，通常技術主管會這樣做。
擺人，代表優先考慮資源，通常組織人力資源拮据的時候，會這樣做。
擺事，代表以任務優先考慮，通常 PO / PM 會這樣做。
#人事物時 的 時 還沒寫
跟企業發展階段的策略有關。
懶的敲了 XD
再敲下去就去開公司好了。。。
我覺得應該開個 podcast 來講一些東西。。。
原始資料
- 發表時間：2022/11/24
- 原文連結