PM 痛點3: 我要怎麼寫好規格?

世界拉花季軍 Up to you coffee @Asakusa 淺草

(最近這些嚴肅的痛點,都無法讓我發揮幽默的實力。還請讀者見諒)

在我寫了九年產品規格的PM生涯中,對於撰寫產品規格的建議,只有幾句話:

規格永遠不會完美,產品經理要做的事,是讓整個團隊意識到,規格不是只是PM的範疇,而是是促進大家溝通的管道。大家共同協助PM記錄到位,可以減少很多重複溝通,翻閱程式的心力。

不過話說回來,PM要怎麼撰寫一份好懂又齊全的文件呢?

一套框架

PM該寫的文件,一般被稱為「需求書」或「規格書」,英文可稱為product specification 或product requirement document。兩者聽起來都很嚴肅,所以PM第一步該做的,也許是定義這份文件裡面會包含哪些元素。

許多PM的規格書去頭去尾,開頭直接附上幾張UI 或流程圖,接著奉上跟工程師討論的硬細節,最後也沒有附上任何來龍去脈。

頭,容我建議你寫好下三點:

  1. 我們為何要開發此功能?(這功能產生前的背景,產品目標,介紹一下吧?)
  2. 我們的用戶會怎麼使用這項功能?(用戶用起來的情境,好歹也跟我說一下吧?)
  3. 這些功能有什麼基本限制與條件?(最基本的限制,開發應該要知道吧?)

上面內容齊全後,你再開始透過文字描述新功能的各種使用情境與細節。這會讓整份文件更有說服力:有點類似兩位朋友拜託你幫忙看家,一個跟你說:「拜託你來幫我顧家,鑰匙在鞋盒、冰箱有牛奶你可以喝、十點的時候記得鎖門。」;另一位拜託你時則跟你說:「拜託你幫我看家,因為我跟先生需要南下照顧雙親三天,我們實在找不到其他人可以幫忙。看家內容如下…」

尾,請讓我建議你附上你的靈感來源(參考連結,出處的意思)

不要以為每個人都為記得這項需求的前因後果,記錄故事比你想像的重要得多。若你在思考第一點時無從下手,那也表示這個功能並不需要做(你自己都不確定了!)

我喜歡有些人把這份文件稱為product page 或product summary。

Test-driven Development

描述一個功能該如何與用戶互動的相關細節時,我傾向使用「測試導向開發」方法撰寫產品的規格細節。其實這是一個非常簡單的架構,也容易套用:

Given – When/ If – Then

意思是:給定(某條件),當(用戶或系統)…,(用戶或系統會)….

例:假設用戶登入的狀態下,當他點擊「查詢密碼」,他會被導引到(或app會導引他到)查詢密碼頁面。

正面列表需求

PM可以視情況以不同方式描述規格細節。另外一種寫法為正面列表一功能該有及不需要處理的條件與狀況。正向列表的好處是簡潔,壞處是大家比較不容易想像是否有遺漏事項,因為正向列表大多少以用戶角度描述該如何操作此功能,自然也讓工程師們較少想到用戶,較多停留在技術層面上進行溝通。舉例來說,若依照剛剛的測試例子,我明確地說明處用戶在哪個互動狀態下,app需要給什麼回饋。若變為正面描述法,規則大致會是:

登入中的用戶(如果pm記得給條件的話)需可以點擊「查詢密碼」來查詢他的密碼。

兩者的差異因為這個舉例簡單而看似差異不大,但是細心的讀者應該會發現:test-driven 寫法多了人與機器的動作,讀者較可以在腦海中勾勒出畫面,想像情境。而正面列表需求的描述較為嚴肅,也相對「靜態」,開發需要更多「腦補」他應該怎麼撰寫程式邏輯。

我寫了無數軟體的產品規格書,使用了許多描述方式。我的經驗是:越複雜的功能越需要生動親切的case 描述(test-driven design) 。反而是簡單的功能才比較適合使用正面(或反面)列表。

越複雜的功能越需要生動親切的case 描述

尋求共識

我習慣在寫好規格書初稿的時候,就找開發主管或是幾位工程師、設計師來聊聊規格。口頭與他們說明這份需求細節的來龍去脈,並點出幾個重要的條件,最後請他們針對需求本身提出問題或建議。

大致沒問題後,我會進一步(或是另訂一個會議)請他們有空詳閱該規格書,為的是詳細討論各種情境。在聽取大家意見後,我接著會調整規格,反映我們討論後所做的產品決定。

滿多時候我在聽完工程師的各種詢問後,察覺到「這需求可以丟垃圾桶了!」或是「我們需要換個解決方案」。這對資深product 人來說不容易,因為你必須為了公司的產品放下個人執著—我花費這麼多時間,應該至少要試試看的心態—這對新手PM也不容易,因為承認思考不周不是一位正常人的正常行為,不過卻是為大局著想的人的必要態度。

小結

規格書不好寫,但是有它存在的必要性,特別在這個遠端工作開始要成為常態的時代中。規格書寫不好的時候,真的很難線上合作。

看看這篇文章、思考你的寫作架構、寫寫看、不要害怕質疑、請教你的潛在讀者哪裡可以寫得更好,進而不斷改進。

其實撰寫產品需求並沒有你想的困難。

作者

Joyce Huang

I consider myself a writer because my passion and profession makes me what I am. I write product spec ever other day. I also write diaries and journals here and there on a daily basis.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s