L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

okr-builder

okr-builder

為產品團隊、創業公司和個人制定結構良好的 OKR(目標與關鍵結果)。當被要求寫 OKR、設定季度目標、定義關鍵結果或審查現有 OKR 時使用。產出完整的 OKR:目標、可衡量的關鍵結果、基線和評分指南。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: okr-builder language: zh-TW description: "為產品團隊、創業公司和個人制定結構良好的 OKR(目標與關鍵結果)。當被要求寫 OKR、設定季度目標、定義關鍵結果或審查現有 OKR 時使用。產出完整的 OKR:目標、可衡量的關鍵結果、基線和評分指南。"

okr-builder 的繁體中文翻譯,英文版本為規範版本。

OKR 制定

寫出有野心、可衡量的 OKR,把產品工作和公司戰略連線起來。避免虛榮指標、以產出為導向的關鍵結果,以及讀起來像任務清單的目標。

從大腦讀取 / 寫入大腦

如果存在 professional-brain(brain/),以它為依據,而不是重新詢問你已經知道的:

  • 先讀: context.md(指標定義)、knowledge/strategy.md(產品方向)以及任何未關閉的 hypotheses/。執行 python3 ../professional-brain/scripts/brain_query.py ./brain "<objective theme>",並保留每條事實的來源標註:不要把基於 [hunch] 的關鍵結果當成基於 [data] 的。
  • 📥 向大腦提議: 產出後,提議把選定的目標和關鍵結果目標值記為一條 decisions/ 記錄(這個週期的押注),把新的指標定義記入 knowledge/,都標註來源。先展示,得到同意後用 ../professional-brain/scripts/brain_write.py … --commit 寫入(只追加,預設試執行)。

從簡要說明開始工作

你常常會拿到一份簡短的說明,缺少一些細節(沒有基線、沒有確切數字)。無論如何都要交付一套完整、具體的 OKR:不要停下來提問,也不要留下 [target] 這樣的方括號佔位符。缺少基線或數字時,根據說明和領域推斷一個合理的值,並標註 (假設,待確認)。清楚標註的假設基線(例如"啟用率 40% (假設) → 60%")永遠好過空白,或被當作事實的編造數字。

延伸材料

  • references/bad-okr-gallery.md:六個真實的壞 OKR 及診斷和改寫(偽裝的路線圖、無法證偽的目標、壓低目標、不可控的關鍵結果、指標動物園、缺少護欄),最後是一個 5 問診斷。審查現有 OKR 時使用:先與樣例對照,再寫反饋。
  • templates/okr-worksheet.md:可填寫的工作表,其列強制執行品質關卡(基線來源、漂移測試、可控性測試、護欄),並附預先約定的季末評分標準。團隊想自己起草 OKR 時提供。

OKR 基礎

目標(Objective): 定性、鼓舞人心、有時間限制。回答"我們要去哪裡?" 關鍵結果(Key Result): 定量、具體、可衡量。回答"我們怎麼知道已經到了?"

好的關鍵結果的檢驗

  • 期末能否按 0.0 到 1.0 打分?
  • 它衡量的是結果而不是產出嗎?("新客戶收入增長 30%",而不是"上線 3 個功能")
  • 有野心但可實現嗎?(以 70% 達成為黃金標準)
  • 它在團隊的控制範圍內嗎?

需要指出並修正的常見 OKR 反模式

反模式例子更好的寫法
偽裝成關鍵結果的任務"上線引導改版""新使用者啟用率從 42% 提升到 65%"
虛榮指標"App 下載量達到 1 萬""新使用者 30 天留存達到 40%"
二元關鍵結果"釋出 API v2""80% 的活躍整合採用 API v2"
關鍵結果太多每個目標 6 個以上每個目標最多 3 到 4 個
沒有基線"提升 NPS""NPS 從 32 提升到 50"

總是指出反模式並給出改寫。

輸出格式

[季度] OKR:[團隊 / 產品領域]


目標 1:[鼓舞人心的定性表述]

為什麼重要: [1 到 2 句戰略背景]

#關鍵結果基線目標值衡量方法
KR1[可衡量的結果][當前狀態][目標值][如何衡量]
KR2[可衡量的結果][當前狀態][目標值][如何衡量]
KR3[可衡量的結果][當前狀態][目標值][如何衡量]

負責人: [姓名 / 角色] 跟進節奏: 每週


每個目標重複。建議每個團隊每季度 2 到 4 個目標。

要包含的評分指南

季末給每個關鍵結果打分:

  • 0.7 到 1.0 = 優秀(0.7 是"最佳點":如果所有關鍵結果都是 1.0,說明不夠有野心)
  • 0.4 到 0.6 = 有進展但未達成
  • 0.0 到 0.3 = 未達成,需要覆盤討論

輸入(未提供的可推斷,並標註假設)

  • OKR 針對的團隊或個人
  • 季度和年份
  • 公司或產品的北極星指標(OKR 應與之相連;如果沒給,推斷一個合理的並標註 (假設))
  • 本季度最重要的 3 個優先事項或目標(粗略的筆記就可以)
  • 要審查或改進的現有 OKR(可選)

指南

  • 把 OKR 與公司或產品的北極星連線起來;如果沒給,推斷一個合理的並標註 (假設),而不是提問
  • 建議每個團隊每季度不超過 3 個目標
  • 如果使用者給的是產出型目標,總是改寫為結果
  • 包含"健康檢查"部分,標出哪些關鍵結果目前沒有基線資料
  • 提醒使用者:OKR 不是績效考核,應該有野心到沒完成也沒關係

評分量表(0 到 40)

交付前給這個技能的任何產出打分;32 分以上才算可以交付。

維度0510
結果導向關鍵結果是上線功能的任務清單("上線 X"、"完成 Y")大多是結果,但有一個或多個關鍵結果是產出或二元的上線與否每個關鍵結果都是可按達成程度 0.0 到 1.0 打分的結果指標
基線與可衡量性沒有基線或衡量方法;季末無法打分有目標值,但幾個基線缺失或沒有來源,也沒有健康檢查標註每個關鍵結果都有基線、目標值和衡量方法;缺失的資料在健康檢查中標出,並有埋點計劃
野心校準目標是上季度趨勢線(壓低目標),或沒有路徑的純幻想有一定挑戰,但沒人說得清 0.7 分是什麼樣子校準到 0.7 達成就是預期中好的季度;壓低的提議和登月目標被指出並修正
戰略聚焦與可控與北極星無關;5 個以上目標或關鍵結果動物園;關鍵結果依賴其他團隊的工作與戰略鬆散相連,但目標過多,或有一個關鍵結果沒透過可控性測試不超過 3 個目標、每個不超過 4 個關鍵結果,每個目標都明確對應北極星,每個關鍵結果都在團隊控制範圍內

品質檢查

  • 每個關鍵結果都可衡量,有基線和目標值
  • 沒有產出型關鍵結果(沒有"上線 X"或"完成 Y")
  • 每個目標最多 4 個關鍵結果
  • OKR 與公司或產品的北極星相連
  • 足夠有野心,0.7 達成是預期分數

反模式

  • 不要接受產出型關鍵結果:任何寫成"上線 X"或"完成 Y"的關鍵結果都必須改寫為有基線和目標值的結果
  • 不要在不問公司或產品北極星的情況下寫 OKR:脫離戰略背景的 OKR 只是一次定目標練習
  • 不要每個目標寫超過 4 個關鍵結果:太多會分散注意力,季末打分也會含糊
  • 不要用二元關鍵結果(上線 / 沒上線):每個關鍵結果都必須能按達成程度 0.0 到 1.0 打分
  • 不要跳過基線健康檢查:沒有當前基線的 OKR 季末無法客觀打分

示例觸發語

  • “幫我寫 OKR。”
  • “訂一下季度目標。”
  • “定義關鍵結果。”
  • “檢視現有的 OKR。”
Skills enregistrées