實戰遊戲專案管理-計劃篇
1、管理無定法，有效最關鍵
管理沒有固定模式，管理方法是有達到管理預期結果的手段，專案管理也是如此。遊戲專案管理中不同的專案規模、同一個專案不同的時期，同一個時期不同的團隊、不同的人，管理方法可能都不一樣，這裡只列出我的經驗和要點，當你面對不同環境的時候，選擇一個你認為最合適的管理方法就好。關鍵的是你選擇某一個方法後，要評估這個方法是否真的有效，記住“有效最關鍵”
2、版本計劃
制定計劃是非常重要而複雜的一個過程，專案越大越複雜，但是隻要按照這個一部一部做，一定可以把計劃做好。任何計劃都是有變更風險的，計劃不如變化但必須有計劃。這點必須要給參與專案計劃制定的人講清楚，不要因為怕變更而不敢做決策，一個有經驗的主程、主美、主策劃都能把變更風險降到最低。這張圖說明的是預測與現實的差距
2.1 開發流程
做計劃之前先要搞清楚當前的開發流程，不同的行業不同的開發流程，不同的專案不同也有不同的開發流程。這裡以一個遊戲行業典型的開發流程舉例，他包含版本規劃、策劃設計、UI設計、程式開發、測試幾個階段。中間有幾個關鍵里程碑一個是制定版本內容（版本規劃），一個是需求說明會（確定相信策劃案），策劃評審（開發完成準備策劃進行確認）
另外美術的製作流程也是差異很大的，這裡以一個3D場景的流程為例，包括策劃設計、原畫設計、3D場景物件建模、場景地圖編輯（烘培、減面）、遊戲接入等環節，也包括2個較重要的里程碑，需求說明會（說明設計意圖）和策劃評審（對產出資源的評審）
2.2 版本規劃與需求池
另外，版本規劃中不光有策劃的需求喲，一般還會有技術相關的底層需求，還有美術相關的資源需求，所以這個版本規劃是需要主程、主美、運營共同參與討論制定的。
還有另一種制定方法，就是“需求池”。這是指策劃把已經規劃、設計好的需求集中管理的一個地方。需求池的策劃內容可能是製作人的一個想法，一個設計，也可能是某個版本上線後的玩家反饋、運營反饋、老闆反饋，等等，不管來源是什麼最終制作人、主策劃決定要搞了就先放到這個需求池裡，防止後面做版本計劃的時候又忘了。這種一般在遊戲上線後的專案管理應用比較多，非常實用。需求池一般包括需求條目、優先順序、預期開發版本、狀態、策劃負責人、需求來源等。
舉例
2.3版本計劃制定
學過PMP的應該都知道WBS，首先在策劃定出的版本內容上進行任務分解，這裡的經驗是：把需求任務分拆到一個人可以獨立完成這個粒度，這樣方便管理。
做完分拆後，對每個任務進行負責人分配，如果是外包寫上外包介面人。這個人員分配步驟比較複雜，因為每個人工作能力不一樣，適合做的任務也不一樣。這裡有個實用的技巧，一般可以設定個原則來進行分配，這樣可以簡化這個人員分工問題，舉個例子，程式設計師的分配，可以設定幾個小分組，相對固定，比如A小組主要負責玩法的開發，B小組負責系統的開發等等，有了這個分工，先按這個分工來，再根據後面的實際分配情況（分配不均）再做微調，另外，這個過程可以由主程、主美主導，因為他最瞭解他們。
Power管理法，這是一個改進的條狀圖（甘特圖）的管理方法，包括：內容、優先順序、負責人、狀態、時間排期，而排期是用如下顏色區分的。這個比傳統的甘特圖更直觀，更符合軟體、遊戲專案管理現狀。當然他忽略掉了某些重疊部分的可能，但那部分不會對各工作造成影響，這樣不會過細，也不會過粗。
這裡的稽核包括，需求評審會、策劃稽核兩個里程碑的時間。而美術也可以用這個來計劃比如這樣，你可以根據你的工作流來靈活定義
每天專案經理在跟進完進度後需要在上面標一個“*”號來說明這個事情確實在做，沒問題，如果出現問題了，可以寫上備註，或者調整計劃。一個版本下來這個表格就是整個專案的“真實情況的反映”。
邊界說明會，策劃拿到版本規劃後，主策劃需要先講解給所有策劃，讓大家瞭解“需求目的”與“內容邊界”，然後策劃在消化後儘快同步給主程式、主UI等相關負責人。因為他們要根據你的“需求目的”與“內容邊界”進行時間評估
經驗：“內容邊界”是最重要的這個決定了工作量，負責實現這個需求的負責人要充分預估他的難度，和策劃的隱性需求，這個非常考驗負責人的經驗。
經驗：當一個任務過於複雜，請負責人嘗試把他進行拆分，拆到一個版本、一個執行負責人的粒度
2.4 策劃的時間分配
分配完人之後就是分配時間了，這個一般是從前往後先排策劃的設計時間，一般策劃儘量把一部分在版本開始前就設計好，這樣不至於出現版本開始前其他所有人在等策劃了。
策劃說明會，記住一定要在策劃案後排一個策劃說明會（里程碑）的時間，要求策劃在後續工作開始前進行這個會。目的有兩個，一是為了確認策劃案，二是讓所有參與這個任務的人在一起交流發表自己的觀點。
經驗：提前把策劃案發給所有相關負責人，這個會的目的不是為了在會上聊細節，細節策劃要提起和主策劃、相關的負責人溝通清楚，儘量保證會上能通過策劃案。當然如果策劃案寫得差，沒有事先溝通，被程式、UI一頓屌，重新寫策劃案，重新開需求說明會的概率會很大。經驗：策劃說明會，可以看出策劃的設計能力，同時也能反映出技術負責人的經驗。
2.5 UI的時間分配
UI時間最大的變數在於，風格的不確定，這個在計劃的時候考慮給最大幹系人（一般是製作人甚至是老闆）的稽核時間，建議效果圖儘可能早的給他們看。另外，程式開始前需要UE設計互動邏輯，為了節省時間，在定出互動後先實現框架，UI框架、互動邏輯先提交給程式實現邏輯，UI畫面細節可以同時並行完善。
經驗：一般定風格都會改幾版，甚至整體風格。
2.6 程式的時間分配
遊戲專案一般有個特點，程式部分一般是由客戶端程式設計師和伺服器程式設計師共同完成，所以一般在制定完計劃後需要分別看兩個程式設計師的工作是否排布合理，如果排布不合理經常會出現開發完了沒時間聯調的情況。按前面所說，儘量繫結小組負責制，可以減少這種衝突的情況。
經驗：一般遊戲專案組的客戶端程式設計師、伺服器程式設計師配比是2：1的比例，也就是客戶端的人會多些，因為客戶端相對工作量會大，所以一般按客戶端的時間來評估整個技術的時間，伺服器能保證在客戶端完成的時候可以完成就可以了，而且一般伺服器是可以多項工作並行的
2.7測試的時間分配
遊戲專案中在開完需求說明會後，測試就可以開始寫用例了，這裡就不需要管理他們的時間，只有他們在開始測試前寫好就可以了。而一個版本通常會在最後階段排一個專門的一週進行測試迴歸，這個用來進行版本回歸測試。
2.8美術的時間分配
美術的計劃特點是時間相對固定，如果是自己人做一般都比較好評估，如果是外包，則一定要考慮，外包返工修改的時間，而發包前的外包商測試，則儘量在任務開始前完成，不然這個任務鐵定延期。
3、風險評估
計劃做好後，就是把關鍵路徑找到，通常是最長的那個，看看他的優先順序如果比較高，儘量提前做吧。風險評估高的任務最好都安排實力相對強的同學做，儘量避免延期。
經驗：如果一個任務不能在迴歸測試前完成程式開發的話，基本也有打不進包裡的風險，風險評估項裡寫進去，提前告訴製作人。
4、工單管理
工單管理工具有很多，什麼禪道(bugfree)，JIRA，可以根據實際情況選擇，可以在計劃制定完成後，開始給各負責人派發工單，工單管理流程可以根據使用的工具靈活選擇，不過錄入工單是一個非常痛苦的過程，而調整計劃後的調整工單更痛苦，所以我們只用工單來管理小任務（計劃上沒有的臨時任務）和BUG，這是一個典型的工單流程，工單的狀態定義可以自己根據實際情況來定義，關鍵是大家都能統一：
