第4部分(第3/4 頁)

相互溝通。

然而，變化已經開始了。各個部門正在調整位置、相互靠近，因為這樣做起事情來更快、更容易。各部門也正在組織功能小組，因為這樣做可以更快地得到更高的質量，並且留下較少的未完成的工作。順著這個趨勢，把它們不斷整合，那你可以把規範書永遠拋棄了。這不是夢想，而是簡單時代的迴歸，並且伴隨著經歷了多年艱苦奮戰才獲得的智慧。

。　最好的txt下載網

樹立靶子

2007年2月1日：“糟糕的規範書：該指責誰？

規範書基本上都是可怕的。不僅僅是指專案管理規範書，而且也包括開發規範書和測試規範書。我說的“可怕”，主要是指難以撰寫，難以使用，而且難以維護。你要知道，這很可怕！規範書往往還是不完善的，組織得很差，並且沒有得到充分的複審。規範書永遠都是這個樣子，也看不到有任何變好的跡象。

為此，我想要指責專案經理，部分原因是因為我喜歡這麼做，但更主要的還是因為他們是糟糕規範書的始作俑者。然而，事實不允許我指責專案經理。人人都在寫糟糕的規範書，而不只是專案經理。即使專案經理偶爾寫出了上好的規範書，但其他大部分的還是很糟糕的。不管誰來寫，上好的規範書總是難以撰寫和維護的。

如果專案經理不該為那些以次充好的規範書承擔罪責，那麼該指責誰呢？管理層將是最直接的目標（另一群我喜歡指責的人）。事實上也是，有些組織，比如Office部門，一貫以來寫的規範書都比其他部門的要好。因此，管理層顯然在其中發揮著作用。然而，Office部門這麼多年來調換過很多次管理層，因此，這裡的原因必定比主管的人更加深層次。

現在清楚了，我應該去指責規範書過程——我們是怎麼寫規範書的，以及我們使用什麼工具。這個過程是繁瑣、艱難並且乏味的。規範書模板冗長、嚇人，複雜到無法駕馭。所有這一切使得要寫成一份上好的規範書，比披著皮大衣、穿著拖鞋想要去贏得一場馬拉松比賽還要無望。

一些落後於時代的杞憂者可能會說：“規範書過程如此荒謬紊亂是有原因的。所有的模板元素和過程步驟都是用來避免以前發生過的災難的。”看到了吧，你不必去擔心從公司高層下來太多的官僚主義，其實，在下面的基層已經自己累積了很多。

病態的過程總是源自於最好的意圖。麻煩的是，這一路走來，最初的目標和意圖都不知不覺地迷失了。喚醒這個目標和意圖，使用新的、更好的方法去實現將會使它們自動現身。

作者注：我在波音公司工作了5年。在那裡，不是所有、但絕大部分官僚主義看起來都來自於公司高層。我已經在微軟工作了12年。在這裡，不是所有、但絕大部分官僚主義看起來都來自於基層。我們在最底下的層次，工作獨立，很自由。有時候這也意味著，我們被授予了足夠的繩子用於勒死我們自己。

溝通分解

所有專案管理、開發和測試規範書的目標，都是為了跟不同時間、不同地點的人進行設計和設計決定的溝通。我們想要使這種溝通變得容易而穩健，並且進行大量的反饋和質量檢查。

假設你還沒注意到，這裡有4個獨立的要求：

？ 容易

？ 穩健

？ 反饋

？ 質量檢查

每個要求都可以透過一個不同的解決方案來滿足。“我們只需在規範書中多加幾節來覆蓋所有的要求”，這種方法跟“我們只需給這個類多加幾個函式來實現所有的功能要求”一樣的愚蠢。我們還是對這些要求逐個來分析吧。

txt小說上傳分享

保持簡單容易

規範書必須要容易寫，容易懂，並且容易維護。它應該使用標準的符號（比如UML）來繪製圖表，使用通用的術語用於文字表達。它不應該承載太多的內容或者說得過於深入。

格式越簡單越好。在“工程卓越手冊”（Engineering　Excellence　Handbook）中的通用規範書模板有30節之多，並且還有3個附錄。而上好的Office規範書模板也有20節。它們都太複雜了！

一份規範書只需要3節，再加上一些後設資料：

？ 需求：為什麼會有這個功能？（跟應用範例和客戶角色聯絡起來。）

？ 設計：它怎麼工作？（圖片、動畫和圖表特別有用。）

？ 問題：做了什