（最近這些嚴肅的痛點，都無法讓我發揮幽默的實力。還請讀者見諒）
在我寫了九年產品規格的PM生涯中，對於撰寫產品規格的建議，只有幾句話：
規格永遠不會完美，產品經理要做的事，是讓整個團隊意識到，規格不是只是PM的範疇，而是是促進大家溝通的管道。大家共同協助PM記錄到位，可以減少很多重複溝通，翻閱程式的心力。
不過話說回來，PM要怎麼撰寫一份好懂又齊全的文件呢？
一套框架
PM該寫的文件，一般被稱為「需求書」或「規格書」，英文可稱為product specification 或product requirement document。兩者聽起來都很嚴肅，所以PM第一步該做的，也許是定義這份文件裡面會包含哪些元素。
許多PM的規格書去頭去尾，開頭直接附上幾張UI 或流程圖，接著奉上跟工程師討論的硬細節，最後也沒有附上任何來龍去脈。
頭，容我建議你寫好下三點：
- 我們為何要開發此功能？（這功能產生前的背景，產品目標，介紹一下吧？）
- 我們的用戶會怎麼使用這項功能？（用戶用起來的情境，好歹也跟我說一下吧？）
- 這些功能有什麼基本限制與條件？（最基本的限制，開發應該要知道吧？）
上面內容齊全後，你再開始透過文字描述新功能的各種使用情境與細節。這會讓整份文件更有說服力：有點類似兩位朋友拜託你幫忙看家，一個跟你說：「拜託你來幫我顧家，鑰匙在鞋盒、冰箱有牛奶你可以喝、十點的時候記得鎖門。」；另一位拜託你時則跟你說：「拜託你幫我看家，因為我跟先生需要南下照顧雙親三天，我們實在找不到其他人可以幫忙。看家內容如下…」
尾，請讓我建議你附上你的靈感來源（參考連結，出處的意思）
不要以為每個人都為記得這項需求的前因後果，記錄故事比你想像的重要得多。若你在思考第一點時無從下手，那也表示這個功能並不需要做（你自己都不確定了！）
我喜歡有些人把這份文件稱為product page 或product summary。
Test-driven Development
描述一個功能該如何與用戶互動的相關細節時，我傾向使用「測試導向開發」方法撰寫產品的規格細節。其實這是一個非常簡單的架構，也容易套用：
Given – When/ If – Then
意思是：給定（某條件），當（用戶或系統）…，（用戶或系統會）….
例：假設用戶登入的狀態下，當他點擊「查詢密碼」，他會被導引到（或app會導引他到）查詢密碼頁面。
正面列表需求
PM可以視情況以不同方式描述規格細節。另外一種寫法為正面列表一功能該有及不需要處理的條件與狀況。正向列表的好處是簡潔，壞處是大家比較不容易想像是否有遺漏事項，因為正向列表大多少以用戶角度描述該如何操作此功能，自然也讓工程師們較少想到用戶，較多停留在技術層面上進行溝通。舉例來說，若依照剛剛的測試例子，我明確地說明處用戶在哪個互動狀態下，app需要給什麼回饋。若變為正面描述法，規則大致會是：
登入中的用戶（如果pm記得給條件的話）需可以點擊「查詢密碼」來查詢他的密碼。
兩者的差異因為這個舉例簡單而看似差異不大，但是細心的讀者應該會發現：test-driven 寫法多了人與機器的動作，讀者較可以在腦海中勾勒出畫面，想像情境。而正面列表需求的描述較為嚴肅，也相對「靜態」，開發需要更多「腦補」他應該怎麼撰寫程式邏輯。
我寫了無數軟體的產品規格書，使用了許多描述方式。我的經驗是：越複雜的功能越需要生動親切的case 描述（test-driven design) 。反而是簡單的功能才比較適合使用正面（或反面）列表。
越複雜的功能越需要生動親切的case 描述
尋求共識
我習慣在寫好規格書初稿的時候，就找開發主管或是幾位工程師、設計師來聊聊規格。口頭與他們說明這份需求細節的來龍去脈，並點出幾個重要的條件，最後請他們針對需求本身提出問題或建議。
大致沒問題後，我會進一步（或是另訂一個會議）請他們有空詳閱該規格書，為的是詳細討論各種情境。在聽取大家意見後，我接著會調整規格，反映我們討論後所做的產品決定。
滿多時候我在聽完工程師的各種詢問後，察覺到「這需求可以丟垃圾桶了！」或是「我們需要換個解決方案」。這對資深product 人來說不容易，因為你必須為了公司的產品放下個人執著—我花費這麼多時間，應該至少要試試看的心態—這對新手PM也不容易，因為承認思考不周不是一位正常人的正常行為，不過卻是為大局著想的人的必要態度。
小結
規格書不好寫，但是有它存在的必要性，特別在這個遠端工作開始要成為常態的時代中。規格書寫不好的時候，真的很難線上合作。
看看這篇文章、思考你的寫作架構、寫寫看、不要害怕質疑、請教你的潛在讀者哪裡可以寫得更好，進而不斷改進。
其實撰寫產品需求並沒有你想的困難。
Product Design 
發表迴響