Posted by 在這一系列『線上遊戲開發記事』的文章中銀狐應該提到過，這個專案因為上市的時間很趕，所以專案的進度不太理想。在這樣的狀況下，專案一直呈現著內容不足的狀況。
在專案開始營運後，面臨著遊戲開始收費後在線人數下滑的狀況，為了要盡快的補充遊戲的內容，專案的開發狀況也變得很吃緊，每一項開發的項目幾乎是完成後立刻就更新到遊戲中。在這樣的狀況下，也造成開放的內容不斷出現大大小小Bug的狀況。
面對這樣的狀況，以及當時公司幾個專案經常在更新後出現問題的現象，公司高層決定推動『全新』的測試品保流程，想要解決這個問題。不過這個新的測試品保流程，很快的就對專案的開發造成相當大的影響。
原本專案在開發的時候，內部就建有一個『開發伺服器(我們稱為內站)』，所有專案成員(企劃或是程式)，都是在這個開發用伺服器上進行開發。完成的項目，測試後會在每週維護時間放到『正式伺服器(我們稱為外站)』上。這樣的流程很容易因為一時不慎，會發生漏放或是放了不該放的檔案到外站，因此在每週的維護時間後，偶而會發生需要立刻再緊急停機解決問題的狀況。
新的流程，在原本內站和外站之間增加一個『測試伺服器(我們稱之為測試站)』，這個測試站的狀態和外站是完全相同的，然後每週再將要開放的內容放上去測試。只有在測試站測試通過的項目，才能在當週的維修時間放到外站上。如果放到測試站上的項目有漏或是不正確，那麼在測試站上就無法完成測試，藉由這個和外站相同的測試站，來測試每週更新內容是否能正確運作。
這個新的流程，解決了之前各專案在維護日更新經常發生的問題，不過相對的，它也因為增加了整個流程的手續，導致開發進度的延誤。
就以銀狐參與的這個專案來說，每週的定期維護日是星期三中午。專案還處於每週都有更新的狀況時，問題就開始浮現了。
首先，每週三要等到外站開站後確定沒有問題，才能將外站複製到測試站；其次，在這之後才能將下一週要更新的內容放到測試站上開始進行測試。這些下週三的開放項目必須在下週一完成測試，這樣週二才可以做最後的確認；如果到下週一還不能通過測試，那麼週一就要將它從當週更新中抽掉。
以軟體版本的角度來說，這樣的作法每週更新後就是一個新的版本，而能夠送到測試站進行測試的，只有下一個版本的更新內容。問題是有一些比較大的機制，或是需要比較長測試時間的項目，例如下下週才要開放的項目，在下週的項目未完成前就會被卡住。而若是兩週更新都有用到某個程式，一不小心也會發生覆蓋的狀況。
特別是專案在需要不斷補充遊戲內容的時候，有一些較重要的機制準備開放，這些機制都不是能夠在短短的週三下午到週一下班前完成測試的。遇到這樣的狀況，最好的辦法是暫時凍結遊戲版本一兩週(一兩週停止更新)，然後在這些重要的項目完成測試後再一起開放，安全又不容易出錯。
只不過當時專案狀況並不容許這麼做，專案的製作人也沒有決定這樣。在公司高層堅持各專案一定要使用這個新版的測試品保流程後，因為進行這個新的制度需要耗費較多的人力，導致專案的進度陷入混亂。
當然銀狐並不是說這個新的制度有什麼不好的，也不是說不應該這麼做。因為從這個制度開始實施之後，定期維護日出問題的次數的確減少了，而這個新的測試品保流程，對於專案的穩定性也提供了某些保障。因此後來銀狐接任製作人後，也盡量的讓專案繼續的照這個制度來運作，對於因為版本切割所造成的影響，改由重新安排項目更新日期來因應。
就這樣到銀狐離開這個職位為止，本專案一直都有遵守這個制度在運作，反而是公司後來的幾個專案，專案的負責人用各式各樣的理由不用這個制度。而當初推動這個制度的某位長官，自己帶領的專案反而找理由不用這個制度，當然那些不採用這個制度的專案，也都紛紛發生過許多次的意外事件。
銀狐認為，任何一個制度的推動都是需要所有人的配合。如果制度在運作的時候有問題，那麼應該是調整制度或是找出辦法來解決，而不應該有的專案要遵守制度、有的專案可以找理由不用遵守制度。
雖然說制度不是絕對的，不過公司的制度若是可以憑自己的高興決定用不用，那麼訂定這些制度、流程又有什麼意義。
「所謂的規定啊，是為了打破它而存在的。」青島俊介(大搜查線)
雖然日劇裡有這樣的台詞，不過工作上不應該是這樣的吧 …. (苦笑ing)
銀狐 Silver Fox。一個在遊戲業打滾30年的老頭，現在則是半退休狀態的說書人。有空喜歡玩玩遊戲，談談遊戲產業的事。喜歡出國旅遊，四處吃吃美食增加體重和膽固醇，當當兼職的遊戲顧問、做遊戲的評測，玩一玩自己有興趣的遊戲。