200人以上的專業(yè)團隊開發(fā)2到3年時間。游戲項目的需求涉及到很多內(nèi)容，包括游戲類型、界面類型、引擎、游戲性等。
游戲項目的需求文檔最初來源于策劃案，內(nèi)容包括劇情創(chuàng)意、玩法、美術(shù)風格等。結(jié)合游戲硬件和軟件環(huán)境等因素，被分解生成《游戲功能描述書》，包含眾多內(nèi)容，若用整篇的文檔來指導開發(fā)和測試工作，很容易引起任務分配的混亂;當發(fā)生需求變更時，也很難追溯歷史版本。TechExcel從實踐中提煉出一個行之有效的解決方法-用規(guī)范點(Specification，以下簡稱Spec)量化需求，正規(guī)表達每一個功能單元。只需打開《游戲功能描述書》的WORD文檔，就可以利用插件，將其中的功能單元逐條地復制出來，在需求管理系統(tǒng)DevSpec中直接生成Spec。相對于需求，Spec是更面向技術(shù)人員的語言。
有序管理需求變更
在實際項目中，實現(xiàn)需求變更的成本隨著開發(fā)進度呈指數(shù)級增長。需求變更的流程化管理能保障正常的開發(fā)進度，將變更及時反應到開發(fā)測試部門。
以下描述的是一個典型過程(如圖1)。一項變更請求在需求管理系統(tǒng)中被提交后，與之關(guān)聯(lián)的各個部門，如市場、程序、美術(shù)、測試等，都會有相關(guān)人員接到系統(tǒng)通知而介入。他們將組成評估團隊，根據(jù)實施難度、周期、費用、對其他機制的影響等指標，對該變更進行全面考察和評估。在理想的游戲研發(fā)管理平臺中，需求管理與所有規(guī)劃、開發(fā)、測試管理過程相集成。因此，需求的正規(guī)表達Spec，以及圍繞Spec正在或?qū)⒁M行的開發(fā)任務和測試任務，都能被納入綜合考慮的范疇，便于評估團隊估算該變更造成的"牽一發(fā)而動全身"的潛在影響。有時，還要結(jié)合商業(yè)需求進行考量，為了趕上最佳發(fā)布時機，有些變更將被拒絕。這個過程由獨立的工作流控制，通常包括請求、復查、討論、調(diào)整、批準和拒絕等狀態(tài)，只有具備權(quán)限的項目成員才能改變狀態(tài)。按照預設(shè)的流程，各方審批全部通過后，該變更才能被接受。
變更請求被批準后，與之相關(guān)聯(lián)的開發(fā)、測試任務都會在系統(tǒng)中被一一標記出來，以提醒程序和測試部門的相關(guān)負責人，引發(fā)這些任務的需求已經(jīng)變更，請他們做出相應的調(diào)整處理。在系統(tǒng)中跟蹤這些任務的進展，可以實時掌握該變更的落實情況。變更完成后，也可以核算它對開發(fā)周期和費用的實際影響，與評估時的預測相對比，找出差異原因，為將來更準確地評估提供參考。
需求指導項目規(guī)劃與執(zhí)行
縱使項目最初都有比較全面的計劃，延期仍然會時常發(fā)生，即便是在管理機制比較成熟的歐美游戲公司，跳票也不可避免。通常情況下，導致跳票主要有以下幾點原因：功能設(shè)計規(guī)劃過多，很多又無法刪除，如不增加開發(fā)時間，游戲幾乎不能完成;缺乏有經(jīng)驗的管理或開發(fā)人員，不能準確估計工作量;任務執(zhí)行缺乏規(guī)范，開發(fā)人員隨意更改功能設(shè)計，影響整體進度;過高的人員流動率，導致知識的流失，任務不能及時跟進。針對以上問題，只要從量化需求入手，有序管理需求變更，用正規(guī)表達、可量化的Spec來指導項目規(guī)劃、編程和測試，就能把風險降到最低。
基于結(jié)構(gòu)化的Spec集合，可以將項目分解為多個子項目，將Spec直接分配到各自對應的子項目中，以此來規(guī)劃和估算子項目的工作量。項目管理人員為每個子項目分配資源，安排優(yōu)先順序，確定項目里程碑。在游戲項目中，不同部門協(xié)作異常緊密，因此子項目間的優(yōu)先順序顯得尤為重要。例如，游戲音效制作與程序開發(fā)之間的相關(guān)度看似并不非常緊密，但若音效人員不實際感受游戲，很難體會玩家心情，也就難以創(chuàng)作出應景的音效。
在項目執(zhí)行時，可以為每一個Spec產(chǎn)生出一系列開發(fā)任務。自定義的工作流機制確保每一個任務從提交到最終解決的生命周期都嚴格符合業(yè)務流程，保證任何時刻都有唯一的負責人、狀態(tài)和截止日期。這樣，不僅能規(guī)范游戲制作的過程，還能降低人員流動帶來的風險。任務的流轉(zhuǎn)及相關(guān)知識文檔，如源代碼、美術(shù)資源等，都得到系統(tǒng)完整的記錄，還能與任務關(guān)聯(lián)，便于追溯。一旦有人離開項目，接替的人員能夠查看任務和文檔信息，迅速彌補人員空缺。
以上所述的需求管理經(jīng)驗，雖然是從游戲行業(yè)的實踐中總結(jié)得出，卻不囿于游戲行業(yè)，項目復雜度較低的一般軟件企業(yè)也可以借鑒。