# 給工程師的PM工作流 / 曾馨儀 (A5HL3Y)

{%hackmd @ModernWeb/SyA2U6SmT %}

> 共筆請從這開始

## 認識商業邏輯的爸爸：商業價值
目的：找到專案最佳施力點

:::spoiler define 專案
:::success
有明確開始跟結束時間
產出一個獨特的成果或達成特定目標
:::

以旅遊為例
分為四個階段
1. 起心動念
2. 商業價值發生
3. 專案範疇與限制
4. 商業邏輯

### 起心動念

每個專案都有高階需求
-> 從願景的層次看待自己正在做的事情

#### 專案章程
每個專案都會有的東西，看不到可以口頭問出來
- 目標目的
- 高階需求
- 關鍵利害人需求
- 正式授權

### 商業價值產生

**計畫**是為了要**因應變化**

當每個去的景點都滿足旅遊的目標，就可以滿足商業價值

### 專案範疇跟限制
1. 蒐集需求
- 找到背後原因對應其商業價值
2. 定義範疇
- 定義限制 = 什麼狀況下say no
- 定義好給過的指標 = 允收準則
3. 建立工作分解(分工)結構 WBS
- 再去找資源、籌預算、排時程、估風險

### 商業邏輯
主動蒐集到的資訊，可以幫我們提出準確的解法

### 持續改進
Lessons Learned參考架構
- Keep
- Stop
- Thanks
- Share
- Learn

## 從流程看專案
上帝視角：用俯瞰的方式在組織中釐清每個人的角色
> 個人解讀：羅列各種不同角色的工作以釐清責任

知道哪些粒度可以自由發揮，有問題要找誰

## 組織結構型態
功能式、矩陣式、專案式
專案阻力大（弱）<---->（強）升遷管道窄
專案經理掌控力（弱）<---->（強）

可以由以下幾點窺測是哪種型態
- 誰權限較大
- 專案經理是否全職
- 資源由誰管理

### 團隊決策
團隊內的共同決策制度是為了集思廣益找到最佳解

決策制定的準則為團隊成員賦能，帶來團隊能動性

團隊章程
* 成員名單
* 個人目標
* 共同目標
* 決策制定準則
* 衝突解決過程

## 當工程師遇上PMP
將 PMP 嚴謹的態度融入開發的工作流程

人
過程
商業環境

推書：[PMBOK GUIDE](https://www.pmi.org/pmbok-guide-standards/foundational/pmbok)

決策優先序
* 內部解決問題
* Trade off 錢或時間
* 向上呈報

**有原則**這件事情在職場上是會被 respect 的

管理和領導其實是不一樣的技能

## PM工具箱

1. 甘特圖：精準集中火力的地圖
看懂要徑（Critical Path）與辨識總浮時

2. WBS > WBSD > 活動清單
大事化小，小事化更小

3. RACI 責任指派矩陣
R - Responsible 責任人:負責執行工作的人員。
A - Accountable 專案責任人:對工作成果負最終責任的人,通常是項目經理。
C - Consulted 諮詢人員:提供意見和建議的人員。
I - Informed 知會人員:需要知悉工作執行情況和結果的相關人員。

## T型人才 : 工程師了解專案管理後可以達成更好的溝通

### 十大知識領域拆解
#### 利害關係人
找到關鍵利害關係人

權力：保持滿意 > 監視

| Column 1 | Column 2 | Column 3 |
| -------- | -------- | -------- |
| 高 | 保持滿意 | 密切監控?? |
| 低 | 監測 | 保持聯繫 |
| 權力/關注 | 低 | 高 |

CD表 - 利害關係人參與分析矩陣

為每個利害關係人量身定做專屬的管理策略，確保專案成功

#### 範疇

需求追朔矩陣圖

| ID | 來源 | 需求說明 | 對應專案目標 |
| -------- | -------- | -------- | -------- |
| ?? | Text | Text | Text |
| ?? | Text | Text | Text |

需求變幻莫測，寫下來才有證據爭取合理時程
> 留下證據

#### 時程

- 類比估算法
- 參數估算法
- 三點估算法
- 由下而上估算法

#### 資源
- 實體資源 physical
- 團隊資源

##### 團隊發展五階段
獲得資源 發展團隊 管理團隊
組建>風暴>正軌>風采>解散
> 組建(Forming): 團隊剛剛組建,成員間彼此不瞭解,尚未建立信任,團隊規範和角色還不明確。
> 風暴(Storming): 團隊成員之間出現衝突和爭論,圍繞目標和操作方式無法達成一致。
> 正軌(Norming): 團隊開始建立規範和角色,成員之間形成信任和合作,衝突減少,開始有共同目標。
> 風采(Performing): 團隊具高度團結和信任,成員可以高效合作,集中精力達成共同目標。
> 解散(Adjourning): 項目結束時,團隊解散,成員離開團隊,團隊生命週期結束。

[圖片來源](https://medium.com/moodwide/%E4%BD%A0%E7%9A%84%E5%9C%98%E9%9A%8A%E7%8F%BE%E5%9C%A8%E8%99%95%E5%9C%A8%E4%BB%80%E9%BA%BC%E9%9A%8E%E6%AE%B5-%E5%9C%98%E9%9A%8A%E4%BA%94%E9%9A%8E%E6%AE%B5%E6%A8%A1%E5%9E%8B%E5%B8%B6%E6%88%91%E5%80%91%E7%9B%A4%E9%BB%9E%E5%9C%98%E9%9A%8A%E7%8F%BE%E7%8B%80-%E5%89%B5%E9%80%A0%E7%99%BC%E5%B1%95-%E4%B8%8A-%E7%B8%BD%E8%A6%BD-43315a227497)

階段不一定是順向進行
新的成員加入也會讓團隊回到組建階段

#### 成本
管理層的考量，工程師是專案的成本。
準確地來說，工程師是專案的資源，而這個資源是透過付出成本來取得的。

時程和成本太抽象

實獲值 = 計畫支出 x 完成百分比

#### 品質
內驗外確
- 可交付成果
- 品質指標

#### 溝通
資訊的發布與管理
- 推式
- 拉式
- 互動式 (視訊會議)

什麼樣的資訊，用什麼方式來發布，會是最好的效果

#### 風險 & 議題

花錢消災
好事也要預判 - 減少沒想到會發生的事情

#### 採購

SOW工作說明書

#### 整合
* 寫管理計畫書
* 辨識利害關係人
* 可能升遷、離開
* 監視與管理專案
* 進行整合變更管制
* 定義好變更的流程，進行流程
* 管理專案知識
* 結束專案

---
> 討論區

弱弱問一下，甚麼是 WBS 呀？
> work breakdown structure

像他舉例的拆細工作項
> 感恩讚嘆

讚！簡報會給大家
> 立馬不拍照了
> 而且他簡報作好漂亮 (+1)
> 謝謝誇獎RRR~簡報檔有給主辦單位了後面應該會發布!
> [這邊有線上版可以先看](https://app.pitch.com/app/presentation/b663912e-bdd9-45c1-855a-cd499b9f153f/fb88783a-dbb1-4049-8bda-df99537fb5d7)

簡單明瞭

**原則很重要**對每個人都是不只PM
> 不覺得有原則的 PM 很容易變成很難搞的人

風采到底是啥？
> 產品備受市場認可吧 XD

講推拉還以為是在說Queue