2016 10 18
規格文件該怎麼撰寫？
相信團隊中的每個角色都有各自的看法，大家所持的意見都有各自的道理，也都有其優缺點。
- RD 期待的文件
希望只要照著文件的指示開發即可，不需要動腦去思考文件內容。
- QA / QC 期待的文件
希望文件能包含開發實作的邏輯及狀態，讓產品的測試案例能夠更完整。
- 業務期待的文件
希望每個畫面、每個功能都有詳盡的說明，讓客戶的問題能夠快速找到解答。
然而，我們常常被自己不切實際的期待與幻想綁架，希望能有一份文件是能夠幫助自己工作更為順暢，卻忘了去了解文件是怎麼生產出來的，也忘了文件是要給人看的。
該為了滿足每個人的期待而分別撰寫三份文件？還是同一份文件盡可能滿足個別需求？以及未來如何共同維護、更新文件都將是一大難題。
常見的謬思
- 規格文件寫得越多、越詳細、越完整越好。
越多越詳細越完整，代表文件很龐大累贅，查詢不便、修改維護不易、所耗費的隱藏工時也有可能日積月累，最後成為團隊的負擔。
- 規格一但交付後，要修改得經過重重關卡審核，避免反覆的修改造成不必要的工時成本。
早期的 Waterfall 流程也許適用這種做法，但現在市場狀況、用戶喜好瞬息萬變，改一個需求若需經過一兩個禮拜的時間才能定案，早就喪失市場先機。
- 認為文件做得好，產品才能做得好。
文件的好壞取決於團隊成員是否能夠清楚透過此文件進行溝通，就算文件格式再完整、寫得再好，沒人看的文件就是不需要存在的文件！
文件怎麼寫才好？
這其實沒有一定的答案，根據不同產品屬性、組織架構、企業文化...等不同，會有各自合適的做法。
下面提供幾個思考的切入點做參考
- 目前產品處於什麼時期？
如果只是在開發 MVP，都還不確定是否會長期經營下去，根本不必在乎是否有正式的規格文件，你需要在意的是目前的溝通效率夠不夠高！
- 了解產品跟團隊特性
若你們的產品是販售給企業客戶，對外理當會有制式規格書。
若是針對一般市場使用者，你該在意的是怎麼吸引用戶來使用你的產品，而不是寫一長串的說明文件，記住！沒有用戶會看你的說明文件！
- 維護文件的成本是否值得
要記住，寫文件是為了溝通！若維護文件的成本高於寫好文件所省下來的溝通成本，那你得好好衡量這樣做是否恰當。
若演變到最後，整個團隊都花許多時間在維護文件上就變得本末倒置了！
