# Ch 03. 鑑別數位能力

**"使用"** 產品 = **"僱用"** 產品，當產品表現不佳時，我們就會 **"解雇"** 這個產品

企業用 API 來展示數位能力 (武力展示的概念?)

## 確保使用者的共同目標
1. 文件應該要盡可能簡單來幫助外部使用者了解 API 的功能
2. 越多的改版很難說服使用者跟著調整，應該要在設計階段就花心思滿足使用者需求
3. 開發團隊通常會有多種角色，因此需要確保**一致性**，讓他們保持相同目標，滿足不同面向最終都能取得一致的成果

## 數位能力 Digital Capability

**商業能力**
* 如何維持市場競爭力或獲利所需具備的能力
* 展示企業的 What，代表企業所能提供的價值

**數位能力**
* 當外部使用者需要使用"程式"與企業進行互動時，**"企業所能提供的服務"** 的能力；這個能力不限定特定技術，只要是透過程式來達成，都可以認定為數位能力
* 展示企業的 How，代表企業如何提供價值

數位能力組合：當一間公司能提供一系列的數位能力時，即為數位能力組合，通常代表該企業可以整合一個平台提供給不同的使用者來串接

數位能力可以用一支 API 來當作單位，而每個數位能力可能需要根據不同的情況提供不同風格的 API 給使用者(ex. Restful API, GraphQL, gRPC, etc.)

## JTBD (Jobs To Be Done, 需要被完成的工作)
JTBD 指的是在建構產品或服務時，已經明確知道需要被完成的工作，通常會聚焦在以下3點：
1. 使用者有那些問題
2. 解決問題需要完成的事項
3. 解決問題後的整體目標

:::info
從確認用戶需求，轉化成具體的工作(Jobs)，再定義如何用產品或服務來滿足需求
* 類似 API First 的概念，不以整體專案為主，而以不同 API 當作各個小產品來滿足一個需求目標
:::

工作 (Jobs) 包含了一切能滿足用戶需求的內容，可能是新的需求，也有可能是既有需求的優化

> 工作以廣義來看，是一切能滿足用戶需求的內容? 以狹義的角度來說，是不是其實就是一種事件 (Event in Event Storming) ?

JTBD 基於用戶心聲 (VOC, Voice Of Customer)，認為應該從客戶的角度出發，以滿足痛點為目標，並透過需求訪談等等來設計產品

> 基本是讓用戶可以滿足所需使用的功能，更進階的是如何滿足用戶的 DX，讓他們覺得用得爽

:::success
原則二 (原則一在第二章)
API 應該要是目標導向，以滿足用戶需求為出發點，因此要將它視為產品，而不是只把它當成資料的傳遞之類的
:::

## 工作故事 Job Story

工作故事是要完成一個產品所需執行的**工作們**，工作故事應該是只專注在需求的知其然並知其所以然，不包含技術細節
所以工作故事有點像 Event Storming 的感覺 (先確定事件 / 先找出工作)，後續再自行補完實作細節

:::warning
在 ADDR 中，會透過工作故事來找出需求的使用情境，跟 Event Storming 感覺蠻類似的?
:::

### 工作故事的結構

工作故事由3個部分組合而成：

1. When：用戶呼叫 API 的時機，代表觸發用戶需求的事件
2. I want to：用戶決定執行的行為，他所選擇的行為會影響他最後得到的結果
3. So I can：用戶預期得到的成果，最終會成為驗收的標準之一

工作故事 - 忘記密碼
> When 我忘記登入密碼
> I want to 重設我的密碼
> So I can 再次成功登入

### 如何寫出工作故事

書上提供了幾種方式

1. 有明確的待解決問題
> 用戶明確知道他的問題，也知道他要怎麼來解決問題
* 用戶想獲得的具體成果 (先確定目標)
* 為了這個目標，有哪些事情是必須要做的
* 根據前 2 點重新審視，有沒有其他的說法可以更好的表達預期要解決的問題，確定描述是否符合，或著我們最初定的場景，會不會只是目標的一種實現而已，其實完全可以用另一種說法來更明確的表達這個問題

2. 已知要達成的目標
> 用戶知道目標，但不確定是否真的需要，可以透過以下問題來確定這個目標是否真的需要或找出工作目標
* 目標的阻力是什麼?
* 目標的事前作業是什麼
* 根據前面的問題，確定原本的目標是否真的能滿足需求

3. 已知所需的數位能力
> 用戶知道他們需要的數位能力
* 用戶想透過什麼方式來達成目標
* 需求的問題點是什麼? 何時會用到? (確認場景)
* 他們真的需要這個數位能力嗎? 還是其實有更符合的

### 工作故事撰寫時的挑戰

1. 太多細節
細節寫得太仔細，導致沒辦法聚焦在目標，而一直發散到實作細節或驗收的細節
這些細節可以放到附加細節去討論，而不該在工作故事上寫下來

> 跟 Event Storming 有點類似，事件上只寫重點，需要補充的可以再寫在旁邊
> 跟 Refinement 不太一樣，Refinement 會需要把重點細節都列出來當驗收標準

2. 太偏向功能面
可能過度聚焦在對功能或實際行為的敘述，而不是聚焦在事件本身上
容易發生在有定義出 UI 規格的產品上
一樣可以把這些寫到附加細節去，只專工作故事的內容只專心在事件上面

3. 缺乏使用情境
另一種表達場景的格式是 User Story，而 User Story 常用 "身為XXX" 來明確表達出角色，但做多了之後可能會看到很多都直接寫 "身為用戶"
在工作故事來說，可以把 I want to 的 I 改成那個角色
ex.
店員 want to 進行結帳

## 寫工作故事的技巧
目前市面上沒有適合的工具，推薦以下工具
1. Excel
一個橫列是一個工作故事，前三欄分別對應到 When, I want to, So I can
2. Doc
3. Markdown

## 範例
但看起來很智障的需求...

###### tags: `Web API 設計原則：API與微服務傳遞價值之道` `Book`