學習要點

讓團隊成員在執行前充分溝通，減少誤解與無效開發。

故事描述

什麼是最快的開發方法？其實，最快的方式就是一次做對。反覆修改是最浪費時間的，尤其開發出不符合需求的功能，甚至可能被要求完全重做。

我早期職涯待在專案型公司，多數時候設計師會先與客戶定稿，然後我再依照設計圖進行實作。至於畫面背後的邏輯，只要顯示資訊正確，沒有人會檢視你用了什麼實作方法。

然而，當我加入產品型公司後，我發現情況完全不同。這裡，功能正常運作僅是基本要求，還要顧慮 API 的設計，是否方便他人介接。同事在進行代碼審查（PR）時，可能會指出不同的實作方式。例如，你選擇了 A 方法，他們可能建議用 B 方法，並解釋為何 B 方法在現有情況下更合適。

儘管你認同他們的建議，但此時已經到了代碼審查階段，代表開發時程已經過了一大半。改用 B 方法可能會延遲上線時間。然而，不改的話，久而久之，你可能會被認為是個不接受建議的人，同事未來可能也漸漸不再願意提供有價值的意見。

有時，你可能忽然被調派到一個不熟悉的專案中支援開發，對於 codebase 的熟悉度較低，不知道 codebase 中已經有類似功能可以引用，而浪費時間重新寫了一個類似的功能。

有時，要開發出真正貼近利益相關者（Stakeholder）需求的功能，也是一個挑戰。例如，若需顯示大量資訊，應該先決定哪些資訊優先展示、哪些放後面，或者將資訊切分成多個頁面。這些都沒有標準答案，如果不事先協商清楚，可能會導致他們對最終成果不滿意。

或許你會覺得，UI/UX 這些問題不應該由設計師先與客戶確認好，然後再交給開發人員實作嗎？這是理想狀態。然而，實際情況中，需求來自四面八方，不僅是外部客戶，還可能來自內部員工。而在大家都搶著使用設計師資源時，你很難佔用設計師的時間，這時候你就得自己來。

啟發

我們需要一種更有效的方式，來提前確保開發出的成果能讓所有人滿意，那就是寫 RFC。

理論：RFC

RFC（Request For Comments）是一種文件形式，主要用於徵求有關技術規範、協議、功能或軟體設計的建議與評論。讓我們可以在開始真的動手之前，評估最佳解決方案，確保執行的方向正確。

撰寫 RFC 的核心目的

• 問題明確化：RFC 讓開發團隊可以在執行工作前，清楚定義問題以及想要解決的目標。

• 徵求意見：通過發布 RFC，邀請開發團隊、設計師或利益相關者對解決方案提出建議或修改意見，讓設計方案更全面。

• 降低風險：RFC 文件在項目實施前確保所有人都對問題有相同理解，並且達成一致意見，從而避免在項目中後期出現方向錯誤，或無法回頭的狀況。

• 參考依據：一旦 RFC 文件確定，它可以成為未來開發和測試的基礎文件，並且隨著需求變化進行版本更新。

由於這一篇文章篇幅較長，所以實踐 RFC 的部分，將在下一篇文章探討。