techwithtam/get-to-the-point

開門見山

改寫草稿，讓決策者能立即理解需求。

決策者時間非常有限。在最初幾行中，他們需要知道發生了什麼事、需要他們做什麼、以及他們有哪些選擇。把這些放在最前面，並將支持細節準備好，以備回答問題。

細節仍然重要，用戶必須能夠解釋所有細節。這些細節應放在開場白之後，或歸入「可能提問」中。

步驟

1. 識別決策者。 確定誰會收到訊息、他們最關心什麼、他們期望多少細節、他們在行動前需要什麼、以及他們向誰報告。首先使用草稿和用戶的描述，僅詢問缺失的資訊。注重細節的決策者會提出更多問題，因此要為他們準備更多答案。需要向其上級簡報的決策者，需要一個他們能重複說出重點的措辭。當你能說出他們在行動前需要什麼時，此步驟即完成。
2. 設定單一意圖。 決定這則訊息是要通知決策者、與他們探討選項、還是請他們做出決定。每一種都需要不同的思考方式，人們需要時間從一種轉換到另一種，因此要求超過一種意圖的訊息更難回應。當草稿混合了多種意圖時，保留用戶現在需要的意圖，並將其他意圖移至單獨的訊息中。當緊急情況迫使三者合一時，保持它們的順序，並為每個意圖設定時間。當訊息只有一個意圖或一個按時間排序的序列時，此步驟即完成。
3. 定義成果。 用精確的用語陳述用戶需要從此訊息中獲得的成果及其重要性。如果草稿遺漏了其中任何一項，請詢問用戶。當你能根據用戶的事實完成這句話時，此步驟即完成：此訊息之後，決策者將……
4. 撰寫開場白。 以結論開頭。目標是三個具體的句子：需要什麼、為什麼重要、以及不行動會發生什麼。對於決策，第一句陳述決策和建議。對於更新，第一句陳述發生什麼事，接下來兩句陳述其意義以及決策者應準備做什麼。在開場白中或緊接其後列出選項，並說明每個選項的影響。這是決策者支持選擇所需的細節層級。一旦他們知道結論，就可以在閱讀時評估推論過程。沒有結論，他們會邊閱讀邊試圖猜測結論。當決策者僅憑開場白就能行動時，此步驟即完成。
5. 直接回答問題。 當決策者提出直接問題時，先給出答案，再說明條件。對是非題給出冗長的條件式回覆，看起來像在迴避問題，即使每個條件都準確無誤，這也會損害用戶的可信度。如果草稿不支持明確的答案，請向用戶尋求一個。
6. 整理細節。 開場白可能就足夠了。只在此之下添加這位決策者為理解需求並採取行動所需的內容，因為任何其他細節都會分散對需求的注意力。保留所有會改變決策的條件或風險。將其餘內容移至「可能提問」中。當草稿中的每個事實都出現在訊息、可能提問或「變更記錄」中時，此步驟即完成。
7. 準備可能提問。 列出這位決策者最可能問的問題，並根據草稿為每個問題提供答案，包括用戶已規劃的任何應變方案。決策者經常測試一個細節，以了解用戶是否了解工作。答案的品質會影響他們對訊息其餘部分的信任程度。根據問題調整每個答案，以便快速檢查得到簡短答案，而嚴肅的挑戰則獲得更多細節。當每個問題都有答案或出現在「待回覆問題」下時，此步驟即完成。
8. 編輯以獲得清晰度。 替換決策者不使用的行話、縮寫和流行詞，因為他們需要逐一轉換這些詞語。保留他們自己使用的技術術語。拆分帶有幾個修飾語的長句，並保持完整、專業的句子。刪除不改變意義的模糊措辭，因為模糊的陳述即使正確也會引發質疑。在影響決策的地方，明確說明一次真正的不確定性。
9. 檢查媒介。 使媒介符合意圖、緊急程度以及決策者的期望。資訊適合書面形式，探討選項適合對話。決策適合會議，並提前發送書面背景資料。聊天中的緊急訊息必須包含決策者需要的所有內容，因為他們可能必須在沒有後續追蹤的情況下行動。如果用戶將親自簡報，為每個要點提供一些提示詞，因為邊念完整筆記邊說話會削弱表達效果。除非媒介與意圖相悖，否則保留用戶的媒介，並在相悖時告知用戶。
10. 陳述下一步。 以具體行動、負責人和日期作結。當訊息明確說出誰接下來要做什麼時，此步驟即完成。

規則

• 僅使用用戶的事實，保留他們的語氣，並標記任何你推斷的內容。
• 向用戶詢問任何缺失的日期、數字或負責人。
• 當用戶因為曾有人挑戰他們而希望在訊息中包含更多細節時，將這些細節保留在「可能提問」中。挑戰是常態，下一次挑戰將會是關於別的事情。

輸出

按順序回傳四個部分：

1. 訊息。 改寫後的草稿，準備好發出。
2. 可能提問。 每個問題及其答案。
3. 變更記錄。 你移動、拆分或刪除的每個項目各一行，以便用戶可以恢復它。
4. 待回覆問題。 用戶需要提供或確認的任何事項。

回覆之後

當用戶分享回覆或會議結果時，確認每個人都知道接下來會發生什麼。如果部分答案足以確定下一步，則可接受。如果不能，起草一個簡短、直接的後續追蹤訊息，詢問下一步並解釋用戶為何需要它。

當結果明確時，為受影響的人起草一份簡短的決策記錄，包含決策、後續步驟及其負責人。人們很快就會忘記或重新解讀口頭協議，而記錄為他們提供了可共同遵循的相同版本。

範例

這些範例是合成的。

不要這樣做	這樣做	原因
假設風險保持在可控範圍內且供應商及時回應，我們應該可以在三月前交付大部分內容。	是的，如果供應商在週五前確認權限，我們可以在三月一日前交付。	問題是是或否。決策者一旦得到答案，就可以權衡條件。
背景，然後分析，然後第四頁的建議。	第一句給出建議，分析在其下方。	按時間順序會讓決策者等待重點。
我們需要針對遷移的後續方法達成一致。	請批准在五月十五日前遷移至 Clearline。	請求命名了行動、主題和日期。
一份包含每家供應商功能的 30 行比較表。	Clearline 每年比 Bellwether 貴 18,000 美元，而且是唯一通過試點的供應商。	決策者在不同影響之間做選擇。完整的比較表準備好以供提問。
我們該怎麼做？還有你今天能簽准嗎？	這裡有兩個選項及其各自的意義。我們需要你在週五做出決定。	第二個版本將選項和決定分開，並給決策者時間權衡。
SIP trunk 轉接處於關鍵路徑上。	上線日期取決於我們移轉電話號碼，這需要 10 天。	用戶領域之外的決策者需要翻譯第一個版本。
謝謝大家。很好的討論。	我們核准了 Clearline，Nadia 將在五月十五日前通知現有供應商。	第一個版本沒有記錄任何內容。第二個版本說明了決定及其負責人。