Windows 機密：淘汰橡皮圖章
智慧型產品開發的重要一面是領悟到程序中有個步驟可能是多餘的。
Raymond Chen
作為一種產品獲取更接近于海運，無論是像消費者預覽或生產 (RTM) 的最終發行版本的預發佈版本，每次更改都經過更嚴格的審查，確保剩餘的有限工程工作重點是重要的問題。 此項審查工作也為了驗證是否每個批准的更改不會有意想不到的後果，使治療比疾病更糟。
軟體產品開發不只是非線性，它是不連續。 一個部分代碼中的次要攝動可以放大到別的地方的一個大變化。 這反過來可以級聯到災難性故障。
在釋放過程的早期階段，審查來在地方一級。 功能業主看一遍每個變更要求，並決定哪些是要接受，哪些要推遲，哪些要拒絕。 例如，如果問題只影響少數人的或者很容易被發現的解決方法，它是更有可能推遲或拒絕。
假設建議的更改傳遞使用者的影響和相關性的障礙，要實現更改的代碼是編寫和測試。 然後功能團隊將審查建議的更改和接受或拒絕它基於各種條件，如與此更改關聯的風險的程度。 這不是一個離散的過程。 評價發生不斷，但這兩個階段 （初步驗收和最後審查） 通常爭議最大。
隨著截止日期的臨近，常有審查在團隊級別添加一個附加層。 然後必須向整體團隊經理提交符合功能業主批准的每個更改。 團隊管理者可以選擇拒絕功能業主所接受的更改。
它通常是在這個級別的人開始問一個尷尬的問題。 多長時間這個 bug 一直有？ 這同樣的 bug 存在任意位置還有嗎？ 這個 bug 是如何介紹的? 誰簽字的更改，介紹了該 bug？ 為什麼在沒有測試更快找到此 bug？
這些問題是不是意味著難堪的功能業主。 （這不是他們唯一目的，至少。)團隊管理者需要知道這些問題的答案，因為發貨前一版本的 Windows 中的 bug 的修復可能會引入一個相容性問題。 資歷深的 bug 往往變成了一個相容性約束。 目前在多個去了未被發現，直到最近的預覽版本中的 bug 甚至可能不值得修復的風險。
甚至更接近于航運、 點評進一步擴大了在鏈。 第一，他們被提前到組級別，然後最後到了整個 Windows 產品團隊。 在這些最後的階段，每個建議的更改對產品是帶到 Windows 船室。 在這裡你要代表變化，解釋為什麼你認為它應該接受到釋放。
Windows 8 跟隨這一進程，就像其父親和祖父。 然後一些有趣的事情發生了。
發運的 Windows 8 的預發佈版本之一後, Windows 船室的人經歷了他們的所有建議修復 Windows 船室批准該預發行週期期間帶來的記錄。 介紹了每個 bug、 提出了令人尷尬的問題、 風險均衡的利益，和它原來最終接受了每一個人。
人跑了 Windows 船房結束這意味著組級船房間被工作做得好的決定的 bug 修復和推遲或拒絕。 Windows 船房間的額外的安全檢查並不添加任何值，因為它從來沒有推翻了下級法院的決定。
由於這種事後分析，發佈管理團隊只是一段時間推遲 Windows 船房過程。 他們恪守組級船客房的各項決定。 Windows 船房並不無限期地解散了，但後認識到這不進程的重要組成部分，它關閉一段時間讓的每個人都得到幾個小時的生命後面。
.jpg)
Raymond Chen Web 網站、 舊的新事物和具有相同標題的書 (艾迪生-衛斯理 2007年) 處理 Windows 歷史和 Win32 程式設計。 不採取內部。