132 lines
4.0 KiB
Markdown
132 lines
4.0 KiB
Markdown
# 影響力敘事工具箱
|
||
|
||
## 1. 基礎改寫公式
|
||
|
||
### STAR / CAR
|
||
|
||
```text
|
||
為了[業務目標或技術挑戰]，
|
||
我[採取了什麼關鍵動作]，
|
||
最終帶來[可量化或可感知的結果]。
|
||
```
|
||
|
||
示例：
|
||
|
||
- 修改前：負責訂單系統開發
|
||
- 修改後：為解決大促期間訂單查詢緩慢問題，主導設計並落地基於 Redis 的緩存方案，將平均響應時間從 800ms 降至 120ms，並支撐峰值 10 萬 QPS。
|
||
|
||
## 2. 決策-權衡寫法
|
||
|
||
當經歷裡存在技術選型、架構權衡、複雜約束時，優先用這個結構：
|
||
|
||
```text
|
||
為解決[問題]，
|
||
評估了[方案 A] 與 [方案 B]。
|
||
我選擇[方案]，因為[關鍵理由]，
|
||
並通過[補償措施或實現細節]控制風險，
|
||
最終實現[結果]。
|
||
```
|
||
|
||
示例：
|
||
|
||
- 修改前：使用 Kafka 實現消息隊列
|
||
- 修改後：為解決跨服務數據一致性問題，在 RabbitMQ 和 Kafka 之間進行技術選型。考慮到未來吞吐增長和實時計算需求，選擇 Kafka，並設計冪等消費機制降低重複消費風險，最終支撐日均 5000 萬條消息處理且未出現數據丟失。
|
||
|
||
## 3. 常見改寫方向
|
||
|
||
### 從職責改成成果
|
||
|
||
- 修改前：負責用戶模塊開發和維護
|
||
- 修改後：主導用戶模塊重構，拆分服務邊界並補齊單測，使新功能交付週期從 2 周縮短到 3 天，單測覆蓋率從 30% 提升到 85%。
|
||
|
||
### 從“做事”改成交付產物
|
||
|
||
- 修改前：負責搭建內部工具
|
||
- 修改後：設計並交付內部發布平臺，將原本分散在多個腳本中的發佈流程統一到一個可複用平臺中，覆蓋研發與測試團隊的日常發佈操作。
|
||
|
||
### 從過程改成價值
|
||
|
||
- 修改前：優化頁面性能
|
||
- 修改後：通過代碼分割、懶加載和 CDN 優化，將首屏加載時間從 4.2 秒降至 1.1 秒，跳出率下降 15%。
|
||
|
||
### 從“做了什麼”改成“為什麼這樣做”
|
||
|
||
- 修改前：開發數據處理 pipeline
|
||
- 修改後：設計並實現基於 Spark 的實時數據處理 pipeline，日均處理 10TB 用戶行為數據，將數據延遲從 T+1 縮短至分鐘級，為運營側提供實時決策支持。
|
||
|
||
## 4. 沒有量化數據時怎麼寫
|
||
|
||
如果用戶拿不出精確數字，不要硬編。可以換成這些結果表達：
|
||
|
||
- 建立了可複用標準
|
||
- 消除了某類線上風險
|
||
- 讓某項流程從手工變成自動化
|
||
- 讓排障、觀測、發佈更可控
|
||
- 讓跨團隊協作更順暢
|
||
|
||
示例佔位符：
|
||
|
||
```text
|
||
[量化數據待補：例如每週節省 6 小時人工處理時間]
|
||
```
|
||
|
||
## 5. 量化優先級
|
||
|
||
優先從這些角度找數字或可驗證變化：
|
||
|
||
1. 性能：延遲、吞吐、成功率、可用性、錯誤率
|
||
2. 業務：轉化率、GMV、留存、訂單量、收入、客訴量
|
||
3. 效率：人天、發佈時長、排障時間、交付週期、手工步驟
|
||
4. 規模：用戶數、接口量、數據量、服務數、團隊覆蓋範圍
|
||
5. 風險：事故次數、故障恢復時間、重複問題、誤操作概率
|
||
|
||
如果拿不到精準數字，降級為：
|
||
|
||
- 高頻/低頻
|
||
- 分鐘級/小時級/天級
|
||
- 單團隊/多團隊/全公司
|
||
- 核心鏈路/關鍵系統/基礎設施
|
||
|
||
## 6. 產物導向模板
|
||
|
||
當原文只有職責，沒有明確交付物時，優先套下面結構：
|
||
|
||
```text
|
||
為了解決[問題]，
|
||
我設計/重構/落地了[產物]，
|
||
被[團隊/系統/用戶]使用，
|
||
最終帶來[結果]。
|
||
```
|
||
|
||
常見產物包括：
|
||
|
||
- 系統
|
||
- 平臺
|
||
- 服務
|
||
- 工具
|
||
- 組件
|
||
- 規範
|
||
- 機制
|
||
- 流程
|
||
- 看板
|
||
- 自動化腳本
|
||
|
||
## 7. 啟發式提問
|
||
|
||
當原始材料太弱時，用問題把亮點挖出來：
|
||
|
||
- 這個項目裡最難的問題是什麼
|
||
- 為什麼當時選這個方案，而不是另一個方案
|
||
- 你真正交付給團隊或業務的產物是什麼
|
||
- 你的改動到底讓誰受益了
|
||
- 沒有你的這項工作，會造成什麼問題
|
||
- 有沒有一個可以證明結果的數字、比例、範圍或變化
|
||
|
||
## 8. 一句話判斷標準
|
||
|
||
一條好的項目描述，至少滿足下面三項中的兩項：
|
||
|
||
- 說清了問題
|
||
- 說清了你的動作
|
||
- 說清了結果
|