2025年3月16日
•5分鐘閱讀
在某次會議討論完之後，各種渺然的需求不斷的被拋出來，腦袋也是一片茫然。不是說在技術上做不到，而是對於整個產品、邊界在哪沒有清楚的想像。於是會議之後，我敲了同事一輪：
「你知道剛剛 OO 說的意思是什麼麻？」 「不確定噎，有些可能在技術上不可行。」
問過了所有同事一輪，大家都沒有共識的想法，開發的方向上總是在撞牆，於是乎我也找到問題的方向了——我需要為自己寫一份開發文件。但問題是怎麼說才說得清楚？同時對開發又有幫助呢？
一開始曾經有試過將自己手邊整理的筆記，請 ChatGPT、ChatPRD 等幫忙整理成開發文件，但總覺得怎麼嘗試 promt，總有一種說不出來的奇怪感：
ChatGPT：https://chatgpt.com/canvas/shared/67d6af74464c8191b44d33510ceb21f4
技術選擇：雖然整理了一份文件，但是對於規劃真實的開發情境還是有些落差。但是基於什麼樣的原因做技術選擇、時程安排、需求分析等等，似乎無法真正的說出來。甚至是應用在比較複雜、或是比較模糊的需求，也無法做出比較務實的規劃。
協作/可編輯性：以 AI 來說，似乎一次的對話產出就結束了，但以真實的開發需求來說，可能每週、每個月都在調整改變，甚至在比較大的公司來說，還需要顧慮到不同的部門如何看待這個專案。以預設的格式來說，看不太到這份文件可以協作的地方，同時比較難在未來擴充、整合。
評估過這些考量之後，或許工程師可以鬆一口氣了（？）。針對特定領域的 Domain Knowledge ，還是要依靠對於專案/領域的了解，包含需要將更為複雜的組織、需求等考慮進去，才能真正寫出一份能夠派上用場的開發文件。
當發現 AI 派不太上用場，因此開始去思考，其他公司是如何寫開發文件的。
或許是被演算法發現我最近想寫 PRD ，因此無意間刷到了這篇文章 12x Real PRD Examples | Best PRD Templates，看完一輪文件之後發現還是 kevinyien: PRD Template 比較對得上眼。
簡單來說這份文件的 PRD 的架構是這樣的:
同時我也很喜歡這份文件為主要的方向提出了一個大塊架，沒有愛多的規範限制，甚至需要使用哪種表格、圖表等等，就看個人及團隊的習慣了。同時這份文件也很在乎是否把『需求溝通』給說清楚，在大家的理解不一致時，那麼更需要做的是需要慢下來，把需求溝通清楚，然後才是開始寫程式碼。
在某次的活動中，和其他廠商的工程師聊到。一個產品能夠成功推出有很多原因，我們很大一部分的工作是要把功能的邊界畫出來，我們能做什麼、哪些不能做、擴充性講清楚，接著才開始開發。
以網頁的前端來說，由於 CORS、及瀏覽器安全性的限制，我們無法直接存取 File System 的資料（試想如果今天你進入了 google.com，但是 Google 可以存取到放在個人電腦的金鑰，這不是很可怕嗎）。但是以後端、Android 來說，可以透過如 node:fs、java.io.File 等等來操作文件系統。如果今天的使用情境是在離線的情境，那麼 React 可能就不是最佳解。
另一個例子是，今天客戶想要針對 OsmAnd 寫一些擴充套件，但哪些是開發者能做到的？那就要去研究 OsmAnd API & SDK 文檔、或是可以與哪些 Android 原生的 API 互動，甚至是評估效能。
在每個階段的評估、實作之後，習慣上我會將這些技術比較整合成一個文件，作為階段性的目標、及未來參考的依據。承接 PRD 上面里程碑的概念，在啃完技術文件之後，也才能決定哪些時候可以辦到哪些事情。而開發的週期，就像是定期的在界定邊界、評估、擴展等等。
上禮拜參加 GDG Taipei 的活動，聽到一句很深刻的話：『在 AI 的世界裡，比起去在意我們什麼時候會被 AI 取代，更重要的是我們該如何利用 AI 來精進我們的工作流』。
以一個團隊來說，不同角色習慣的文件管理模式可能是不同的：
…
當 PRD 可以將不同角色的目標聚焦在一起時，或許下一步可以思考如何將文件整合進團隊的工作流。像是透過語音辨識、搭配離線部署的服務等，來自動化整合文件的內容，或許也是我想嘗試的目標。
前幾天臨時要去維護一份前幾個月寫過的專案時，其實還滿慶幸自己平常有好好寫文件的習慣，不然真的會忘記怎麼打開專案。寫文件也是多了一次的輸出，在軟體開發如此快速的環境中，讓自己有一份反思、回顧。同時對於團隊來說，更是用來減少誤會、統整共同的目標。
至於平時不寫文件、也不看文件的人，你需要靠的是通靈師，而不是工程師。
最近也在透過練習，來讓自己對於產品、開發流程有更多的掌握度，也在探索什麼是比較適合自己的文件格式。或許有很多混亂的開發環境，不過這一次就幫自己留下文件吧。