# CH8 API團隊

雖然各家公司使用頭銜並無一致性，但是都使用了某種形式的團隊、頭銜與工作角色

本章節會討論一套通用的API角色，其代表了共同的任務與責任(組織內必須有人承擔的任務與責任)。

## API 角色

- 當看到這些角色，可以將其對應到你自己組織內的角色，如果沒有，這可能意味著你要補強公司的工作敘述，以確保API工作清單覆蓋了我們列出來的所有職責。

- 初步可分為兩個部分：商務角色[商務目標(OKR)]、技術角色[技術目標(KPI)]

### 商務角色
- 主要專注於API的商務面，有責任站在客戶的立場說話，讓產品與明確的策略目標保持一致，以及讓API對應公司範圍的OKR。

#### API產品經理
- PM，負責確保API有明確的OKR、KPI
- 確保其他成員能夠支援所需的API支柱
- 負責監測AIP，並引導成功的激勵完整的API週期
- 負責定義與描述API的WHAT(或待辦事項)
- 確保預期的開發者體驗，以滿足API用戶的需求
#### API設計師
- 負責關於設計的所有層面，包括確保實體介面可發揮作用並提供正面的開發者體驗
- 幫團隊決定API的外觀與感覺，可能也要負責聽客戶抱怨
- 必須讓整體設計符合公司範圍的既定風格準則
#### API技術撰稿人
- 負責為API產品的所有關係人撰寫API文件
- 與API設計師和產品經理密切合作，以確保文件是accurate, up to date.
#### API傳教士
- 負責在公司內部推廣與支援API實踐與文化，大型組織特別需要這個角色
- 確保使用API的內部開發者都了解它，並能夠用它來完成目標
- 聆聽Feedback並回報給產品團隊，負責DEMO、教育訓練
#### 開發者大使
- 同上，但是主要是負責公司外部的推廣、銷售、產品支援、客戶回饋

### 技術角色
- 實作API的設計、測試和部署，並讓API維持健康、可用的狀態。
- 通常負責實現重要的KPI，以及協助商務人員達成他們的OKR。
#### 首席API工程師
- 與API產品的開發、測試、監測、部署有關的所有工作和主要聯絡人(Leader)
- 負責API中的HOW，技術細節部分，並負責協調團隊的其他技術人員。
#### API架構師
- 負責API產品本身的架構設計細節，確保API可以容易與系統資源互動(包含其他團隊的API)
- 整個組織的軟體和系統架構 (安全、穩定性、可靠性)
#### 前端開發者
- 確保API提供高品質的用戶體驗。
#### 後端開發者
- 負責實作API實際介面的細節、資料儲存機制
- 執行PM與API設計師所定義之API的WHAT跟HOW
- 負責確保API投入生產之後是可靠、穩定和一致的
#### 測試 / QA工程師
- 總之就是各種測試
#### DevOps工程師
- API建構與部屬的各個層面。
## API團隊
> 一個人可以加入多個團隊
### 團隊與API成熟度
> 對決策有最大影響力的角色是

**主角**：==負責執行API中必須完成的工作角色==
>

**配角**：==起到輔助與支援的角色==
>

**團隊人數**

很大程度上受到API成熟度和每個階段所需角色的影響

#### 階段1：製作
> ##### 主角：產品經理、設計師、首席API
> ##### 配角：API傳教士、DevOps、API架構師、後端開發者
- 在不影響真實用戶的情況下，提出基礎策略和最佳介面設計

#### 階段2：發表
> ##### 主角：產品經理、API技術撰稿人、DevOps
> ##### 配角：前端開發者、設計師、後端開發者、API傳教士、DevRel(開發者大使)
- 到達發表階段，代表我們已經準備好讓User使用我們的API了！
- You need 以下這些人才
- 擅長開發
- 會寫文件
- 發現活動(宣傳你的API？)

#### 階段3：實現
> ##### 主角：DevOps、產品經理
> ##### 配角：設計師、QA、API架構師、後端開發、前端開發、技術撰稿人、開發者大使、API傳教士
- 當API實現時，回報就提升了！~~台灣價值也提升了~~

- 此刻重點在於讓人員參與，並確保API持續讓高價值的User使用
- 主要活動為：管理變動、改善部署架構

#### 階段4：維護
> ##### 主角：DevOps、開發者大使、API架構師
> ##### 配角：產品經理、首席API、後端開發
- 目的在於維持API的正常運行
- DevOps負責監測與維護已部署的實例
- API架構師：這個階段在於關注系統可能發生的變化，以及變化可能帶來的工作

#### 階段5：除役
> ##### 主角：產品經理
> ##### 配角：開發者大使、API傳教士、API架構師、DevOps、首席API
- 主要工作是策略性的，優秀的PM能夠制定一個最適合特定情況的廢棄策略。

### 擴大你的團隊
- 與許多團隊合作，如何去管理是很重要的
- 將每個API視為獨立的小組，意味著可以解決自己的問題，且對其他團隊的依賴最小。事實上，團隊必須依靠彼此才能把工作做好，而不是彼此之間完全獨立
- 制定**多團隊策略**很重要，要擁有更大的視野，了解如何將各個部分(團隊)結合成一個整體

### Spotify團隊與角色
- 小隊(Squad)
- 人數約5~7人，類似Scrum，是Spotify的基本工作單位
- 每個小隊都在一個更大型的產品團隊裡面負責一項**任務**或**工作**

- 部落(Tribe)
- 部落代表更大的產品範圍，等同於小隊的集合
- Spotify試著將部落的總人數控制在100人左右，具備足夠的多樣性以完成任務，又不至於大到難以維持健康的關係
- 分會(Chapter)
- 讓這些群體具備某種程度的效率，代表需要進行某些交流，以分享知識，並確保各團隊和產品的一致性。
- **相同產品群組的不同團隊**中，類似的角色，類似的經驗，但處理過程不盡相同，讓這些人聚在一起分享彼此經驗和知識是很有意義的。
- 公會(Guild)
- 類似分會的功能，但是面向的人是**不同產品群組**的人
- Ex:每年聚集全球各地團隊領導人參加的聚會，聚集在一起分享在各個部門的工作內容。

### 決定你擴展方法的因素
> 擴大AP團隊的正確方法取決於組織的背景、限制

>對於找出團隊擴展模式有著最大的影響力的三個因素：**組織價值、優先目標、人才分配**

#### 組織價值
- 各組織可能使用相似的技術，但工作帶來的價值往往有很大的差異
- 建議找出可用額外的投資來產生最大價值的API核心類型
> 了解你的組織優先考慮甚麼，以及它為了達成目的而願意降低哪些事情的優先順序非常重要

#### 組織規模

- 想讓API團隊在大公司裡快速發展，就必須讓他們與需互動的利害關係人、監督者、主管部門保持聯繫。
- 如果微小型的組織則要設計擴展策略，不要變成組織的瓶頸
#### 專業知識的分布
- 不同公司的人才往往存在著巨大的差異
- 如果能做出重要決定的人較少，就把他們集中起來，或找到方法來傳播他們的專業知識

### 文化與團隊

擁有正確的公司文化、人員，就能安全地將更多決策下放，同時仍維持結果的一致性

> Mel Conway對==群組互動==如何影響產出的觀察
> Robin Dunbar關於==團隊規模==如何影響溝通理論
> Christopher Alexander對==多樣性==如何影響生產力的觀察

## 結論
- 定義了一組角色，反映了設計、建構和維護API所需的決策範圍和職責
- 各種API週期階段如何影響API產品團隊的角色構成與需求，事實證明==團隊是動態的==
- 團隊規模等因素，會影響溝通的品質與最終結果的準確性，沒有跨團隊溝通可能會在組織內部產生「技術少數族群」，從而扼殺創新與創造力