網路遊戲
專案管理
的特殊性：
國內大多數的遊戲公司
專案管理
都採用傳統方式，沒有考慮到行業的特殊性。網路遊戲的研發是一項要求精細度很高的工程，每個開發單位之間的銜接都是非常緊密的。在實際的研發過程中，我深入的分析了決定研發成果的過程，以下部分是根據我三年研發和管理的經驗，經過多次調整後，確定下來的管理模式。
專案前期：
專案前期需要建立專案臨時小組，成員包括專案負責人和開發成員。負責人確定後，由他提出《專案立項需求書》。需求書中需要包含市場分析、遊戲內部需求分析、專案綜述、對程式設計的要求、參數列、各種物品的開發描述、預計的開發周期、特殊需要注意的說明、設計參考圖、流程圖、立項確定的最終週期。每次組內討論，都要對達成部分內容的共識保留相關記錄。記錄中，每個好的提議都要署名，以備年終考核以及職業發展參考用。當交流達到大部分的共識之後，負責人需要整理出《專案執行方案》。執行方案中包含可執行策劃、效果圖、多方確認的開發進度表。可執行方案中的重要部分應做特殊標記，以確保最終產品同方案無重要出入。
專案中期：
專案中期會是乙個相對長的整合時間。這個過程中，最重要的就是記錄和統一。記錄不僅僅是只為重要決策服務的，任何微小的分析，都會直接影響最終的開發進度，導致大量的返工。開發進行中，主框架修改時應慎重，任何重大修改，都必須經過全體臨時組成員通過。分歧最終確認後，負責人需要修改執行方案並做特殊標記。文案傳送臨時組內各成員，並及時更新。專案文案的修改，需要進行不用顏色的標註：專案中重要部分，統一用一種顏色標記；每次修改的部分，分別要用不同顏色做標記；有爭議的部分，統一用第三種顏色標記；程式開發部分，統一用一種顏色標記；如遇多專案並行方案，不同開發的部分，使用不同的顏色標記相區別；美術開發部分，統一用一種顏色標記；如遇多專案並行方案，不同開發部分，都要使用不同顏色標記相區別。這五項內容，使用的顏色都互相區別。有爭議的部分，每次達成一致後，顏色恢復黑色。專案文案中，應含有清楚明了的顏色標記說明。例如：重要部分顏色統一標記為紅色；程式開發部分統一標記為綠色；美術開發部分統一標記為橙色；始終有爭議的部分統一標記為鮮綠。這樣，隨著習慣成為共識，每個成員間的協作會更加默契。
專案後期：
專案後期開發人員自測結束後，需要完成《測試報告》和《測試說明》。《測試報告》記錄測試的點以及修改後結果，《測試說明》裡列出需要內部協助測試的點以及要求。然後由負責人組織美術、程式、策劃、客服、市場方面的人員進行內部測試。大多數公司，會忽略測試過程中人員的組成，經常只是客服或研發部測試就草草了事，實際上乙個專案正式推出是乙個整體行為，在專案沒有出來前，市場部要對其進行宣傳，所以任何環節也不能忽略。每個部門測試之後，會有相關的測試反饋文件發至研發部。由負責人詳細記錄測試結果，並把問題集中後轉給相關的開發人員進行修改。從程式自測、內測的週期為半個月，產品進行封包，封包後將不能進行任何修改。在正式推出前三日後上傳國際網。網路遊戲
專案管理
的核心：
專案管理
的核心是進度管理、分工協作和質量測評三個方面。進度管理是由進度表、進度逐級管理、進度變更規則、進度權責規範這幾部分組成。進度表是控制工期、專案程序狀態、節點完成情況行之有效的辦法。人們制定規則的本身就是要遵循他去指導群體去做將要做的事情，很多遊戲公司也會如實的更新進度表，但是往往很多情況下，根本不按照進度表執行和控制專案，這就使進度表失去了他的意義。進度逐級管理實際上是進度的整個把握詳細分層的過程。研發都是以臨時的專案組為單位的，臨時組中設立美術和程式兩個協調人。負責開發過程中的總設計、協調等工作。每個成員都可以對專案策劃以及開發進行監督、指正，但最終由專案負責人集中管理。專案負責人需要整理修改意見、新的提議以及測試結果。進度是否合理是在初期的進度表確立時，就經過充分
溝通的，但是仍然會有人力不可控的各種情況發生，所以大家應該對進度變更規則有共識。整體進度調整，需要經過臨時組會議，並全體通過才可調整。修改後的進度表，重新傳送全組。個人需要調整，同專案負責人
溝通，沒任何分歧後，修改進度表並做特殊標記。專案負責人需要整理變更進度記錄，其中含變更人、變更原因、變更前後進度等。
在整個專案管理
的過程中，每個成員的權責都需要有明確的劃分，這樣才能各盡所能，各司其職。專案負責人是負責整體的專案策劃、組織實施、監督、協調。如專案在無不抗拒可因素下，沒有按時完成，專案負責人是應負主要責任的。任何環境裡也存在不可抗因素，例如研發人員中途離開、未同其他人
溝通就自行變更專案內容、整個開發組上一級臨時決策等等。
協調人員是負責自己領域內的設計、組織實施、監督和協調。主要責任就是保證其領域內，按時完成。他們直接對負責人負責。其他成員，有監督和建議的權利。責任就是不能因為個人影響進度。其他成員主要是對協調人負責。
質量測評可以是內部的，也可以是工作組或部門間互動性的測評。測評內容包含專案是否有特色、規則是否合理、耐玩性、遊戲平衡性、背景**或音效是否優美、程式上是否可實現、執行文案是否清晰完整等。以下為質量測評參考表。
以上是專案管理
方案。這個方案是流動的，不是僵化的。任何乙個管理方式，都不會是最終版本。
後記：如果你選擇帶
團隊，一定是帶著大家通往凱旋門的，而不是停滯不前或撤退的。所以，你要比成員更加用心的去體會每件事情和每個人的特點。我曾經看過一家大型企業的管理規定，非常有深意。其分為5個部分：「崗位說明」即「你是誰」、「崗位職責」即「你要做什麼？」、「崗位執行標準」即「做到什麼程度為好？」、「崗位協作」即「如何和別人協作」、「獎懲」。其中最有意思的就是「獎懲」這部分，隨時有人在任何的時間，來詢問你關於管理制度中的條款，如果你背不出來，就肯定會被扣除一部分錢做為懲罰。這家大型企業的管理制度，就象一把雙刃寶劍，懸於半空，隨時都有掉落下來，砸在自己頭上的危險。所以每個人都被訓練成了機械工人，按照嚴格規定謹慎的做事情。這樣的管理制度會導致沒有創造力，對遊戲公司並不適用。
團隊需要有凝聚力，這和
團隊負責人以及制度是密不可分的，如果你的個人魅力非常強，而你又考慮到了全部的管理細節，那我相信你的下屬會一定為你和公司竭盡全力。
遊戲專案管理經驗談
手頭目前的專案已經進行了一年4個月了，從專案初期的激情，到專案中期的平淡。如今專案終於處於收尾階段，回頭看整個專案的程序，有喜有憂，最重要的是通過一年多專案的實施發現了自己很多方面能力和經驗的不足。我需要總結前面的教訓和經驗，為以後的工作做更好的鋪墊。首先作為專案的管理者，第一位的是執行力，試想連管...
專案管理經驗分享
我的專案經驗分為專案啟動前，專案開發中，專案維護中三個階段總結。一 專案啟動前 1 需求分析 根據需求給定的需求說明書，去仔細分析理解每乙個需求任務，評估功能需求的可做性 技術可行性，評估功能的實現和耗費的資源 人力和時間 的可支援性。例如 在tulipb b02 專案開發過程中，在使用者遠端許可權...
專案管理經驗借鑑
要馬兒好，又要馬兒不吃草 這句話不知是誰 發明 的 發明這句話的人，想來是專案管理的高手。為什麼？因為專案管理的精義，就是 又要馬兒好，又要馬兒不吃草。乙個成功的專案，通常有三個要素 這三個彼此互斥的要素，就像乙個等邊三角形的三邊一樣，缺了一邊，或任何一邊比其它兩面邊短，我們就不能再稱這個三角形為等...