製作遊戲的兩三事【48】時程估算的誤區

忘記是那位遊戲同業曾經說過,開發遊戲很少有不Delay的,唯一的差別就是Delay時間的長短而已。事實上,在銀狐個人這二十年的遊戲研發經驗中,實際參與的遊戲研發專案,幾乎是每個專案都有發生過Delay的現象。輕微一點的Delay個數週;嚴重一點的Delay好幾個月。而對於遊戲公司的老闆或是專案負責人來說,沒有人希望發生這樣的現象的。

「遊戲研發會出現延期的狀況,很多時候其實是預估時程就出了問題。」

碼錶

專案時程會出現延誤的原因很多,從單純的開發人員的異動、離職到各種天災人禍,像是硬碟掛掉造成程式碼損毀或是打雷打壞電腦等等離奇的理由都有。不過讓我們先把這些千奇百怪的原因放到一邊,專心來看看因為人員評估時程所造成的狀況。因為大多數的遊戲研發,在進行時研發人員都會針對要開發的項目進行所需時間的評估。而這個時間評估上的正確率,通常也會影響到遊戲研發時程的正確性。

遊戲研發時程估算的錯誤,就銀狐個人的遊戲研發經驗中遇到過多種不同的狀況。以下,就讓銀狐列出幾個最常造成遊戲研發時程估算失準的狀況:

過份樂觀沒有考慮意外狀況的預估

有句俗話說『天有不測風雲,人有旦夕禍福』,指的是有些災禍的發生是無法預測的。同樣的,在工作時程的預估上,我們也必須要考慮到這些意外事件的發生。如果在預估時間的時候沒有考慮到這些,只以最樂觀的狀況來判斷,那麼在執行的過程中只要出現一點意外,就會造成時程的延誤。

舉個簡單的例子來說好了。銀狐之前有很長的一段時間負責一款線上遊戲的營運工作,當一款線上遊戲營運的時間久了,就會面臨到伺服器使用較長時間,有硬體需要進行更換的工程。這一類的工程各間遊戲公司都經常面對,因此都有相關的SOP可以參考。不過每一款遊戲的硬體配置不同,SOP上通常只會列出需要進行這項工程的流程,每項工作需要花費的時間會由各款遊戲自己計算。

有一次,專案又遇到了有硬碟需要進行更換的狀況,工程人員依據以往的經驗,估算了整個更換硬碟所需要的工程時間,然後將這個時間向玩家公告為維護時間。工程人員所估計的時間,是整個流程完全沒有出現任何意外所需要的時間。

結果,實際在進行硬碟更換工程的時候,先是在事前的資料檔備份壓縮的時候下錯了指令導致需要重新進行一次,接下來在更換硬碟的時候發現其中有一條排線太過老舊需要更換,結果花了更多的時間。由於原本預估的時間並沒有考慮到這些狀況,因此最後停機的時間不足,需要公告延長停機時間,而這自然也引發玩家的抱怨。

預估的時間沒有包含除錯測試以及調整的所需時間

遊戲研發的過程中,每一個項目通常都會需要經過一段除錯、測試以及調整的過程。而且這個除錯、測試以及調整的過程,有時候花的時間會比原本製作這個項目的時間還要長。當任何的遊戲內容從紙上的設計變成實物,操作後通常都會有需要調整的地方,如果在預估時間的時候沒有把這個部份考慮進去,那麼估算出來的時程一定會有很大的誤差。

舉個例子好了。在前面銀狐提到的那個專案中,有一次營運單位提出了某項需求,銀狐經過和程式討論之後認為這個項目需要佔掉一位程式將近一週的工時,因此告知營運單位就目前的人力狀況來說撥不出人力做這個項目。

當然營運單位沒有辦法接受這樣的說法,於是私下去找了位熟識的程式詢問,那位程式很豪爽的說「這樣簡單的功能他只需要一個下午的時間就可以完成。」當然,有著這位程式的背書,營運單位就理直氣壯的來和銀狐理論,說銀狐故意找理由不願意支援他們。在這樣的狀況下,銀狐只好放手讓這位程式去做這個項目。

結果,這位程式花了大約一天的時間才把這項功能做出來(和他原本所說的一個下午已經有了點差距),然後寫出來的功能有Bug又修了兩天,然後因為實際運作起來的狀況和營運預期的又有些不同,因此又花了兩三天的時間去調整。最後整整花了七個工作天的時間,才把這個項目做到營運需求的樣子。這個半天變成七天的工時預估,就是這位程式忽視了除錯、測試以及調整所需要花費的時間。

會不斷的有雜事打斷你正在進行的工作

記得曾經有國外的文章提到過,許多的程式設計師喜歡在夜晚工作,因為這個時段他們的產能最高。其實,仔細去分析這個狀況就會發現,並不是程式設計師的生理時鐘有什麼問題,造成他們會在夜晚的時間工作效率比較而。而是平常上班的時間,他們的工作可能會不斷的被各種事情打斷,只有在夜晚沒有人幹擾的時候才能夠專心工作,因此產能比較高。

其實同樣的狀況在研發遊戲的時候也一樣會發生。當一款遊戲在研發的時候,任何一位專案的成員身上通常都不會只有一件工作,而這些工作可能分別和不同的同仁有關,因此當你在進行一項工作的時候,很有可能會被另外一項工作出現的狀況所打斷。如果是營運中的遊戲,研發成員同時負責維護舊有的內容以及開發新的內容,那麼這個狀況就更為嚴重。

遊戲研發有很大一部份是腦力的勞動,而思考到一半的事情若是被打斷,在打斷之後要重新回到原本的狀態,通常會需要一點時間。這就好像是汽車加速到100公里後踩了急煞車,之後要重新加速回到100公里通常也需要花一點時間是一樣的。而這個重新加速的時間,就會成為時程預估中無法估計到的時間。每多一次打斷,這個時間就會不斷的增加。

每日工時估算的錯誤

當一個開發項目出現後,研發人員就會依據這個項目的難易度來預估開發需要的時間。依據工作項目的大小,可能會以天數或是小時數來估算這個項目完成所需要的時間。一般來說,大多數的遊戲公司每日的上班時間是八小時(雖然實際的工作時間遠超過八小時),因此有些開發人員會先以小時數估算所需的時間,然後除以八求出所需要的天數。不過,雖然公司規定的每日工時是八小時,實際上每個人一天『真正』在工作的時間是否真的有八個小時呢?

早上到公司吃個早餐、看看新聞,上班的時候上一下臉書、PTT,中午午餐時間以前和同事討論一下午餐要吃什麼,中午午休時間多睡個十幾分鐘。如果再加上抽個煙、上廁所時順便到其他同事那裡串個門子、或是去茶水間倒水的時候和同事聊聊天,一天真正剩下來可以工作的時間還剩下多少?就銀狐自己的習慣,每日的工時如果能有六個小時,那麼這位同仁已經算是相當努力工作的,有些誇張一點的人一天真正的工時可能連四小時都不到呢。

在實際每日工時相差如此龐大的狀況下,原本估算出來的時程根本無法完成。雖然說大多數的遊戲公司加班的狀況常見。不過,也有許多的人就算是留在公司加班但是心根本不在工作上。當你的周圍有許多下班後留在公司玩遊戲的同事時,就算是再怎麼有定力的人,恐怕都很難真正的把心思放在工作上吧。在估算工時的這件事情上,銀狐個人習慣用每日工時四至六的這個區段來計算實際所需天數。

—–[我是分隔線]—–

以上所說的幾種狀況,都是研發遊戲的專案人員在估算時間的時候容易踏入的誤區。在發生這些狀況的時候,對於預估的時間都會出現程度不一的誤差。當然,這些時間上的誤差都比不上某些老闆/上司喜歡用的『菜市場殺價式』的喊價狀況,那種隨隨便便就把專案時間砍掉1/2或是1/3的狀況,其最終的結果都會悲劇收場。

而某些老闆/上司習慣用壓縮後的時程來逼迫員工加班趕工,他們的想法可能是『反正一年的專案會做一年半才完成,那我不如一開始就把專案時間喊成六個月,這樣就算做了一年才完成也比做到一年半要好』這樣的想法。這種作法也許一次兩次會有效,但是人不是機械,是會彈性疲乏的,當專案的成員陷入這樣的狀態後,是很難再將大家的士氣拉起來的,到了那個時候可就神仙也難救了。

如果你要問銀狐有沒有避免遊戲研發Delay的方法?銀狐會告訴你「我沒有」。我所能做的,就是在專案預估開發時間的時候,避免專案的成員踏入以上的誤區。但是,就算是避開了這些誤區,還是有許多會造成專案研發Delay的因素,剩下的就只能『兵來將擋,水來土掩』的見招拆招了。

  • Ayukawayen

    避免遊戲研發Delay的方法: 不要訂時間表就不會Delay了 XD

    • 很好的建議,但是一點都不實用。

      當老闆要你開時間表的時候,你敢向老闆說「為了避免Delay,所以我們不要開時間表。」?
      是嫌自己死得不夠快嗎? (笑)

  • yehnan

    schedule就是用來delay的。
    不知道銀狐先生有沒有看過《在公牛身上擠奶》(後改名為 軟體超人X光眼)或相關的軟體開發的書籍著作。

    • 看過很多。我之前曾經想要買幾本『人月神話』送給我之前的幾位老闆 XDDD