游戲研發項目特點
項目整體復雜性強
游戲是一種特殊的軟件,尤其是大型網游,通常比一般的軟件開發規模大、人數多、周期長、復雜程度高。首先,正規的游戲開發會包括策劃、美術(含2D和3D)、編程和測試等多個團隊,如何使這些具備不同工作技能的團隊成員協同工作,如何使各個工作環節銜接順暢,是一個頗為復雜的問題;其次,網絡游戲項目的開發周期較長,雖說一般在1年半到2年之間;另外,游戲項目的成敗很大程度上依賴于市場對游戲的反響和接受意愿,頻繁的需求變更再次增添了游戲研發的復雜性。
需求管理難度大
游戲的需求管理貫穿整個開發過程,是影響游戲開發質量的關鍵。游戲項目最初的需求是從策劃部門提交的游戲創意、玩法、美術風格、大致背景、特色系統、與同類游戲區別等等一系列繁雜的內容中,通過各部門討論和評估而總結出來的。雖然通過需求分析會得到《游戲功能描述書》這一結果性文檔,但如果不進一步結構化分解,項目成員要進行任務分配和編程仍然很難。
除了最初的需求分析,需求變更管理也是一個難點。游戲項目計劃經常改動,往往也是由需求變更引起的。一方面,為了使游戲發布后更具有競爭力,需求變更不可避免,如果不對變更進行評估取舍,項目的整體目標可能很難達到;另一方面,為了彌補需求變更對項目進程帶來的影響,開發人員常??焖俚倪M行功能修改和增加,而沒有遵循統一的流程控制,從而使游戲整體的有序性被破壞,人為地增加了工作量,最后導致跳票。
項目規劃與執行要求高
項目規劃準確性。游戲作為大眾娛樂的商業產品,通常都會選擇在重要檔期推出,如圣誕、新年和暑假等。準確的項目規劃能使企業在第一時間收回成本并盈利,游戲跳票就意味著被競爭對手搶占先機;若為了在檔期按時發布而忽略了游戲的品質,將給企業帶來更為嚴重的后果,導致游戲只能降價出售,甚至召回。
項目執行過程規范程度。游戲作為創意產業,很多從業人員都充滿智慧、自信、極具創造力,同時也有些不容易受到流程和規則的約束。例如,一些開發人員喜歡增加不必要的“玩家欣賞”,這些功能并不在需求規格說明書中,也不是玩家所期望的,開發這些功能必然會影響項目整體進程。因此,游戲的創意雖要無拘無束,但項目管理必須要流程化、規范化,才能使項目往預期的方向發展,直至游戲成功發布。
美術資源管理。游戲設計中會有大量圖片、視頻等大文件資源,尤其是在3D游戲中,包含模型、貼圖和骨骼等內容。目前的版本控制工具很多都不適合大文件的管理,或者會浪費過多的存儲空間。另外,在游戲發布時,都會對資源文件打包,網游的客戶端文件中有很大部分都為美術資源,只有將這些文件按規則存儲到相對應的路徑并規范命名,才能有序管理這些資源,提高效率。
測試管理。目前國內網游團隊的測試能力相對較弱,大部分都沒有高效、全面的缺陷管理系統,甚至有一些測試工作與客戶支持任務都由同一團隊來負責。相反,測試在歐美游戲公司中起了非常重要的作用,這也是歐美游戲品質上乘的重要原因之一。
有效的需求管理方法
從游戲研發項目點中不難發現,目前存在于游戲開發管理中的很多問題都源于需求管理環節。
量化需求管理
如前所述,游戲項目通常規模巨大,涉及部門眾多。很多歐美視頻游戲的開發投入都在千萬美元以上,通常需要200人以上的專業團隊開發2到3年時間。游戲項目的需求涉及到很多內容,包括游戲類型、界面類型、引擎、游戲性等。
游戲項目的需求文檔最初來源于策劃案,內容包括劇情創意、玩法、美術風格等。結合游戲硬件和軟件環境等因素,被分解生成《游戲功能描述書》,包含眾多內容,若用整篇的文檔來指導開發和測試工作,很容易引起任務分配的混亂;當發生需求變更時,也很難追溯歷史版本。TechExcel從實踐中提煉出一個行之有效的解決方法—用規范點(Specification,以下簡稱Spec)量化需求,正規表達每一個功能單元。只需打開《游戲功能描述書》的WORD文檔,就可以利用插件,將其中的功能單元逐條地復制出來,在需求管理系統DevSpec中直接生成Spec。相對于需求,Spec是更面向技術人員的語言。
有序管理需求變更
在實際項目中,實現需求變更的成本隨著開發進度呈指數級增長。需求變更的流程化管理能保障正常的開發進度,將變更及時反應到開發測試部門。
以下描述的是一個典型過程(如圖1)。一項變更請求在需求管理系統中被提交后,與之關聯的各個部門,如市場、程序、美術、測試等,都會有相關人員接到系統通知而介入。他們將組成評估團隊,根據實施難度、周期、費用、對其他機制的影響等指標,對該變更進行全面考察和評估。在理想的游戲研發管理平臺中,需求管理與所有規劃、開發、測試管理過程相集成。因此,需求的正規表達Spec,以及圍繞Spec正在或將要進行的開發任務和測試任務,都能被納入綜合考慮的范疇,便于評估團隊估算該變更造成的“牽一發而動全身”的潛在影響。有時,還要結合商業需求進行考量,為了趕上最佳發布時機,有些變更將被拒絕。這個過程由獨立的工作流控制,通常包括請求、復查、討論、調整、批準和拒絕等狀態,只有具備權限的項目成員才能改變狀態。按照預設的流程,各方審批全部通過后,該變更才能被接受。
變更請求被批準后,與之相關聯的開發、測試任務都會在系統中被一一標記出來,以提醒程序和測試部門的相關負責人,引發這些任務的需求已經變更,請他們做出相應的調整處理。在系統中跟蹤這些任務的進展,可以實時掌握該變更的落實情況。變更完成后,也可以核算它對開發周期和費用的實際影響,與評估時的預測相對比,找出差異原因,為將來更準確地評估提供參考。
需求指導項目規劃與執行
縱使項目最初都有比較全面的計劃,延期仍然會時常發生,即便是在管理機制比較成熟的歐美游戲公司,跳票也不可避免。通常情況下,導致跳票主要有以下幾點原因:功能設計規劃過多,很多又無法刪除,如不增加開發時間,游戲幾乎不能完成;缺乏有經驗的管理或開發人員,不能準確估計工作量;任務執行缺乏規范,開發人員隨意更改功能設計,影響整體進度;過高的人員流動率,導致知識的流失,任務不能及時跟進。針對以上問題,只要從量化需求入手,有序管理需求變更,用正規表達、可量化的Spec來指導項目規劃、編程和測試,就能把風險降到最低。
基于結構化的Spec集合,可以將項目分解為多個子項目,將Spec直接分配到各自對應的子項目中,以此來規劃和估算子項目的工作量。項目管理人員為每個子項目分配資源,安排優先順序,確定項目里程碑。在游戲項目中,不同部門協作異常緊密,因此子項目間的優先順序顯得尤為重要。例如,游戲音效制作與程序開發之間的相關度看似并不非常緊密,但若音效人員不實際感受游戲,很難體會玩家心情,也就難以創作出應景的音效。
在項目執行時,可以為每一個Spec產生出一系列開發任務。自定義的工作流機制確保每一個任務從提交到最終解決的生命周期都嚴格符合業務流程,保證任何時刻都有唯一的負責人、狀態和截止日期。這樣,不僅能規范游戲制作的過程,還能降低人員流動帶來的風險。任務的流轉及相關知識文檔,如源代碼、美術資源等,都得到系統完整的記錄,還能與任務關聯,便于追溯。一旦有人離開項目,接替的人員能夠查看任務和文檔信息,迅速彌補人員空缺。
以上所述的需求管理經驗,雖然是從游戲行業的實踐中總結得出,卻不囿于游戲行業,項目復雜度較低的一般軟件企業也可以借鑒。
作者:john,梅沙科技產品經理 公眾微信號:短話說產品,個人微信:xiaoteng1234567890.專注于互聯網產品研究。
本文由 @john 原創發布于人人都是產品經理。未經許可,禁止轉載。
然而中國的游戲行業,沒接觸過端游不談,頁游手游只能呵呵了,換皮換皮還是換皮,一套已經成熟的系統框架放在了面前,只需要換換UI,換換原畫和模型就ok啦 ?? ?? ??