PRD 一日密集課：手把手教你的第二場，是企業包班，這也是我第一次來到別人公司裡去教課，現場的環境真的是比小樹屋好太多了，桌椅又新、螢幕又非常清楚，不過令我比較意外的是這堂課是連老闆、設計師、前端工程師、專案經理一起進來上 PRD 一日密集課了。
想要來上PRD 一日密集課的主因
這間企業是屬於乙方接案性質，因為想要最佳化現在的內部流程，主要的問題如下：
- 專案多樣，導致資料與文件分散
執行項目涵蓋 Landing Page、數位廣告物、平面文宣與大型輸出等設計型專案，文件標準化難度高，容易產生資訊紀錄分散、整理不易的狀況。 - 高度依賴口頭溝通，提高紀錄風險
目前仍較仰賴口頭交辦與臨場補充，將造成資訊落差與認知誤差，無法追溯原始需求，進而影響執行準確性與效率。 - 客戶需求缺乏聚焦，難以落實規格化
客戶初期說明多偏向方向或雜訊，需主動進行需求彙整、優先排序、框架確認與範疇界定，才能讓執行人員清楚任務內容與重點。 - 流程溝通耗時，常出現多方意見干擾
即便為單一頁面，需求仍可能來自不同部門，各有主張與修改建議。內部流程反覆討論與意見整合所耗時間，往往大於實際設計與製作。 - 甲方流程不穩定，易波及乙方作業
已確認的稿件後續被退回重改、審核權責不清、窗口與上級指令不一致等，使執行進度受阻，且責任歸屬常落於乙方。 - 專案後期常見執行細節出錯
圖檔容量超標、Logo 遺漏、字級錯誤等問題，容易因缺乏文件驗收項目與設計提醒而遺漏，應於初期文件即定義清楚。 - 執行者對專案缺乏整體邏輯與脈絡理解
僅依據 PM 口頭任務指派，易導致執行者只見其一、不解全貌，產生結構誤解或設計優先順序錯誤，進一步增加改稿頻率。
因為我過去剛好曾在某間公司擔任類似的甲方角色，所以在出發上課前，我先打電話問了當年的同事，回顧我們當時是怎麼和乙方協作的，也釐清為什麼我們會成為問題那一方。
這次教學的重點之一，就是讓乙方學會如何應對這類甲方。因此，在 PRD 教學內容上也做了一些調整。例如，以前做產品時只需要填「修訂追蹤表」，但換作乙方角色時，就必須用「需求變更控制表」，明確記錄甲方的變動造成了哪些新增工時、是否影響交期。
這些做法可能無法改變太「機車」的甲方，但對於愛面子的甲方，至少能讓他們清楚知道，延誤專案的責任是從哪裡開始的。
一樣，先來檢討自己
這次因為所有學員都使用 Figma 進行實作，導致在撰寫內容時無法完全比照我原本用 Axure 製作的範例格式，這讓後續負責聆聽簡報的工程師在理解上出現了不少困難。這也讓我開始思考：是否該轉向使用 Figma 作為教學主軸？畢竟我目前所有的 PRD 文件都是以 Axure 編寫為主，這可能成為一個未來的教學門檻。
另外，這次沒預料到會有學員忘記帶筆電充電器，導致無法參與實作，只能和另一位學員共用電腦、旁觀簡報。這讓我意識到應該要事先規劃「設備備案」，針對學員若沒帶電腦或設備故障的情況，準備應變措施。
這次時間真的不太夠，原本希望每位學員都能完成全部內容，但因為現場討論和互動很多，最後只能讓每人負責一個模組來實作。未來可能需要調整，把每個人要完成的任務範圍再縮小一點，才不會做不完。
另外，如果每個人做的都是同一個題目，那上台簡報時，工程師就會連聽六遍一模一樣的內容。或許應該反過來，讓大家的題目不同，但實作的範圍和角度要錯開，這樣才有助於呈現多樣性，也比較不會浪費聽眾時間。
學員們的目標都很明確
這次的學員目標都很明確，就是希望能快速建立一套文件制度，協助他們在與甲方互動時，有一個清楚的依據與流程。這樣一來，就不用再靠大量口頭溝通或是反覆翻 LINE 對話來確認專案內容，減少誤解與遺漏。
其中一位學員是老闆、業務與執行三種角色集一身，口條流暢、簡報能力很強。即使簡報內容和其他同學稍有不同，但他的臨場反應非常好，能快速補足缺口。
另一位則是典型的專案經理角色，平常會跟老闆一起去聽甲方需求，也是把外部資訊轉化為內部執行資源的關鍵人物。在課堂互動上表現流暢，溝通上沒有任何問題，現在需要的就是整理出一套可複製的範本，方便公司其他同仁後續沿用。
一位設計師在撰寫 PRD 時展現出極高的細節掌握度，幾乎能預判甲方會在意什麼、可能想改什麼，完全對得起「通靈甲方」的能力。
另一位設計師則非常縝密，考量模組中涉及互動操作，特別在 PRD 裡標出幾個需要前端工程師注意的關鍵點，還運用了 wireflow 來說明流程，甚至連使用者填錯資料的錯誤提示都定義好了，邏輯完整、思考到位。