線上遊戲開發記事【12】新制度造成的進度大混亂

在這一系列『線上遊戲開發記事』的文章中銀狐應該提到過,這個專案因為上市的時間很趕,所以專案的進度不太理想。在這樣的狀況下,專案一直呈現著內容不足的狀況。

在專案開始營運後,面臨著遊戲開始收費後在線人數下滑的狀況,為了要盡快的補充遊戲的內容,專案的開發狀況也變得很吃緊,每一項開發的項目幾乎是完成後立刻就更新到遊戲中。在這樣的狀況下,也造成開放的內容不斷出現大大小小Bug的狀況。

面對這樣的狀況,以及當時公司幾個專案經常在更新後出現問題的現象,公司高層決定推動『全新』的測試品保流程,想要解決這個問題。不過這個新的測試品保流程,很快的就對專案的開發造成相當大的影響。

原本專案在開發的時候,內部就建有一個『開發伺服器(我們稱為內站)』,所有專案成員(企劃或是程式),都是在這個開發用伺服器上進行開發。完成的項目,測試後會在每週維護時間放到『正式伺服器(我們稱為外站)』上。這樣的流程很容易因為一時不慎,會發生漏放或是放了不該放的檔案到外站,因此在每週的維護時間後,偶而會發生需要立刻再緊急停機解決問題的狀況。

新的流程,在原本內站和外站之間增加一個『測試伺服器(我們稱之為測試站)』,這個測試站的狀態和外站是完全相同的,然後每週再將要開放的內容放上去測試。只有在測試站測試通過的項目,才能在當週的維修時間放到外站上。如果放到測試站上的項目有漏或是不正確,那麼在測試站上就無法完成測試,藉由這個和外站相同的測試站,來測試每週更新內容是否能正確運作。

這個新的流程,解決了之前各專案在維護日更新經常發生的問題,不過相對的,它也因為增加了整個流程的手續,導致開發進度的延誤。

就以銀狐參與的這個專案來說,每週的定期維護日是星期三中午。專案還處於每週都有更新的狀況時,問題就開始浮現了。

首先,每週三要等到外站開站後確定沒有問題,才能將外站複製到測試站;其次,在這之後才能將下一週要更新的內容放到測試站上開始進行測試。這些下週三的開放項目必須在下週一完成測試,這樣週二才可以做最後的確認;如果到下週一還不能通過測試,那麼週一就要將它從當週更新中抽掉。

以軟體版本的角度來說,這樣的作法每週更新後就是一個新的版本,而能夠送到測試站進行測試的,只有下一個版本的更新內容。問題是有一些比較大的機制,或是需要比較長測試時間的項目,例如下下週才要開放的項目,在下週的項目未完成前就會被卡住。而若是兩週更新都有用到某個程式,一不小心也會發生覆蓋的狀況。

特別是專案在需要不斷補充遊戲內容的時候,有一些較重要的機制準備開放,這些機制都不是能夠在短短的週三下午到週一下班前完成測試的。遇到這樣的狀況,最好的辦法是暫時凍結遊戲版本一兩週(一兩週停止更新),然後在這些重要的項目完成測試後再一起開放,安全又不容易出錯。

只不過當時專案狀況並不容許這麼做,專案的製作人也沒有決定這樣。在公司高層堅持各專案一定要使用這個新版的測試品保流程後,因為進行這個新的制度需要耗費較多的人力,導致專案的進度陷入混亂。

當然銀狐並不是說這個新的制度有什麼不好的,也不是說不應該這麼做。因為從這個制度開始實施之後,定期維護日出問題的次數的確減少了,而這個新的測試品保流程,對於專案的穩定性也提供了某些保障。因此後來銀狐接任製作人後,也盡量的讓專案繼續的照這個制度來運作,對於因為版本切割所造成的影響,改由重新安排項目更新日期來因應。

就這樣到銀狐離開這個職位為止,本專案一直都有遵守這個制度在運作,反而是公司後來的幾個專案,專案的負責人用各式各樣的理由不用這個制度。而當初推動這個制度的某位長官,自己帶領的專案反而找理由不用這個制度,當然那些不採用這個制度的專案,也都紛紛發生過許多次的意外事件。

銀狐認為,任何一個制度的推動都是需要所有人的配合。如果制度在運作的時候有問題,那麼應該是調整制度或是找出辦法來解決,而不應該有的專案要遵守制度、有的專案可以找理由不用遵守制度。
雖然說制度不是絕對的,不過公司的制度若是可以憑自己的高興決定用不用,那麼訂定這些制度、流程又有什麼意義。

「所謂的規定啊,是為了打破它而存在的。」青島俊介(大搜查線)

雖然日劇裡有這樣的台詞,不過工作上不應該是這樣的吧 …. (苦笑ing)