適應於任何型別功能規格說明書撰寫的三大規則

今天為大家更新《使用者體驗要素》的第四章——範圍層——功能規格說明

本小結關鍵詞：功能規格說明

主要觀點：適應於任何型別功能規格說明書撰寫的三大規則

前兩節我們講了如何去定義需求，並使用文件定義產品需求的原因，其實就是我們所說的產品功能規格說明書，今天我們就來好好聊聊的這個文件。

功能規格說明

功能規格說明在某些方面的名聲不太好。程式員們痛恨功能規格說明，因為它們非常枯燥，並且會佔用大量編碼的時間去閱讀它們。結果，那些“沒有人讀的功能規格說明”反過來又強化了“撰寫它們是一件浪費時間的工作”的印象——事實上也正是如此！一個應用不當的功能規格說明就這樣變成了自我應驗的預言。

對功能規格說明的抱怨之一是它們沒有反映實際的產品。“在實施過程中事情會產生變化”，每個人都理解這個——這是技術型工作的正常情況。有時候你考慮好的一些事情會行不通，或不大可能以你想象的那種方式來運作。無論如何，這並不是一個把撰寫功能規格說明書當成一件失敗的工作而放棄的理由。相反，它強調了一個真正起到了作用的功能規格說明書的重要性。當事情在實施過程中改變的時候，你不應該舉起你的雙手宣稱撰寫功能規格說明書是沒有價值的，而是應該讓撰寫的過程變得快速簡便，不要把它變成產品開發過程中一個獨立的專案。

換句話說，文件不能解決問題，但定義可以。我們需要的不是文件有多厚或有多詳細，而是要足夠清楚和準確。功能規格說明不需要包含產品的每一個細節——只需要包含在設計或開發過程中出現有可能混淆的功能定義。同時功能規格說明也不需要展望產品未來的理想化狀態——只需要記錄在建立這個產品時已經確定下來的決議。

記下來

無論這個專案有多麼龐大或多麼複雜，有幾條規則適用於撰寫任何型別的功能規格說明。

樂觀

描述這個系統將要做什麼事情去“防止”不好的情況發生，而不是描述這個系統“不應該”做什麼不好的事情。比如，下面這句描述就不太好：

這個系統不允許使用者購買沒有風等線的風箏。替換成下面這句會更好：如果使用者想買一個沒有線的風箏的話，這個系統應該引導使用者到風箏線頁面。

具體

儘可能詳細地解釋清楚狀況，這是我們能決定一個功能是否被實現的最佳途徑。

對比下面的例子:

1.最受歡迎的視訊要重點標註。

2.上一週被播放最多的視訊要顯示在列表的最前端。

第一句話看上去像是定義了一條明確的需求但是不需要花費太大精力就能看出它有很多漏洞。什麼叫做“最受歡迎”?如果這個視訊的評論最多，是否就“最受歡迎”了呢?那麼被投票最多的那個視訊也算嗎?另外如何“重點標註它們?

第二句話用具體的細節定義清楚了我們的目標，定義了我們認為什麼算“最受歡迎”，並且描述了關於“重點標註”的機制。

避免主觀的語氣

這是另外一種使需求“保持明確”和“避免歧義”的途徑一一因而也避免了誤解的可能性。

這裡有一個非常主觀的功能規格說明:

這個網站的風格應該是時尚、閃耀的。

功能規格必須可驗證——就是說，它必須要能證明“這個需求沒有被滿足”。你如何去驗證這種被宣稱為“時尚”和“閃耀”的產品品質?我對於時尚的定義也許並不符合你的，而CEO更可能對此有完全不同的看法。

這並不是說你不能要求你的網站時尚。只是必須找到某種方式來明確說出應該達到的標準:

這個網站應該符合郵遞員Wayne所期望的時尚。

Wayne通常不會對這個專案說些什麼，但是我們的專案發起人很顯然會尊重他對於時尚的看法。而且這有可能和我們的使用者的期望值是一樣的。但是這樣的一個需求仍然是很主觀的，因為我們依賴的是Wayne的認同，而不是可以更客觀界定的一系列的標準。所以，這個功能規格說明最好能像這樣:

網站的外觀應該符合企業的品牌指南文件。

時尚的概念已經完全從這個需求中消失了。相反地，我們得到了一個清晰、毫不含糊的、已有的參考指南。為了確保品牌指南有足夠的時尚性，負責市場的副總裁可能需要去了解郵遞員Wayne，或者去和她十幾歲的女兒交流，甚至她還可能做一些使用者調研的工作。這取決於她。但是現在我們可以明確地說出“這個需求是否被滿足了”。

我們也可以量化地定義一些功能，通過這樣的手段來避免主觀性。正如成功的標準能使戰略目標得以量化一樣，用量化的標準來定義功能也能有助於知道我們是否滿足了需求。比如，要求系統具有“高級別的執行能力”，我們可以用“要求這個系統的設計至少要支援1000個使用者同時使用”來代替。如果最終產品只能支援千位數的使用者，我們就知道這條需求沒有被滿足。

總結來說，就是我們不僅要寫功能規格說明書，而且還要細化，量化的去定義每一個功能點，同時遵循文中作者說的幾點。

接下來，會更新如何確定需求的優先順序，敬請期待。