回到他自己的座位，想著他終於搞清楚了接下去該做什麼。那個專案經理也回到了他的辦公室，想著開發人員寫出來的程式碼肯定能夠反映他真正想要的東西。也許他們在想同一件事情，也許不是。也許測試和實施人員會同意他們的解決方案，也許不會。也許他們方方面面都考慮到了，也許他們不曾做到。也許這是最好的方式去處理變更，也許猴子會衝出我的……好吧，至少你知道了有這種方法。

。　想看書來

委員會議

第二種方法是委員會議。對於這種會議，不同的團隊有不同的稱呼，但它主要是用於討論規範書變更的主管級會議。通常這種會議會定期召開，各個主管形成一個組織，他們聚在一起討論規範書上的漏洞或者問題，並且以組織的名義尋找解決方案。主管的專案經理記錄會議結果，並且發郵件告知整個團隊。

這種方法的優點是：委員會議把該包含的人都包含了進來，達成了最終決議，記錄在檔，並且拿這些最終決議跟團隊溝通。缺點是：委員會議也是可怕的噩夢。它們通常比較冗長、令人厭煩、使人筋疲力盡。它們佔用了關鍵資源的巨大週期，阻礙了工作進展，成為了最要命的一種瓶頸——自我傷害和自我永續不斷。

電子書　分享網站

規範書變更請求

我最喜歡的方法是“規範書變更請求”（SCR，Spec　Change　Request），它還有一個扭曲的名字叫“設計變更請求”（DCR，Design　Change　Request）。這種方法是委員會議和走廊會議的組合，同時帶有一些關鍵的改進。假設你現在想去改變規範書或者給規範書增加新的內容，你的這個想法可能是你自己想出來的，也可能源於一次走廊對話，也可能受到了一次主管會議的啟發。

不管你是專案經理、開發、測試或實施人員，你都可以把你的想法寫到e…mail中去，並且e…mail的標題定為“SCR： …　”。在e…mail結尾的地方，你用粗體字寫下這麼一句話，“除非有人強烈反對，否則這就是最新採納的規範書。”然後，你把這封e…mail發給最直接受這個變更影響的專案經理、開發、測試和實施人員。幾天之後，當你根據他們的建議做完了必要的修改，你就可以把你的SCR發給團隊中剩下的所有人，並且把它放到RAID中或者一個公共目錄中，跟其他SCR一起跟蹤。

譯者注：關於RAID，參見本書最後的“術語表”。

這裡的關鍵是，規範書的變更現在文件化了，並且得到了相關人員的複審，而且不會阻礙工作的進展。反對幾乎總是例外，不會有很多。開發人員在任何時候都可以繼續工作，這裡只是一個權衡問題——動手做之前花更多的時間等待是否有反對，或者冒著後來被反對的風險馬上就動手做。典型情況下，開發人員會一直等待，直到SCR經過了初始的幾次修改後發給團隊全體成員的時候才動手做。

預防是最好的治療

當然，最理想的是規範書從一開始就不會遲到，至少你不能被它矇蔽。這裡就用得著T…I…M…E圖表了。在T…I…M…E圖表中，第一份規範書展示了對整個專案的設計。它不是簡單的需求文件，也不是數個小型規範書的集合，而是專案的一個高階規範書，很像是開發主管寫的那種高階架構文件。這個規範書應該展示專案將具有的功能和使用者介面，以及它們怎樣在一起協作，而把細節留給以後的規範書。所有後來的規範書和功能都必須參考這個高階規範書。

這樣的話，開發、測試和實施人員就可以制定計劃去說明未來所有的功能了。他們能夠生產出整合得更好的產品，使使用者體驗更加流暢。專案經理也可以使用第一份規範書去安排剩下的其他規範書，先做優先順序高的，而不必擔心遺漏什麼東西或者做出讓別人吃驚的事情來。這種理想終究使T…I…M…E產生了（難以抗拒）。

作者注：T…I…M…E（Totally　Inclusive　Mutually　Exclusive）圖表是由Donald　Wood首先提出的，但它從未像我的同事Rick　Andrews最初預期的那樣流行過。然而，微軟現在的價值主張、遠景文件、跨產品案例和仔細設計的原型都能達到同樣的目的。

電子書　分享網站

寶寶做了件極壞的事情（1）

2002年6月1日：“閒置人手”

你的開發團隊兩週前達到了“零Bug反彈”（