WHY｜決策消失了，麻煩才開始 「當初為什麼這樣決定？」這句話在專案中後期常常出現。新成員加入，沒有人告訴他背景。產品方向調整，舊的決定被重新質疑。某個功能被砍掉，但三個月後又有人提議做回來。 這些情況有個共同點：決策當下有人知道原因，但沒有記下來。 Decision Log 不是繁瑣的文件作業，是讓團隊不用一直重新解釋、不用靠記憶維持共識的工具。 WHAT｜Decision Log 是什麼？ Decision Log 就是一份表格，把每一個重要決策記下來，包含： * 什麼時候決定的 * 決定了什麼 * 為什麼這樣決定（背景、考量、取捨） * 誰決定的 * 影響範圍 一個基本的欄位設計長這樣： 日期 決策描述 背景與原因 決策者 影響 狀態 2024/06/01 不做 iOS 版，先只出

WHY | 為什麼你需要 RACI？ 你有沒有遇過這種情況：一個任務大家都以為別人在負責，最後沒人做。或者一個決定討論了三次，還是不知道誰有最終決定權。 這不是團隊的工作態度不好，是合作安排出問題。 團隊裡的角色沒有明確對應到每一件事，就會出現三種狀況：重工（兩個人做同一件事）、漏接（沒人做），以及決策卡關（沒人敢拍板）。 RACI 就是來解決這件事。它不是複雜的框架，只是一張簡單的表格，把任務對應到四種角色，這樣每個人就清楚自己應該做什麼事。 WHAT | RACI 是什麼？ RACI 是四個英文字的縮寫，代表四種角色： R — Responsible（執行者） 實際動手做事的人。一個任務可以有多個 R，例如工程師、設計師都是執行者。 A — Accountable（當責者） 對結果負責的人，最終審核和拍板的那個人。每個任務只能有一個 A，不能是零，也不能是兩個。當責任被分攤，就等於沒有人真的負責。 C

產品經理最重要的工作之一，就是實現各部門千奇百怪的願望，我都笑稱PM是神燈裡的精靈。而精靈最頭痛的事情，不是實現願望，是了解願望。因為一但理解誤差，就會像 "神鬼願望" 電影裡的惡魔，錯把 "變成有錢人" 這個願望，實現成 "販毒致富的毒梟" 現實工作上，為了避免這種誤差，PM身為稱職神燈精靈的責任，就是要把這些千奇百怪的願望 ，具體轉成開發團隊能理解的需求，並且確認需求最終帶來的結果和公司的走向一致。這就是PRD的目的及價值。 什麼是PRD Product Requirement Document ，產品需求說明書，顧名思義就是制定需求的文件。有一點需要注意，和開發團隊討論需求時，最忌諱只談論要做什麼（What），而忽略了為什麼要做（Why）。後者代表需求的終點，也就是需求帶來的價值，而前者只是實踐價值的過程而已。有了終點，團隊就知道該往什麼方向努力，有時優秀的團隊甚至會以技術立場提出比PM更有效率的需求，這就是讓團隊有共同目標的優點。 所以PRD除了詳細紀錄功能描述之外，更重要的是把stakeholders的目標，需求帶來的價值以及要完成的目的都記錄下來，