簡介游戲項(xiàng)目管理.pdf是一份面向游戲行業(yè)項(xiàng)目經(jīng)理、制作人及團(tuán)隊(duì)管理者的入門級參考手冊內(nèi)容圍繞項(xiàng)目管理的規(guī)劃、組織、人事、領(lǐng)導(dǎo)與控制五大過程展開并系統(tǒng)梳理了項(xiàng)目經(jīng)理、制作人、執(zhí)行制作人、監(jiān)制、企劃、游戲設(shè)計(jì)師等核心角色的職責(zé)邊界。文中還涵蓋了項(xiàng)目定義、組織架構(gòu)搭建、溝通要素、評價(jià)標(biāo)準(zhǔn)與常用工具針對游戲項(xiàng)目規(guī)模擴(kuò)大、進(jìn)度控制等典型挑戰(zhàn)給出管理思路并特別指出項(xiàng)目檢討階段常見的問題點(diǎn)。文件為PDF格式共1個(gè)文件壓縮包僅20KB便于快速閱讀與打印。內(nèi)容預(yù)覽中附有從草案制作到開發(fā)流程的完整說明可幫助讀者建立游戲項(xiàng)目管理的基本框架明確各職能分工適用于希望提升項(xiàng)目管理能力的游戲行業(yè)從業(yè)者。這份輕量而實(shí)用的PDF目前已有390人學(xué)習(xí)下載尤其適合初入游戲行業(yè)、需要快速了解項(xiàng)目管理整體脈絡(luò)的讀者。1. 游戲項(xiàng)目管理.pdf為什么團(tuán)隊(duì)每天很忙卻遲遲做不出第一個(gè)可玩版本大多數(shù)游戲團(tuán)隊(duì)的項(xiàng)目崩盤不是崩在代碼而是崩在“沒人把項(xiàng)目管理當(dāng)一回事”。立項(xiàng)時(shí)聊玩法、聊美術(shù)、聊技術(shù)選型唯獨(dú)沒人聊怎么排期、怎么凍結(jié)需求、怎么驗(yàn)收里程碑。兩個(gè)月后策劃在加需求美術(shù)在返工程序在等定稿所有人都在忙第一個(gè)可玩版本卻遙遙無期。游戲項(xiàng)目管理.pdf 這類文檔講的就是把研發(fā)從“靠感覺推進(jìn)”變成“按里程碑交付”的方法需求怎么拆、排期怎么算、資源怎么排隊(duì)、驗(yàn)收怎么把關(guān)。它最適合主程、主美、制作人和一個(gè)人管多條線的獨(dú)立開發(fā)者目的是讓你從天天救火變成在每周站會上就能看清下一步該干什么。如果你正處在一個(gè)天天延期、周周救火的項(xiàng)目里這文檔最值錢的部分不是流程而是那幾張能直接拿去用的表格。2. 游戲項(xiàng)目管理不是寫文檔先吃透和軟件項(xiàng)目的三個(gè)本質(zhì)差異很多人把軟件項(xiàng)目管理的經(jīng)驗(yàn)原樣搬到游戲上比如照搬敏捷看板結(jié)果第一個(gè)迭代就亂。原因不是方法有問題而是游戲研發(fā)有幾個(gè)軟件項(xiàng)目沒有的特征美術(shù)資源是獨(dú)立且沉重的產(chǎn)出管線、玩法需求必須靠試玩才能收斂、里程碑的驗(yàn)收對象是“體驗(yàn)”而不是“功能”。這三個(gè)差異不先吃透后面所有排期和模板都用不對。2.1 美術(shù)資源管線才是排期瓶頸游戲?yàn)楹尾荒苷瞻崦艚菘窗遘浖?xiàng)目的產(chǎn)出基本都在一套代碼倉庫里一個(gè)功能完成代碼合入并通過驗(yàn)證就算過關(guān)。游戲項(xiàng)目則要同時(shí)產(chǎn)出玩法代碼、美術(shù)資源、音頻、數(shù)值表、文案其中美術(shù)資源常常是整個(gè)進(jìn)度表里最粗的那根管子。一張概念圖要過草圖、線稿、上色、評審、修改、導(dǎo)出好幾輪一個(gè)角色從概念到能進(jìn)游戲正常要兩到三周。更麻煩的是美術(shù)任務(wù)天然串行場景原畫不定建模就沒法開始模型沒完成動(dòng)作和特效就得干等。程序側(cè)可以并行推進(jìn)美術(shù)側(cè)卻有一長串等待鏈。我一般不會讓團(tuán)隊(duì)直接照搬兩周沖刺的看板而是先拉一張美術(shù)資源清單把“資源依賴”畫出來。排期的時(shí)候先看美術(shù)資源在哪一周能交付再回推程序什么時(shí)候可以開始接入。程序側(cè)的任務(wù)按功能切美術(shù)側(cè)的任務(wù)按資產(chǎn)切兩套粒度強(qiáng)行混在一個(gè)看板里很快就會變成“看起來都在動(dòng)實(shí)際都在等”。資源類型預(yù)估件數(shù)單件工期評審輪次依賴前序可否并行主角模型110天3輪角色原畫定稿否待機(jī)/跑/跳動(dòng)作36天2輪模型綁定完成否主界面UI8屏12天2輪交互原型確認(rèn)是技能特效55天1輪技能邏輯可演示是這張表不用追求精確目的是把美術(shù)資源的串行依賴擺到臺面上。填完之后你會發(fā)現(xiàn)很多“卡進(jìn)度”的任務(wù)根本不是工作量問題而是它前面的資源沒到位。2.2 玩法迭代讓需求變更成為常態(tài)三層凍結(jié)機(jī)制怎么設(shè)軟件項(xiàng)目里需求變更是被當(dāng)作異常來管理的要變更就要走審批流程。游戲項(xiàng)目不一樣玩法迭代本身就是產(chǎn)品的一部分。尤其是休閑游戲數(shù)值、手感、關(guān)卡難度不到真實(shí)試玩根本不知道要不要改。強(qiáng)行學(xué)軟件項(xiàng)目那一套“需求凍結(jié)”反而會把團(tuán)隊(duì)的試錯(cuò)空間堵死。所以游戲項(xiàng)目管理要做的不是阻止變更而是把變更按批次消化不讓它像洪水一樣沖垮當(dāng)前排期。常見的做法是設(shè)三層凍結(jié)。第一層是玩法凍結(jié)核心玩法機(jī)制在某個(gè)時(shí)間點(diǎn)之后不再新增只允許調(diào)數(shù)值和表現(xiàn)。第二層是內(nèi)容凍結(jié)外圍系統(tǒng)、關(guān)卡、活動(dòng)內(nèi)容在某個(gè)版本之后封口新內(nèi)容統(tǒng)一進(jìn)下個(gè)版本。第三層是美術(shù)凍結(jié)最終評審?fù)ㄟ^后資源只允許修 bug不允許改設(shè)計(jì)方向。每一層凍結(jié)之后新想法統(tǒng)一進(jìn)入下一版本的需求池而不是當(dāng)場塞進(jìn)當(dāng)前版本。這套機(jī)制能跑通的前提是團(tuán)隊(duì)相信“這個(gè)版本錯(cuò)過了下版本還能用”。凍結(jié)不是砍需求而是給當(dāng)前版本一個(gè)確定性的終點(diǎn)。項(xiàng)目越到后期越要敢于凍結(jié)否則永遠(yuǎn)在動(dòng)、永遠(yuǎn)沒完。2.3 里程碑驗(yàn)收從“完成功能”改成“可玩版本通過試玩清單”軟件項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)是“可用”游戲項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)是“可玩而且值得再玩一次”。這兩個(gè)詞差別非常大。一個(gè)系統(tǒng)功能完成了玩家路徑可能還是斷的一個(gè)關(guān)卡做完了玩起來可能毫無樂趣。所以游戲項(xiàng)目的里程碑不應(yīng)該叫“完成了 XXX 系統(tǒng)”而應(yīng)該叫“某個(gè)版本通過了試玩清單”。我會把每個(gè)里程碑都寫成一張可勾選的試玩清單驗(yàn)收時(shí)不是看 PPT而是真的開一局。清單里至少包含幾類核心循環(huán)能否完整跑通、單局時(shí)長是否符合目標(biāo)、關(guān)鍵手感參數(shù)是否在數(shù)值表允許范圍內(nèi)、美術(shù)資源是否全部替換為正式資源、最低配置設(shè)備幀率是否達(dá)標(biāo)。驗(yàn)收人必須是能拍板的人而不是開發(fā)成員自己。驗(yàn)收項(xiàng)驗(yàn)收標(biāo)準(zhǔn)結(jié)果核心循環(huán)新手關(guān)從開始到成功通關(guān)無需開發(fā)指令通過/不通過單局時(shí)長穩(wěn)定在 90~120 秒實(shí)測數(shù)據(jù)移動(dòng)手感跳臺成功率不低于 70%50次實(shí)測資源替換場景內(nèi)無占位模型逐關(guān)檢查性能低端機(jī)幀率不低于 30幀率記錄有了這張清單驗(yàn)收才不會變成“我覺得還行”和“我覺得不行”的吵架。每一次試玩的數(shù)據(jù)都是下一次迭代的輸入。3. 把 PDF 里的方法落成四份表從立項(xiàng)章程到周報(bào)模板方案聽再多不如落到四張表上。我這里說的四張表就是一套最小可用的游戲項(xiàng)目管理資產(chǎn)項(xiàng)目章程、資源依賴表、風(fēng)險(xiǎn)登記表、一頁紙周報(bào)。每張表都可以在項(xiàng)目剛開始的第一次會議上當(dāng)場搭起來不需要專門的軟件Excel 或者在線表格就夠。3.1 項(xiàng)目章程先寫清玩什么、給誰玩、不做什么項(xiàng)目章程是給整個(gè)團(tuán)隊(duì)立的“共識基線”不需要長篇大論但要能回答幾個(gè)問題。第一個(gè)問題用一句話描述這個(gè)游戲的核心玩法最好帶上具體對象和行為比如“用一根線控制小球到達(dá)終點(diǎn)的解謎游戲”而不是“一個(gè)充滿創(chuàng)意的休閑游戲”。第二個(gè)問題目標(biāo)平臺和用戶是誰這直接決定性能和美術(shù)規(guī)格。第三個(gè)問題是很多團(tuán)隊(duì)會忽略的這個(gè)版本明確不做什么。把“不做什么”寫清楚比寫“要做什么”更能減少后期需求蔓延。我習(xí)慣讓團(tuán)隊(duì)在立項(xiàng)時(shí)花一小時(shí)把這幾點(diǎn)寫在一頁里確認(rèn)后放進(jìn)項(xiàng)目文檔首頁。之后每一次需求評審先拿章程過濾一遍這個(gè)需求能讓核心玩法更好玩嗎符合目標(biāo)平臺嗎有沒有碰“不做什么”的紅線三關(guān)都過才進(jìn)入排期。這個(gè)過程不需要爭吵只需要拿章程對照。章程字段填寫要點(diǎn)示例一句話玩法對象行為目標(biāo)通過拉伸彈弓擊碎目標(biāo)方塊的物理游戲目標(biāo)平臺設(shè)備與系統(tǒng)版本移動(dòng)端最低支持4年前的機(jī)型目標(biāo)用戶年齡段與游戲習(xí)慣12歲以上單局2分鐘內(nèi)的碎片玩家本版本不做明確排除項(xiàng)不做聯(lián)機(jī)、不做內(nèi)購、不做劇情章程不是永不變的但修改必須走全員知曉的流程而不是某個(gè)人私下改了就算。3.2 資源清單與依賴表讓排隊(duì)等待關(guān)系顯性化第二張表是資源清單與依賴表。它解決游戲項(xiàng)目里最常見的“等”字。每個(gè)任務(wù)拆出來之后除了寫負(fù)責(zé)人和工期還要寫兩個(gè)字段前置依賴和釋放條件。前置依賴表示“我必須等誰”釋放條件表示“我完成后誰能開始”。舉例來說一個(gè)“角色待機(jī)動(dòng)作”的資源前置依賴是“角色模型完成”釋放條件則是“模型已綁定骨骼、導(dǎo)出格式正確、文件名符合規(guī)范”。這樣資源一落地下游的人立刻能開始不需要反復(fù)問“好了嗎”。依賴表每周排期會時(shí)過一遍重點(diǎn)找出那些“所有人都在等它”的任務(wù)這種任務(wù)通常是進(jìn)度的真正瓶頸。我見過不少團(tuán)隊(duì)的項(xiàng)目表里只有任務(wù)、負(fù)責(zé)人、截止日期沒有依賴關(guān)系。結(jié)果就是每個(gè)人都在按自己的理解趕工以為自己在關(guān)鍵路徑上實(shí)際上做的活根本沒人接得住。依賴表的價(jià)值就是把這些隱藏的等待關(guān)系挖出來逼著團(tuán)隊(duì)直面問題。3.3 風(fēng)險(xiǎn)登記表每周更新一次不等問題爆了才處理風(fēng)險(xiǎn)登記表的目的是把“我擔(dān)心會發(fā)生的事”變成一條條可跟蹤的記錄。很多團(tuán)隊(duì)沒有這個(gè)習(xí)慣結(jié)果每周都在處理突發(fā)問題。事實(shí)上大部分風(fēng)險(xiǎn)在爆發(fā)前都有征兆只是沒人記錄、沒人跟蹤。表格的字段不需要復(fù)雜序號、風(fēng)險(xiǎn)描述、發(fā)生概率、影響程度、最早可能爆發(fā)時(shí)間、當(dāng)前對策、責(zé)任人、狀態(tài)這幾列就夠。每周站會后花十五分鐘更新一次狀態(tài)從“潛在”到“已規(guī)避”或“已爆發(fā)”。有一條很實(shí)用的判斷標(biāo)準(zhǔn)如果某個(gè)風(fēng)險(xiǎn)連續(xù)三周存在且沒有對策說明它已經(jīng)不是風(fēng)險(xiǎn)而是正在發(fā)生的問題應(yīng)該升級處理而不是繼續(xù)躺在表里。序號風(fēng)險(xiǎn)描述概率影響對策責(zé)任人狀態(tài)1外包動(dòng)畫延遲交付中角色手感聯(lián)調(diào)整體延后提前兩周備份內(nèi)部粗模先動(dòng)主美跟蹤中2關(guān)卡數(shù)值失衡高核心循環(huán)體驗(yàn)破壞每周一次數(shù)值試玩主策劃已緩解3新機(jī)型適配異常低上線前排期占用提前借測預(yù)留2天客戶端組長潛在這張表不是用來“記錄風(fēng)險(xiǎn)”然后不管的。每周必須有一個(gè)人被明確指定為某項(xiàng)風(fēng)險(xiǎn)的推進(jìn)者否則風(fēng)險(xiǎn)條目只會越積越多最后變成一張沒有意義的表格。3.4 一頁紙周報(bào)給制作人看的七個(gè)字段周報(bào)不是寫給領(lǐng)導(dǎo)看的是寫給決策者看的。我見過很多團(tuán)隊(duì)周報(bào)寫了兩三頁重大進(jìn)展、風(fēng)險(xiǎn)分析、團(tuán)隊(duì)感受結(jié)果制作人根本沒時(shí)間看問題出在哪。一頁紙周報(bào)的規(guī)則是只寫七個(gè)字段超出七個(gè)字段的信息說明當(dāng)前版本太亂。這七個(gè)字段是當(dāng)前里程碑剩余天數(shù)、本周完成的任務(wù)數(shù)、本周新進(jìn)入的需求數(shù)、關(guān)鍵路徑狀態(tài)、風(fēng)險(xiǎn)清單摘要、需要拍板的問題、下周承諾。前六項(xiàng)都是客觀信息最后一項(xiàng)才是團(tuán)隊(duì)的承諾。制作人看周報(bào)最該看的是“需要拍板的問題”那一欄如果一個(gè)決策拖了兩周還沒拍那項(xiàng)目停擺的原因根本不在執(zhí)行力在決策速度。字段填寫說明里程碑剩余天數(shù)距最近一次試玩驗(yàn)收還有幾天本周完成按任務(wù)粒度附具體數(shù)量本周新增需求新進(jìn)入當(dāng)前版本的需求數(shù)量關(guān)鍵路徑狀態(tài)綠/黃/紅并注明原因風(fēng)險(xiǎn)摘要只寫新增或狀態(tài)變化的風(fēng)險(xiǎn)需要拍板寫出問題與候選方案等一句回答下周承諾下周能交付的可試玩內(nèi)容如果團(tuán)隊(duì)還處在“每天都很忙但不知道做到哪了”的狀態(tài)先別急著上各種報(bào)表把這份一頁紙周報(bào)跑起來寫夠四周項(xiàng)目面貌會有明顯變化。4. 排期不靠人天估算用產(chǎn)能模型和關(guān)鍵路徑把工期算準(zhǔn)游戲項(xiàng)目排期最怕兩件事一是估算用的“人天”完全不準(zhǔn)二是排期只排任務(wù)不排依賴。第一件事靠產(chǎn)能模型修正第二件事靠關(guān)鍵路徑兜底。兩個(gè)都做了排期才能從“拍腦袋”變成“算出來的”。4.1 為什么人天估算在游戲里必翻車打斷率與返工率人天估算在游戲項(xiàng)目里翻車幾乎是必然的原因是游戲團(tuán)隊(duì)的每個(gè)人一天能保持高強(qiáng)度產(chǎn)出的時(shí)間非常有限。算上晨會、評審會、跨職能對需求、臨時(shí)答疑一個(gè)程序一天能有六小時(shí)有效工作就算不錯(cuò)。美術(shù)更夸張資源返工是常態(tài)一輪評審改了三天評審沒過又要重來。這時(shí)候還按“一個(gè)任務(wù) 3 人天”拍下去實(shí)際很可能要 5 到 6 天。血淚經(jīng)驗(yàn)是人天估算必須乘兩個(gè)系數(shù)。打斷修正系數(shù)用于覆蓋會議、溝通、臨時(shí)支援帶來的效率損失團(tuán)隊(duì)越忙這個(gè)系數(shù)越高返工修正系數(shù)用于覆蓋評審修改、驗(yàn)收不過、需求微調(diào)帶來的額外工時(shí)。比如一個(gè)任務(wù)原始估算 3 天打斷系數(shù) 1.2返工系數(shù) 1.3實(shí)際排期就是 3 乘 1.2 乘 1.3約 4.7 天。第一次排期先按這個(gè)起步跑兩周后用實(shí)際數(shù)據(jù)回填修正系數(shù)比拍腦袋準(zhǔn)得多。參數(shù)默認(rèn)值說明原始估算3天純投入工時(shí)估算不含等待打斷修正系數(shù)1.2會議頻繁時(shí)調(diào)至1.4返工修正系數(shù)1.3新類型任務(wù)調(diào)至1.5排期結(jié)果4.7天3 × 1.2 × 1.3很多團(tuán)隊(duì)不肯乘系數(shù)理由是“排期太長了領(lǐng)導(dǎo)不會同意”。但項(xiàng)目延期和排期太長哪個(gè)代價(jià)更高做過幾個(gè)項(xiàng)目的人心里都有數(shù)。4.2 產(chǎn)能計(jì)算與甘特圖把等待時(shí)間也算進(jìn)排期產(chǎn)能不是“每人每周五個(gè)工作日”。一個(gè)美術(shù)的周產(chǎn)能等于 5 天乘有效工時(shí)系數(shù)再乘 1 減中斷率再乘 1 減返工率。如果有效工時(shí)系數(shù)是 0.8中斷率 0.2返工率 0.3那這個(gè)美術(shù)一周實(shí)際產(chǎn)能只有 5 × 0.8 × 0.8 × 0.7約 2.24 天。聽起來很難接受但這符合大部分真實(shí)項(xiàng)目的狀態(tài)。甘特圖的真正價(jià)值也不是畫給別人看而是把等待時(shí)間顯性化。排期時(shí)不但要排工作時(shí)間還要排等待時(shí)間。一個(gè)任務(wù)做完之后要等多久才能被下游接上這段時(shí)間同樣要畫在圖上。我一般會把依賴關(guān)系里每個(gè)節(jié)點(diǎn)的“等待時(shí)長”單獨(dú)標(biāo)出來如果某個(gè)節(jié)點(diǎn)等待超過兩天就要考慮調(diào)整任務(wù)順序或者讓資源去支援其他部分。4.3 關(guān)鍵路徑的緩沖策略給高不確定性任務(wù)留 20% 余量關(guān)鍵路徑上的任務(wù)晚一天里程碑就晚一天。這是排期里最硬的約束。游戲項(xiàng)目里最容易拖期的任務(wù)有幾種新玩法原型、新渲染管線調(diào)優(yōu)、外包美術(shù)第一次接入。這些任務(wù)的不確定性最大幾乎不可能第一次就估算準(zhǔn)。常見做法是給關(guān)鍵路徑末端加緩沖而不是給每個(gè)任務(wù)都加冗余。把所有任務(wù)上的冗余都抽走集中在里程碑末尾放一個(gè)緩沖池比例在 15% 到 20% 之間。任務(wù)提前完成緩沖就留著任務(wù)延期緩沖被吃掉。這樣一來團(tuán)隊(duì)能清楚看到自己是在“攢余量”還是在“透支余量”。如果某次里程碑的緩沖全部被吃光那就說明關(guān)鍵路徑上的任務(wù)難度被低估了下個(gè)版本要把同類任務(wù)的估算再放大。注意緩沖池必須由制作人或版本負(fù)責(zé)人統(tǒng)一管理不能每個(gè)開發(fā)自己偷偷加兩天。各自加余量的結(jié)果是每個(gè)任務(wù)都看起來很穩(wěn)里程碑整體還是延期的。5. 游戲項(xiàng)目管理避坑五個(gè)真實(shí)翻車場景與對策前面講的是方法這一章講的是方法失效的場景。以下五個(gè)坑我從沒見過哪家團(tuán)隊(duì)能完全躲開區(qū)別只在于踩得深還是淺。5.1 美術(shù)“再調(diào)一版”永遠(yuǎn)調(diào)不完評審意見沒量化現(xiàn)象美術(shù)資源每周評審都有意見每周都在改改到上線前最后一晚還在“再調(diào)一版”。版本號一路從 v1 改到 v8整體風(fēng)格卻和第一版沒什么差別。原因評審意見沒有量化全是“不夠好看”“差點(diǎn)感覺”“你再試試”。執(zhí)行者不知道往哪個(gè)方向改只能憑感覺試試一次不行就再試一次。解決評審記錄必須寫清三件事改哪里、改成什么參數(shù)、不動(dòng)哪里。比如“角色側(cè)臉下頜線角度從 25 度調(diào)到 20 度”“裙擺動(dòng)畫幅度增加 10%”“配色保持不動(dòng)”。意見越具體返工輪次越少。沒有量化意見的評審會寧可不開。5.2 需求文檔寫滿了驗(yàn)收時(shí)還在吵缺少驗(yàn)收基線現(xiàn)象策劃說程序沒做對程序說按文檔做完了兩邊拿著同一份需求文檔吵了一下午。文檔里功能路徑、交互流程、界面說明都寫了但分歧還是在。原因文檔寫的是行為和功能沒寫驗(yàn)收基線。程序認(rèn)為“跑通邏輯”就是完成策劃心中的完成是“手感好、表現(xiàn)到位”兩者的標(biāo)準(zhǔn)完全不在一個(gè)維度。解決每個(gè)需求帶一句“滿足什么條件算完成”。比如“玩家連續(xù)跳 5 次同一平臺不再卡邊”“低端機(jī)型幀率不低于 30”“連擊第 3 段命中后有 0.2 秒頓幀反饋”。驗(yàn)收基線寫得越具體驗(yàn)收時(shí)的爭吵越少。5.3 版本分支合并翻車功能分支存活太久變成“世界分支”現(xiàn)象分支開了一堆每個(gè)分支都活了半個(gè)月以上。合并時(shí)沖突十幾處甚至幾十處修沖突修了一整天最后甚至把美術(shù)資源的二進(jìn)制文件搞壞整個(gè)版本回退。原因自由分支策略下長期存活的開發(fā)分支會逐步偏離主干和別人的改動(dòng)漸行漸遠(yuǎn)。分支存活越久合并成本越高到后期干脆沒人敢合。解決主干開發(fā)短分支分支只活兩到三天完成任務(wù)立刻合入。美術(shù)資源不要放在代碼分支里反復(fù)合并而是通過成品目錄統(tǒng)一導(dǎo)入代碼倉庫只保留導(dǎo)入后的結(jié)果。每次合入前先同步主干再合并合并后立刻打上版本標(biāo)簽保證隨時(shí)可以回退。5.4 進(jìn)度永遠(yuǎn)是 80%沒有完成定義現(xiàn)象問某個(gè)任務(wù)完成多少答復(fù)永遠(yuǎn)是“80%就差最后一點(diǎn)”。第二周再問還是 80%。最后在版本節(jié)點(diǎn)前熬了三個(gè)通宵才把任務(wù)收尾。原因每個(gè)人對“完成”的定義不同。程序覺得功能跑通算完成美術(shù)覺得資源導(dǎo)入算完成策劃覺得數(shù)值調(diào)好才算完成。沒有統(tǒng)一標(biāo)準(zhǔn)進(jìn)度百分比就成了各自心里的感覺值。解決給每個(gè)任務(wù)定義完成條件也就是 DoD。代碼合入主分支并跑通冒煙、資源正式入庫且文件名規(guī)范、自測用例全部通過、能出現(xiàn)在試玩清單中。四條全過才算“完成”否則一律算“進(jìn)行中”。這樣進(jìn)度表上再也看不到永遠(yuǎn) 80% 的任務(wù)。5.5 跨職能評審變成吵架會沒有決策人現(xiàn)象評審會上策劃、程序、美術(shù)各說各的每個(gè)人都從自己專業(yè)角度出發(fā)最后誰都說服不了誰會議開完沒有結(jié)論問題拖到下個(gè)版本繼續(xù)吵。原因會議只有討論機(jī)制沒有決策機(jī)制。參與的人都是“意見提供者”沒有一個(gè)人是“問題拍板者”。沒有決策人的評審會本質(zhì)是集體閑聊。解決評審會必須有一位明確的決策人通常是制作人或核心主設(shè)計(jì)。會上先討論但討論必須在約定時(shí)間內(nèi)結(jié)束到了時(shí)間決策人拍板。當(dāng)場拍不了板的問題記錄到風(fēng)險(xiǎn)登記表明確下次決策的時(shí)間和負(fù)責(zé)人絕不懸著拖延。6. 用三個(gè)數(shù)據(jù)自檢項(xiàng)目管理是否有效從試玩版本數(shù)量開始方法用了一段時(shí)間怎么知道它真的有用我習(xí)慣看三個(gè)數(shù)據(jù)每周統(tǒng)計(jì)半小時(shí)連著看四周項(xiàng)目狀態(tài)就藏在這幾個(gè)數(shù)字里。6.1 可用功能數(shù)替代完成任務(wù)數(shù)的硬指標(biāo)每周統(tǒng)計(jì)一個(gè)數(shù)字本周實(shí)際能玩到的功能數(shù)。完成任務(wù)數(shù)會說謊可用功能數(shù)不會。如果任務(wù)完成了一大堆功能數(shù)沒漲說明團(tuán)隊(duì)在做返工或者無效任務(wù)。這個(gè)數(shù)字漲得快說明管線是通的。6.2 需求變更率與返工成本每周記錄新增需求數(shù)、修改需求數(shù)和已驗(yàn)收任務(wù)被返工的數(shù)量。正常情況下新增需求說明產(chǎn)品在迭代但返工成本一旦超過總工時(shí)兩成就要反思需求評審是不是太粗、驗(yàn)收基線是不是沒定清楚。指標(biāo)健康線警告線可用功能數(shù)每周穩(wěn)定增長連續(xù)兩周不漲返工占比低于20%超過30%關(guān)鍵路徑狀態(tài)兩周內(nèi)全綠出現(xiàn)紅色節(jié)點(diǎn)6.3 產(chǎn)能負(fù)荷對比用連續(xù)兩周的數(shù)據(jù)對比表上的計(jì)劃任務(wù)量和實(shí)際完成量得到一個(gè)真實(shí)產(chǎn)能系數(shù)。把系數(shù)帶進(jìn)下一次排期估算會準(zhǔn)很多。這個(gè)數(shù)據(jù)不拿來追責(zé)只拿來校準(zhǔn)排期節(jié)奏。我自己的習(xí)慣是每周五下午花半小時(shí)把這幾個(gè)數(shù)字填到項(xiàng)目記錄里不評價(jià)任何人只看趨勢。如果你的項(xiàng)目也總在救火先別急著換引擎或換人翻一翻手邊這份游戲項(xiàng)目管理文檔把里面最樸素的幾張表用起來大概率能少熬幾個(gè)夜。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取