無痛功能規格 - 第二篇:規格是什麼?

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
編輯:Jeff Wang 王家麒
October 3, 2000

A part of Joel on Software, http://www.joelonsoftware.com


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

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

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

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

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

讀完了嗎?

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

(耐心地等待...)

picture-OldSanJuan:

噢,很好。你回來了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誰該寫規格?請看第三篇

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