Use Knowledge Management to Create Release Notes Templates and Streamline Your Product Delivery Process

學習撰寫出色發布說明的秘訣、在模板中包含的內容以及如何運用知識簡化你的產品交付過程。

Table of Contents

Text Link

事實：產品發布溝通存在問題

產品發布說明的目的是讓內部團隊（從工程到客戶支持）和外部利益相關者（客戶和合作夥伴）知道產品有了更改。在科技行業，一切都以光速運行，通過發布說明提供產品更新幾乎是一個歷史問題。

我工作過的每家公司都努力使發布說明“正確”。但這是一件難以做到的事情；每個變更或產品發布的重要性會依據受眾的不同而有所變化，這些變更如何影響特定群體與功能的互動，以及該群體如何每天使用整個產品。

這些產品發布通訊（通常被稱為發布說明）需要發送給關心不同事物的受眾。作為 Guru 的收入賦能領導者，我的相關利益者是任何因產品路線圖而影響他們履行職責的人，包括：

產品/設計/工程團隊
銷售團隊（銷售運營、內部銷售、各細分市場的客戶經理）
客戶體驗（成功經理和支持代表）
市場推廣團隊（產品市場、增長推廣、品牌、內容，將主導產品的 GTM 策略和新聞發布）
業務發展和合作夥伴

所有這些合作夥伴都必須消化產品更新並立即弄清楚他們需要在多大程度上將這些更新應用到自己的工作中。他們還需要考慮如何幫助最終用戶了解任何變更將對他們產生的影響。

負責撰寫發布通訊的人（或團隊）需要考慮所有將會消費產品知識的受眾。 發布對後端工程師與零售行業的潛在客戶有什麼影響？

如何不處理發布說明

雖然考慮不同受眾的需求很難，但對產品經理或產品市場經理（PMM）來說，撰寫五個不同版本的內部發布說明也根本無法擴展。根據我的經驗，發布說明通常過長且脫離上下文，或缺乏足夠的技術性。靜態的發布說明無法提供這些洞察，通常是為作者所寫，而不是為需要了解變更的那個人而寫。坦率地說，它們通常是錯過的機會。

我參加過每週長達一個小時的發布說明會議，在這個會議上，產品管理方面的單調聲音講解幻燈片上的要點。會議結束後，這位產品經理會收到來自各個部門的電子郵件、電話（還記得那些嗎？）、Slack 等，想知道變更對他們、他們的客戶和潛在客戶意味著什麼。如果你錯過了會議，那麼你就錯過了細微差別和上下文，而只是獲得了原始的變更日誌。

但產品經理的角色不是進行這種神聖的翻譯；他們的工作是構建解決市場問題的產品。 PMM 的工作是翻譯那個意圖，讓市場了解其價值。

撰寫優秀軟體發布說明的秘訣

我是一個真善美之聲的粉絲（驚人，我知道），作為一名賦能專業人員，電影中的永恆教訓在我心中引起共鳴。 “讓我們從一開始/這是一個非常好的起點”每週都會在我腦海中響起。因此，在塑造或重塑產品交付過程時，你必須學習該語言，才能教導該主題。

1. 建立內部詞彙表

挖掘此過程的第一步是讓整個團隊講相同的語言。社交化共享術語似乎很明顯，但它可能在你的組織內並未發生。不懂縮寫和誤解語言可能會產生隔閡，造成團隊間的混淆和孤島現象。

例子：我們的市場團隊使用術語“發佈”來描述我們將如何及何時市場推廣功能。然而，工程團隊使用“發佈”來描述功能已經釋放到我們的測試環境中。對於工程來說，功能特定的發佈在客戶知道之前是“完成的”。這相當混淆且內部衝突。

沒有人想公開承認他們因為要求定義而不懂某物而說出愚蠢的話。我們的解決方案：在一個跨職能工作組（包括工程、產品、產品市場的代表）中，我們清晰化了細節並記錄了我們的產品發布定義：

注意：如果任何卡片無法加載，請刷新頁面！

2. 發布說明中應包含的內容

在建立共享語言之後，當你的團隊能夠清楚表達發布術語時，你可以撰寫說明。最簡單的做法是創建一個可重用的模板來撰寫發布說明。這樣，利益相關者在幾次迭代後會熟悉格式，並省去每次都要重新設計的麻煩。

從最低限度來看，好的發布說明包含：

發布日期
內部和外部
功能或錯誤的描述
受影響的產品（如果你有多於一個）
如果你有多個軟體產品，你也可能想要包含版本號
可以在內部詢問的地方

然而，出色的發布說明還包括：

預期的常見問題解答（FAQ）
如果有的新公共文件的鏈接
針對功能：
功能名稱
功能外觀的截圖
展示功能的視頻
功能存在的原因
它如何影響相關的買方/客戶角色

這是 我們內部使用的模板（隨意複製！）：

💡注意：指派負責的個人來執行這項任務（而不是把它留給一個團體的努力，沒有任何人負責）。工程或產品經理應負責發布說明的技術部分（名稱/版本/產品/日期/截圖），而產品市場經理或銷售工程師應負責背景信息（買方角色/為何重要）。

執行產品交付過程策略

建立一致的溝通格式

現在你已經統一了術語並編寫了模板，下一步是就一致的交付媒介（即：Slack、電子郵件、Loom、Guru、Google Docs）和方法達成一致。一致的交付媒介可確保你的發布說明利益相關者知道他們應該去哪裡或查看或訂閱（拉取），以了解發布。

這對於變更管理來說也至關重要，因為你通常需要告訴某人多次，以確保他們完全吸收這一點。根據發布的類型、對 UI/UX（用戶界面和用戶體驗）的變更，以及對客戶的影響，你的發布說明受眾需要被推送產品知識（推送）。在 Guru，我們同時採用推送和拉取的方法。

拉取：在哪裡找到知識

對我們而言，利益相關者可以在我們的 Slack #release-notes 頻道中跟進，這裡有一個一致且可消化的格式，用於從錯誤修復到全新功能的所有內容。請記住，你們的受眾不僅需要知道發布正在進行（通過 Slack 或電子郵件的拉取），更重要的是，他們需要知道該發布在背景下的意義。

發布的知識僅僅將會發生或已經發生，除非你的團隊能實際採取行動，否則這並沒有價值。為了制定一個可以提供適當上下文的一致格式，我調查了銷售代表、賬戶開發代表、業務發展人員（該行業中的各種角色），以建立我們所稱的產品交付模板“功能分解卡”，你可以在上面找到。

當一位工程經理開始開發新功能時，負責的個人會通過Asana收到警報，以使用發布說明模板創建功能特定的功能分解卡。新的功能分解卡成為我們發布的穩健的事實來源或“功能大腦”。主題專家（SME）——例如 PMM 和銷售工程師——包括發布有何價值、對誰最重要的詳細信息，以及在可能的情況下，如何演示該功能的指導，將其作為更大故事的一部分。

發布說明利益相關者，尤其是客戶經理，會一遍又一遍回到這些卡片上，因為他們發現功能分解卡上的動態知識是可信、相關且適用的。受眾現在不僅在講相同的語言，還在從同一（動態）的劇本中讀取。返回功能分解卡仍然是“拉取”方法的一部分，因為它是自我節奏的，並且在準備銷售或支持電話時進行，或者如果潛在客戶對路線圖有問題。