項(xiàng)目整體復(fù)雜性強(qiáng)

游戲是一種特殊的軟件，尤其是大型網(wǎng)游，通常比一般的軟件開發(fā)規(guī)模大、人數(shù)多、周期長(zhǎng)、復(fù)雜程度高。首先，正規(guī)的游戲開發(fā)會(huì)包括策劃、美術(shù)（含2D和3D）、編程和測(cè)試等多個(gè)團(tuán)隊(duì)，如何使這些具備不同工作技能的團(tuán)隊(duì)成員協(xié)同工作，如何使各個(gè)工作環(huán)節(jié)銜接順暢，是一個(gè)頗為復(fù)雜的問題；其次，網(wǎng)絡(luò)游戲項(xiàng)目的開發(fā)周期較長(zhǎng)，雖說一般在1年半到2年之間；另外，游戲項(xiàng)目的成敗很大程度上依賴于市場(chǎng)對(duì)游戲的反響和接受意愿，頻繁的需求變更再次增添了游戲研發(fā)的復(fù)雜性。

需求管理難度大

游戲的需求管理貫穿整個(gè)開發(fā)過程，是影響游戲開發(fā)質(zhì)量的關(guān)鍵。游戲項(xiàng)目最初的需求是從策劃部門提交的游戲創(chuàng)意、玩法、美術(shù)風(fēng)格、大致背景、特色系統(tǒng)、與同類游戲區(qū)別等等一系列繁雜的內(nèi)容中，通過各部門討論和評(píng)估而總結(jié)出來的。雖然通過需求分析會(huì)得到《游戲功能描述書》這一結(jié)果性文檔，但如果不進(jìn)一步結(jié)構(gòu)化分解，項(xiàng)目成員要進(jìn)行任務(wù)分配和編程仍然很難。

除了最初的需求分析，需求變更管理也是一個(gè)難點(diǎn)。游戲項(xiàng)目計(jì)劃經(jīng)常改動(dòng)，往往也是由需求變更引起的。一方面，為了使游戲發(fā)布后更具有競(jìng)爭(zhēng)力，需求變更不可避免，如果不對(duì)變更進(jìn)行評(píng)估取舍，項(xiàng)目的整體目標(biāo)可能很難達(dá)到；另一方面，為了彌補(bǔ)需求變更對(duì)項(xiàng)目進(jìn)程帶來的影響，開發(fā)人員常常快速的進(jìn)行功能修改和增加，而沒有遵循統(tǒng)一的流程控制，從而使游戲整體的有序性被破壞，人為地增加了工作量，最后導(dǎo)致跳票。

項(xiàng)目規(guī)劃與執(zhí)行要求高

項(xiàng)目規(guī)劃準(zhǔn)確性。游戲作為大眾娛樂的商業(yè)產(chǎn)品，通常都會(huì)選擇在重要檔期推出，如圣誕、新年和暑假等。準(zhǔn)確的項(xiàng)目規(guī)劃能使企業(yè)在第一時(shí)間收回成本并盈利，游戲跳票就意味著被競(jìng)爭(zhēng)對(duì)手搶占先機(jī)；若為了在檔期按時(shí)發(fā)布而忽略了游戲的品質(zhì)，將給企業(yè)帶來更為嚴(yán)重的后果，導(dǎo)致游戲只能降價(jià)出售，甚至召回。

項(xiàng)目執(zhí)行過程規(guī)范程度。游戲作為創(chuàng)意產(chǎn)業(yè)，很多從業(yè)人員都充滿智慧、自信、極具創(chuàng)造力，同時(shí)也有些不容易受到流程和規(guī)則的約束。例如，一些開發(fā)人員喜歡增加不必要的“玩家欣賞”，這些功能并不在需求規(guī)格說明書中，也不是玩家所期望的，開發(fā)這些功能必然會(huì)影響項(xiàng)目整體進(jìn)程。因此，游戲的創(chuàng)意雖要無拘無束，但項(xiàng)目管理必須要流程化、規(guī)范化，才能使項(xiàng)目往預(yù)期的方向發(fā)展，直至游戲成功發(fā)布。

美術(shù)資源管理。游戲設(shè)計(jì)中會(huì)有大量圖片、視頻等大文件資源，尤其是在3D游戲中，包含模型、貼圖和骨骼等內(nèi)容。目前的版本控制工具很多都不適合大文件的管理，或者會(huì)浪費(fèi)過多的存儲(chǔ)空間。另外，在游戲發(fā)布時(shí)，都會(huì)對(duì)資源文件打包，網(wǎng)游的客戶端文件中有很大部分都為美術(shù)資源，只有將這些文件按規(guī)則存儲(chǔ)到相對(duì)應(yīng)的路徑并規(guī)范命名，才能有序管理這些資源，提高效率。

測(cè)試管理。目前國(guó)內(nèi)網(wǎng)游團(tuán)隊(duì)的測(cè)試能力相對(duì)較弱，大部分都沒有高效、全面的缺陷管理系統(tǒng)，甚至有一些測(cè)試工作與客戶支持任務(wù)都由同一團(tuán)隊(duì)來負(fù)責(zé)。相反，測(cè)試在歐美游戲公司中起了非常重要的作用，這也是歐美游戲品質(zhì)上乘的重要原因之一。

有效的需求管理方法

從游戲研發(fā)項(xiàng)目點(diǎn)中不難發(fā)現(xiàn)，目前存在于游戲開發(fā)管理中的很多問題都源于需求管理環(huán)節(jié)。

量化需求管理

如前所述，游戲項(xiàng)目通常規(guī)模巨大，涉及部門眾多。很多歐美視頻游戲的開發(fā)投入都在千萬美元以上，通常需要200人以上的專業(yè)團(tuán)隊(duì)開發(fā)2到3年時(shí)間。游戲項(xiàng)目的需求涉及到很多內(nèi)容，包括游戲類型、界面類型、引擎、游戲性等。

游戲項(xiàng)目的需求文檔最初來源于策劃案，內(nèi)容包括劇情創(chuàng)意、玩法、美術(shù)風(fēng)格等。結(jié)合游戲硬件和軟件環(huán)境等因素，被分解生成《游戲功能描述書》，包含眾多內(nèi)容，若用整篇的文檔來指導(dǎo)開發(fā)和測(cè)試工作，很容易引起任務(wù)分配的混亂；當(dāng)發(fā)生需求變更時(shí)，也很難追溯歷史版本。TechExcel從實(shí)踐中提煉出一個(gè)行之有效的解決方法—用規(guī)范點(diǎn)（Specification，以下簡(jiǎn)稱Spec）量化需求，正規(guī)表達(dá)每一個(gè)功能單元。只需打開《游戲功能描述書》的WORD文檔，就可以利用插件，將其中的功能單元逐條地復(fù)制出來，在需求管理系統(tǒng)DevSpec中直接生成Spec。相對(duì)于需求，Spec是更面向技術(shù)人員的語言。

有序管理需求變更

在實(shí)際項(xiàng)目中，實(shí)現(xiàn)需求變更的成本隨著開發(fā)進(jìn)度呈指數(shù)級(jí)增長(zhǎng)。需求變更的流程化管理能保障正常的開發(fā)進(jìn)度，將變更及時(shí)反應(yīng)到開發(fā)測(cè)試部門。

以下描述的是一個(gè)典型過程（如圖1）。一項(xiàng)變更請(qǐng)求在需求管理系統(tǒng)中被提交后，與之關(guān)聯(lián)的各個(gè)部門，如市場(chǎng)、程序、美術(shù)、測(cè)試等，都會(huì)有相關(guān)人員接到系統(tǒng)通知而介入。他們將組成評(píng)估團(tuán)隊(duì)，根據(jù)實(shí)施難度、周期、費(fèi)用、對(duì)其他機(jī)制的影響等指標(biāo)，對(duì)該變更進(jìn)行全面考察和評(píng)估。在理想的游戲研發(fā)管理平臺(tái)中，需求管理與所有規(guī)劃、開發(fā)、測(cè)試管理過程相集成。因此，需求的正規(guī)表達(dá)Spec，以及圍繞Spec正在或?qū)⒁M(jìn)行的開發(fā)任務(wù)和測(cè)試任務(wù)，都能被納入綜合考慮的范疇，便于評(píng)估團(tuán)隊(duì)估算該變更造成的“牽一發(fā)而動(dòng)全身”的潛在影響。有時(shí)，還要結(jié)合商業(yè)需求進(jìn)行考量，為了趕上最佳發(fā)布時(shí)機(jī)，有些變更將被拒絕。這個(gè)過程由獨(dú)立的工作流控制，通常包括請(qǐng)求、復(fù)查、討論、調(diào)整、批準(zhǔn)和拒絕等狀態(tài)，只有具備權(quán)限的項(xiàng)目成員才能改變狀態(tài)。按照預(yù)設(shè)的流程，各方審批全部通過后，該變更才能被接受。

變更請(qǐng)求被批準(zhǔn)后，與之相關(guān)聯(lián)的開發(fā)、測(cè)試任務(wù)都會(huì)在系統(tǒng)中被一一標(biāo)記出來，以提醒程序和測(cè)試部門的相關(guān)負(fù)責(zé)人，引發(fā)這些任務(wù)的需求已經(jīng)變更，請(qǐng)他們做出相應(yīng)的調(diào)整處理。在系統(tǒng)中跟蹤這些任務(wù)的進(jìn)展，可以實(shí)時(shí)掌握該變更的落實(shí)情況。變更完成后，也可以核算它對(duì)開發(fā)周期和費(fèi)用的實(shí)際影響，與評(píng)估時(shí)的預(yù)測(cè)相對(duì)比，找出差異原因，為將來更準(zhǔn)確地評(píng)估提供參考。

需求指導(dǎo)項(xiàng)目規(guī)劃與執(zhí)行

縱使項(xiàng)目最初都有比較全面的計(jì)劃，延期仍然會(huì)時(shí)常發(fā)生，即便是在管理機(jī)制比較成熟的歐美游戲公司，跳票也不可避免。通常情況下，導(dǎo)致跳票主要有以下幾點(diǎn)原因：功能設(shè)計(jì)規(guī)劃過多，很多又無法刪除，如不增加開發(fā)時(shí)間，游戲幾乎不能完成；缺乏有經(jīng)驗(yàn)的管理或開發(fā)人員，不能準(zhǔn)確估計(jì)工作量;任務(wù)執(zhí)行缺乏規(guī)范，開發(fā)人員隨意更改功能設(shè)計(jì)，影響整體進(jìn)度；過高的人員流動(dòng)率，導(dǎo)致知識(shí)的流失，任務(wù)不能及時(shí)跟進(jìn)。針對(duì)以上問題，只要從量化需求入手，有序管理需求變更，用正規(guī)表達(dá)、可量化的Spec來指導(dǎo)項(xiàng)目規(guī)劃、編程和測(cè)試，就能把風(fēng)險(xiǎn)降到最低。

基于結(jié)構(gòu)化的Spec集合，可以將項(xiàng)目分解為多個(gè)子項(xiàng)目，將Spec直接分配到各自對(duì)應(yīng)的子項(xiàng)目中，以此來規(guī)劃和估算子項(xiàng)目的工作量。項(xiàng)目管理人員為每個(gè)子項(xiàng)目分配資源，安排優(yōu)先順序，確定項(xiàng)目里程碑。在游戲項(xiàng)目中，不同部門協(xié)作異常緊密，因此子項(xiàng)目間的優(yōu)先順序顯得尤為重要。例如，游戲音效制作與程序開發(fā)之間的相關(guān)度看似并不非常緊密，但若音效人員不實(shí)際感受游戲，很難體會(huì)玩家心情，也就難以創(chuàng)作出應(yīng)景的音效。

在項(xiàng)目執(zhí)行時(shí)，可以為每一個(gè)Spec產(chǎn)生出一系列開發(fā)任務(wù)。自定義的工作流機(jī)制確保每一個(gè)任務(wù)從提交到最終解決的生命周期都嚴(yán)格符合業(yè)務(wù)流程，保證任何時(shí)刻都有唯一的負(fù)責(zé)人、狀態(tài)和截止日期。這樣，不僅能規(guī)范游戲制作的過程，還能降低人員流動(dòng)帶來的風(fēng)險(xiǎn)。任務(wù)的流轉(zhuǎn)及相關(guān)知識(shí)文檔，如源代碼、美術(shù)資源等，都得到系統(tǒng)完整的記錄，還能與任務(wù)關(guān)聯(lián)，便于追溯。一旦有人離開項(xiàng)目，接替的人員能夠查看任務(wù)和文檔信息，迅速?gòu)浹a(bǔ)人員空缺。

以上所述的需求管理經(jīng)驗(yàn)，雖然是從游戲行業(yè)的實(shí)踐中總結(jié)得出，卻不囿于游戲行業(yè)，項(xiàng)目復(fù)雜度較低的一般軟件企業(yè)也可以借鑒。

作者：john，梅沙科技產(chǎn)品經(jīng)理 公眾微信號(hào)：短話說產(chǎn)品，個(gè)人微信：xiaoteng1234567890.專注于互聯(lián)網(wǎng)產(chǎn)品研究。

本文由 @john 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。