何時需要做硬承諾#
多數目標應該是「願景式（aspirational）」——我們不確定哪些會成功、達成什麼程度，企圖心也可調整。但有時候我們需要團隊做出「高完整度承諾（high-integrity commitment）」。
商業現實：有些事必須在某個日期前完成#
在所有商業領域，**偶爾都會有「重要事情必須在特定 deadline 前交付」**的情境：
- 重大產業展會的時間
- 合約驅動的合作夥伴日期
- 日曆驅動（稅季、節慶）
- 行銷活動已購買的廣告時間
領導者會走向命令與控制（特別是路線圖）的主因之一，正是「需要知道重要事情何時發生」。
要轉到賦能模式，前提之一是團隊在必要時能給出可信日期——不是路線圖時代那種低完整度的日期，而是領導者真的能仰賴的日期。
為什麼「敏捷估算」會失敗#
用慣例敏捷流程的人都知道：要給出高信心日期極為困難、有時根本不可能。
但若你並行進行產品探索與交付，要給出高信心日期就不難——前提是公司願意等到必要的探索完成（通常數天）才給日期。
不要過量#
若公司有太多日期型承諾，通常是更嚴重問題的訊號——但作者也誠實地告訴團隊：經營企業，總會有一定數量的高完整度承諾。
即使沒有外部承諾，內部也會有：
- 你需要某個平台團隊的新能力
- 多數小依賴會被當作 KTLO 處理
- 偶爾規模較大的依賴 → 視為高完整度承諾
提醒：不是每個依賴都需要當作高完整度承諾——絕大多數不是。
高完整度承諾是給：「重要的外部承諾」或「非常重要、實質的內部承諾」。
Deliverables（交付物）的處理#
當團隊被要求做高完整度承諾：
- 必須先調查這個承諾——做足夠的產品探索，讓 PM、設計師、技術主管能判斷該方案在價值、易用、可行、商業可行四個面向上是否成立
- 通常包含建立可行性原型，讓工程師了解必要工作的範圍
當團隊相信自己已充分理解解法：
- 能以高信心估算所需時間（feasibility）
- 能評估該方案是否對顧客可行（value, usability）
- 能評估是否對公司可行（viability）
體驗團隊依賴平台團隊的承諾時——平台團隊可以從體驗團隊繼承目標與 KR。
對高完整度承諾，實際的交付物必須與 KR 分開記錄與追蹤。
高完整度承諾的特殊處理#
對高完整度承諾，不討論企圖心程度——它是二元的：團隊要嘛交付，要嘛沒有。
一旦做出承諾，團隊絕對被期待要交付——出現問題的第一個訊號就要立即舉旗求援。
追蹤上：
- 公司內常會明確追蹤每筆高完整度承諾
- 有些公司中，CTO 必須親自同意每個高完整度承諾——因為她的聲譽掛在上面
賦能型團隊建立在信任之上——高完整度承諾是團隊與領導層建立信任的重要方式之一。被請求承諾日期時，務必確認團隊真的能、也會兌現。
最後警告#
高完整度承諾應該是例外，不是常態。
否則你會滑入危險斜坡——目標慢慢變成一份「交付物與日期清單」，那只是路線圖換了個格式而已。