為什麼你的產品決策總是會被重新討論？

一個產品團隊花了兩週時間評估是要構建原生行動應用程式還是漸進式網頁應用程式（PWA）。他們研究了各種選項、諮詢了工程部門的可行性、分析了使用者數據，並根據一組特定的限制條件決定採用 PWA 方案。該決定在多個 Slack 討論串中進行了討論、在會議中進行了辯論，並在後續訊息中得到了確認。開發工作隨即開始。

三個月後，一位新副總裁加入。他們問道：「我們為什麼要做 PWA 而不是原生應用程式？」沒有人能迅速給出推理過程。Slack 的討論串早已被洗掉。會議沒有錄音。後續訊息也淹沒在一個擁有數千條訊息的頻道中。於是，討論重新開始。提出了一模一樣的論點。進行了一模一樣的分析。兩週後，得出了相同的結論，這消耗了當初同一批人（除了已經離職的人）以及引發重新討論的新副總裁的時間。

這種重複爭論的模式是產品組織中最常見且成本最高的低效行為之一。它浪費時間、挫傷團隊積極性，並耽誤了依賴該決策保持不變的後續工作。

為什麼會發生這種情況

決策通常是好的。推理通常也是合理的。問題在於，推理過程沒有以一種在問題再次出現時便於查找的形式保存下來。

產品決策通常是結合了 Slack 討論、會議和非正式對話做出的。每個渠道都記錄了部分推理過程，但沒有一個渠道能以可搜索、永久保存的形式保留全貌。決策散落在三個 Slack 討論串、兩次會議以及一份雖然分享過但從未歸檔到任何易於查找之處的 Google 文件中。

當有人問「我們為什麼決定這樣做？」時，團隊無法迅速給出答案，因為拼湊答案需要搜索多個渠道、重建時間線，並回憶在哪裡進行了哪次討論。尋找推理過程的阻力很大，以至於重新討論往往比去考證研究更容易。

解決方案：決策日誌

決策日誌記錄了每個重大產品決策及其推理、替代方案和限制條件，透過讓答案變得立即可查，從而防止重複爭論。

格式很簡單：問題是什麼、考慮了哪些選項、決定了什麼、為什麼，以及需要改變什麼才能重新審視該決策。當新副總裁詢問「為什麼是 PWA 而不是原生應用程式？」時，團隊會引導他們查看決策記錄。副總裁閱讀了推理，理解了限制條件，要麼接受該決策，要麼提出原團隊未曾考慮的新因素。無論哪種方式，原本會消耗兩週時間的重複爭論，都被壓縮成了 15 分鐘的閱讀。

挑戰在於如何持續建立決策日誌，這正是 自動撰寫文件 發揮作用的地方。當系統捕捉到辯論 PWA 決策的 Slack 討論串以及確認決策的 會議，並從這些來源生成結構化的決策記錄時，日誌就在無需任何人單獨撰寫文件的情況下建立了。決策是在團隊的日常工作流程中做出的。而文件是從該工作流程中自動生成的。

複利效應

決策日誌隨著累積而變得更有價值。六個月後，團隊擁有了一個可搜索的決策及其推理的存檔。一年後，他們擁有了關於產品如何演變以及原因的完整記錄。新團隊成員可以閱讀決策歷史，以了解不僅產品是什麼，而且它是如何發展成那樣的，這種上下文資訊可以防止他們提出重新討論已定結論的修改建議。

決策日誌還能隨著時間的推移提高決策品質，因為它為推理建立了問責機制。一個記錄了依據的決策可以進行回顧性評估：當時的推理是否合理？限制條件是否準確？我們今天還會做出同樣的決策嗎？如果決策及其推理在做出後幾週內就遺失了，這種反思實踐是不可能實現的。

常見問題

什麼樣的決策才算「重大」到值得記錄？ 任何影響產品方向、架構、優先順序或範圍，且您預計日後會有人問起的決策。如果新團隊成員很可能會問「為什麼會這樣？」，那麼推理過程就應該被記錄下來。日常的具體執行決策則不需要日誌。

這不會減慢決策速度嗎？ 當決策記錄是從現有討論中自動生成時，就不會產生額外的時間成本。團隊依然以同樣的方式做出決策（Slack、會議、文件）。記錄只是作為副產品自動發生。

如果因為情況發生變化而需要重新審視決策怎麼辦？ 決策記錄應包括「需要改變什麼才能重新審視此決定」。當滿足這些條件時，重新開啟決策是合適的，且該記錄提供了起點。這與重複爭論不同，重複爭論是在沒有新資訊的情況下重新開啟決策。

延伸閱讀：如何構建產品知識庫、您的代碼有文件記錄，但您的決策沒有、文件債。相關頁面：決策日誌、自動撰寫文件、致產品經理。