無痛功能規格 - 第二篇：規格是什麼？ Painless Functional Specifications – Part 2: What’s a Spec?

(你看過第一篇嗎？如果還沒有可以到這裡看。)

這一系統的文章是在探討功能規格而非技術規格(譯註：也稱為工程規格)。人們常會把這兩者攪混。我不知道是否有其他標準術語，不過我個人的用法如下：

1. 功能規格純粹由使用者的角度來描述產品如何運作。它不管東西是怎麼做出來的。功能規格會述及功能，還會詳述畫面、功能表、對話框等等。
2. 技術規格則是描述程式內部的實作。它會說明資料結構、關連式資料庫模型、程式語言及工具的選用、演算法等等。

當你從頭設計一個產品時，最重要的一點就是要確定使用者的體驗。要顯示什麼樣的畫面，運作的邏輯為何，要達成什麼功能。再來還要考慮如何達成。如果產品本身要做什麼都還沒決定，爭論要用哪種程式語言是完全沒有意義的。我在這個系列中只會討論功能規格。

我寫了一篇簡短的規格範例，應該能讓你大致瞭解一份良好功能規格的重點。在我們繼續之前請先讀這份規格範例。

讀完了嗎？

一定還沒有。現在就去讀完再回來，這樣我們才能討論一份良好規格所應具備或不應包含的東西。我會在這裡等你。謝謝。

(耐心地等待...)

噢，很好。你回來了。

下面列出一些我在每份規格上都會放的項目。

一段聲明。純粹自衛用。如果你寫一段文字說「這份規格還沒完成」，別人就不會衝進你辦公室把你的頭咬掉。等時間流逝規格開始完整時，你可以改寫成「就我所知這份規格已經夠完整了，不過有什麼漏掉了，請告訴我」這提醒我每份規格都需要：

一位作者。有些公司認為規格應該要由整組人來寫的。如果你嘗試過團體寫作，就知道那是最可怕的酷刑。團體寫作就留給擁有大批新出廠哈佛畢業生的管理顧問公司吧，他們需要做大量的虛工才能收取鉅額費用。你的規格應該由一個人負責並撰寫。產品規模很大時就切成幾區，讓不同人寫各區的規格。其他公司認為把個人名字放在規格上會讓他「獨佔功勞」，會太過自我本位，不是良好的「團隊合作」模式。胡說。人們對被指派的工作應該要同時有責任和所有權。如果規格有問題，在規格上印上大名的規格負責人應該要負責解決。

腳本。當你在設計產品時，一定要想出某些真實存正的狀況以及人們使用的方法。否則最後就會設計出一個完全沒有真實用途的產品(就像Cue?Cat)。替你的產品選好客戶群，針對每種客戶想像一個完全虛構而又完全典型的使用者，用很典型的方式使用產品。我的UI設計書(可以在線上免費取得)中的第9章討論虛構使用者和情境的建立。這些使用者或情境就是用在這裡的。狀況定得愈清楚愈真實，針對真實或虛構使用者的設計就愈好。這也正是我會放入這麼多虛構細節的緣故。

非目標。當你和整組人一起建立產品時，通常每個人都會各有所好，因而產生各式各樣真正或虛構的必備心愛功能，如果要將這些功能全部都做出來，恐怕永遠做不完而且要花很多很多的錢。所以你必須馬上開始刪功能，而刪功能的最佳方法就是利用規格的「非目標」章節，列出我們不打算做的東西。非目標可能是個不會具備的功能(「沒有精神感應式介面！」)，也可能是較一般性的定義(「我們不在意這個版本的效能。這個產品跑得多慢都沒關係。如果第二版時間夠，我們會把效率最佳化。」)這些非目標很容易引起爭議，不過儘早把它們曝露出來卻是非常重要的。就像老喬治布希說的：「絕對不會做！」

概要。這就像是規格書的目錄。它可以是張簡單的流程圖，也可以是段廣泛的架構討論。大家會先讀這部份知道大致輪廓，再來看細節才有意義。

細節、細節、細節。最後會進到細節。除非必須了解特定的細節，否則大多數人都會略過這一部份。當你在設計一個網路服務時，有個好方法就是把所有可能的畫面都取個正式的名稱，再對每個畫面用一整章鉅細糜遺地詳述細節。

細節是功能規格中最重要的部份。由範例規格中，你可以注意到我對登入頁面各種錯誤狀況有極為詳細的說明。當郵件地址錯誤時要怎麼做？密碼錯誤時要怎麼做？這所有的錯誤狀況，都會對應到將要撰寫的真實程式碼，不過更重要的是這些狀況都會對應到某人必須做的決策。某個人必須決定遺忘密碼時的處理方式。由於不決定就無法寫程式，所以規格就必須把決定寫下來。

未定義項目。第一版的規格有未定義項目是正常的。我在寫初版草稿時總是有很多未定義項目，不過我都會標示出來(加上特殊格式便於尋找)，如果可以的話還會討論各種可選用的方案。等程式人員開始作業時，所有未定義項目都必須處理乾淨。(你可能認為，先讓程式員從簡單的項目做起，你稍後再把未定義項目定清楚。這是個壞主意。光是處理程式人員實作程式時出現的新問題就夠了，根本不會記得還有些舊問題有待處理。另外解決重大項目時所用的方法也可能會嚴重影響到程式的寫法。)

旁註。在寫規格時要記住你會有各種不同的讀者：程式員、測試人員、行銷人員、技術作者等等。當你在撰寫時可能會想到一些只對某類讀者有用的小資料。舉例來說，我會把寫給程式員看的訊息(通常描述某些技術實作細節)標成「技術註解」。行銷人員直接跳過而程式人員就會細讀。通常我的規格裡滿滿都是「測試註解」，「行銷註解」和「文件編寫註解」

規格必須是活的。某些程式團隊會有一種「瀑布」心態：我們會一次就把整個程式設計好，所以把規格寫好印出來丟給程式員就可以收工回家了。對這種想法我只能說：「哈哈哈哈哈哈哈哈！」

這種作法正是規格如此不受歡迎的原因。很多人都對我說：「規格根本沒用，因為沒有人會照著做。規格總是過時而且從來無法反映產品。」

原諒我。你的規格可能總是過時又不能反映產品。不過我的規格可是時常更新的。只要產品還在開發而又出現新的決策，就會持續進行更新。規格總會反映我們對產品運作的最佳認知。只要在程式完成時(也就是所有功能完備但尚未測試除錯)規格才會凍結不變。

為了讓大家好過一點，我不會每天重新發行規格。通常我會在伺服器上放一份最新版供大家參考。遇到特別的里程碑時，我會印一份出來，裡面加上修訂標記讓大家不必重讀整份文件(他們可以快速地發現修訂標記以便找出變更所在)。

誰該寫規格？請看第三篇！。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.