1、專案的過程管理

    專案管理工作是一個非常幸苦的工作，一個專案一般最忙的是專案經理，而且對人的綜合能力要強很高。不光在管理方面有知識與經驗要求，而且一個好的專案管理一般都需要懂自己所負責的專案每一個環節的實現細節，甚至最好你能精通某一環節（比如你是程式轉的專案經理熟悉程式開發環節），這樣在推動專案的時候與執行團隊能有共同語言。

    專案經理一天的日常工作內容，主要是圍繞如何讓自己的專案有效向前推動開展的，做的所有事，開的所有會，最終本質都是這個目的。

2、專案過程管理目的

    為了有效推動專案的正常開展，對專案經理來說，主要力求做到兩個方面：“可控”與“透明”

2.1、可控度

    還記得“計劃篇”中說的“管理無定法”嗎，這裡也是一樣的。要做到可控，並沒有一個標準的方法，只有專案經理覺得當前對整個進度是否能可控。如果覺得不可控就需要加強管理，如果覺得“盡在掌控”就可以保持當前力度或適當減少管理力度。

    具體使用什麼樣的管理方法來督促專案、來達到可控需要根據不同專案、不同進度、不同環境來選擇。如果管理粒度過粗，就會不透明、可控性差，導致容易失控。如果過細，管理成本就會直線高、影響工作效率。

2.2、透明度

    軟體專案開發過程中，人是主要過程管理物件。遊戲研發中經常會遇到需要預研的功能，或者底層的（不可見）的功能。專案經理遇到這種問題，沒做好的話會導致，專案經理無法信任、控制專案進度，這個時候需要通過某些手段把這些黑盒透明化，比如拆解出幾個小步驟，讓這件事的過程可以通過這些步驟來體現出進度

    比如一個某一個美術資源的產出，如果你對美術資源不關心的話，只要結果管理就可以了。但你發現這件事佔用時間非常長，而且風險很高，管理結果完全不可控，你可以把按步驟拆解。比如畫一個這樣的圖，把每個環節可視化出來。

    當然這只是一個舉例，總結來說“透明化”就是一個拆解的過程，但要講究一個度，因為你的精力有限。

3、日常推進

    日常推進進度佔據專案管理80%工作內容。

3.1、溝通時間

    每天專案經理需要把專案進度做一次跟蹤。一般可以跟著某一團隊開早會，可以瞭解這一團隊每個人的進度。比如跟著客戶端團隊開會，如果把客戶端成員每個人的工作進度都瞭解到了，那會後就可以只去找伺服器和其他團隊瞭解了。

    程式設計師、美術做執行的人一般不希望在工作中經常被打斷，所以一般固定一個時間去了解進度，例如我們都選早上的時間段。

3.2、溝通方式

    一定要面對面溝通，儘量不要rtx或郵件，除非對方是外包公司或異地團隊。這樣可以大大減少溝通時間，提升溝通效率。

3.3、溝通物件

    這是最重要的一個需要考慮的因素，你可以有這幾個選擇

    和任務本人溝通，這是最常用的方式，也是管理粒度最細的方式，優點是你能最大限度的瞭解真實情況，缺點是通常一個任務有許多人負責，你要和每個人溝通來了解實際情況。

    也可以選擇和他的組長來溝通進度，對於一些小組，組長能力強，而且你夠信任，你可以選用這種方式，比如我們UI組，UI方面的進度一般都只和他對。

    和負責這個功能的策劃來溝通，這個做法表面上是讓策劃瞭解自己負責功能的進度，其實好處是也可以促進他們瞭解自己負責的功能的實現情況，因為在對進度的時候會要了解大量的實現細節，這對專案是非常有好處的。

3.4、關鍵事件

    在跟進的時候經常會有些突發任務、重要任務或關鍵節點，這裡我建議找個白板，做“管理看板”，放在專案組附近，讓大家每天都會看到，開早會的時候可以看到，無時不刻不在提醒大家。而專案經理也需要單獨對這些事情進行跟蹤。注意，這些事情列在白板上一定要列上負責人和完成時間。

對與專案中一些非常關鍵的任務或問題，除了剛才說的在一個看板上列出，專案經理要專項對待，在任務優先順序中排出一個特殊的優先順序。對於形成的解決方案，需要做記錄，因為選擇這個解決方案可能關係到專案的命運。每週在週報中對這些重要的事情做專門闡述。

3.5、需求說明會

    這個是一個任務從設計到開發中間的一個關鍵里程碑，專案經理一定要拉上這個任務的干係人都參與，其實在開這個會之前就應該拉好溝通的群，來討論一些需求細節。注意這裡的干係人一定包括“UI”、“測試”甚至還有“運營”，因為他們往往能提出很多需求設計上的缺陷。

3.6、設計討論會

    在一些複雜功能程式拿到需求後，會要求開設計討論會，主要是針對需求的實現方案。這裡策劃是必須要出現的，因為往往有些很難實現的功能，也許策劃改改需求，就可以繞過這個設計難點，當然這個需要雙發充分的討論。這對整個專案是非常有好處的。專案經理應該鼓勵大家開這個類的會。

3.7、需求邊界的動態調整

    一般從需求說明會開始、UI設計、程式實現一直到測試，都有可能出現意外情況，比如發現還需要開發一個衍生系統，或者版本時間有限部分功能無法在版本內完成，又或者無意遺漏的一些實現細節。這些都會導致邊界的調整，甚至產生新的需求。對於這問題，專案經理應該要及時做好版本計劃的維護、調整以確保版本計劃上是真實情況的反映。另外還要記錄下來，在版本總結的時候，當成經驗分享給大家。

4、外包管理

    關於外包管理是專案管理的一個難點，因為很多外包商的進度都非常難把控。為了儘量避免延期，可以在合同上約定清楚懲罰措施、在任務開始前讓對方儘量早的提交製作計劃。專案經理需要設計一個專門的表格來管理他們的進度，因為不可控因數太多了，這裡強烈建議每天和外包對進度，而且要預留好計劃外時間，儘量不能讓外包負責關鍵路徑的工作。

    外包的質量把控需要“業務對接負責人”專案經理只能管進度，計劃中也要預留出質量不好的返工時間，經驗來看是3/1的製作時間，如果沒用到就是賺到了。

    外包商平時就要多積累，不要只找需要的數量，永遠要有一個備用的，不行就換。因為外包質量一般都是逐步下降的。

    外包管理表格注意包括：各個節點（里程碑）的時間，一定要做到透明與清晰。

5、質量管理

    質量管理是保證產品最終品質的重要組成部分，雖然一般有質量經理，但對專案經理來說也是重點關注的部分。

5.1、測試用例

    一般測試團隊在需求說明會後就可以開發測試用例了。在測試用例編寫完，不管是質量經理、還是策劃、還是交叉檢查，建議要有一個測試用例評審的環節，這樣可以儘量保證測試用例的全面性。

    另外對於用例管理，這裡我強烈建議使用Excel表格化、模組化，這樣的測試用例未來複用性很好，比如可以可以重新組合成一個迴歸測試流程。一般測試用例包括：前置條件、操作步驟、預期結果，甚至也可以有衍生的bug編號，這些你都可以根據你的管理實際情況進行修改

5.2、問題處理流程

    一般團隊都會有工單系統，比如禪道(bugfree)、Jira、QC、TAPD等等反正你得有一個，在上面跑bug跟蹤流程。專案經理需要每週對專案的質量情況資料做分析，比如bug產生數、解決數，每個模組的質量情況，bug最多的模組，問題最多的人等等

5.3、開發過程質量管理

    對於軟體開發一般除了一般bug外有兩種需要特別關注的，

5.3.1、低階問題

    說白了一看就知道程式設計師提交後自己都沒執行一下，比如模組都打不開、按鈕無法點，告訴測試可以測了。對於這種問題要單獨列出來，記錄下來在例會進行反饋。這樣才能讓程式設計師養成良好的自測習慣。

5.3.2、阻塞性問題

5.4、遊戲產品質量的關鍵點

    除了一般的功能測試、迴歸測試外，產品品質還需要其他的測試來保證

5.4.1、客戶端效能測試

    目的是測試客戶端的“記憶體洩漏”，“快速點選產生的併發問題”。一般用暴力點選測試法、反覆迴圈操作測試法，常用工具是“按鍵精靈”。比如不斷進出房間、不斷開啟關閉某個功能、不斷戰鬥，觀察連續操作幾小時後，記憶體情況，功能情況等等

5.4.2、客戶端弱網測試

    手機遊戲這個是重點，目的是測試客戶端在網路環境差，甚至短暫斷網的情況下，斷線重連這個功能情況。這裡首先需要策劃、技術出弱網應對設計方案，一般包括：地圖延遲同步策略、超時策略等，注意這裡不是一個系統，是要列出所有系統的策略，比如戰鬥中多長時間伺服器判斷客戶端斷開，伺服器是否給予自動託管，自動託管中客戶端重連是否會拉回戰鬥，如果託管超過多長時間算真正退出，或者在判斷戰鬥結束時，恰好客戶端斷開會怎麼樣......。這項測試弱網策略是最重要的。

5.4.3、伺服器協議測試

    目的是為了做伺服器的漏洞測試。比如購買數量，通過改協議發一個整數最大值或最小值（負數）過去，又或者重複傳送一些協議，看伺服器是否處理。一般都能發現非常多的問題，這個測試對伺服器品質的保證非常重要，而且一般也要求對每個功能寫測試用例，和一般功能的測試用例放在一起用型別分開就好。

5.4.4、伺服器效能測試

    目的是為了測試服務的效能，這個測試方法很多，一般包括併發測試、高負載測試、疲勞測試。另外就是建議做個過載實驗，找到伺服器的瓶頸，和極限峰值，方便運維做負載預警系統。做這個測試前，先讓技術給一個性能基線（併發人數等。。。），按這個基線進行測試，這個測試是必須要過關的。

    這個測試與協議測試一樣建議技術他們提供測試工具，可以通過配置方式來靈活實現測試場景。

5.4.5、破壞性測試與故障演練

    目的是為了驗證伺服器在部分故障情況的表現。現在的伺服器架構一般不會採用單服制來設計，一般會多個伺服器甚至微服化，這樣需要測試下看看某些伺服器關閉後，對整個遊戲的影響，以及應對策略。比如正常起服後，聊天服關閉，是否只是聊天不了了，客戶端會不會因為連不上聊天服而發生什麼狀況，一般我們預期是隻有對應的功能無法使用，而不能影響其他系統的正常使用，而且在這種極限情況下，客戶端的體驗需要設計，不要出現“不停的彈出報錯對話方塊”等等。又比如在10臺戰鬥服壞了一臺，之前他上面的負載的玩家是否會自動分配到其他服上去，客戶端的表現又是什麼樣的。還有看看伺服器在這種情況下重啟是否能恢復服務，而不是再也回不來了。只有考慮了這些，設計了這些，做了這個測試才能保證伺服器叢集是一個健壯的柔性可用的伺服器叢集

5.5.6、資料測試

    目的是為了測試資料是否錯誤，這個測試不光是研發階段要做，產品上線後，DBA也需要定期對線上資料進行檢查。這個測試最重要的環節是，設計什麼樣的日誌資料。比如設計所有的玩家購買行為日誌資料，玩家等級升級日誌資料，玩家揹包日誌資料等等..... 。通常會要求幾個日誌之間是要有一定的邏輯關係的，比如購買日誌的購買行為，一般會觸發揹包新增日誌。這樣做最大的好處是防止玩家因為某些bug刷東西，通過這些資料分析，可以很快發現玩家資料的異常情況。

    測試在研發階段一定要保證這些日誌的準確性，關於資料日誌不要嫌繁瑣，遇到事了你會慶幸有這些日誌，因為就算沒有刷東西的情況，老闆也會找你要各種資料分析的，因為這是遊戲產品的一個特點。

6、臨變管理

    關於變更是專案管理中最常見的一個事了，關鍵看你的管理粒度，對與不同的變更採用不同的應對策略。一般的變更可以管到天、周(幾天)、節點3類。一般嚴重的會影響到節點的比如里程碑或版本完成的為最高階，需要通報和記錄，最細的天級一般是這個團隊經常出問題，可以採用這種嚴格的管理方式，直到情況好轉。為什麼不一直採用最細的管理粒度呢？還是那句話，你的管理重心和精力是有限的。一般小的臨變還有很多變通的方式來做，比如用工單系統，在裡面加一個臨變需求的型別，這樣可以保證這個事會有效執行，又可以簡單的統計到臨變資料

7、專案日誌

    專案日誌是記錄專案過程的一個工具，當專案發生一些事件的時候可以記錄一下，因為後面會有各種人找你要時間點，你可以直接查這個日誌可以輕鬆應對。

7.1、功勞簿與過失簿

    在專案開發過程中難免會有人犯錯，難免會有人失誤，需要把這些問題記錄下來，作為一個重要的經驗記錄下來。

    當然對於一些有突出貢獻的同學，對等的也應該記錄在功勞簿裡。方便在適當的時候可以激勵下，或者作為KPI的依據

8、人的管理

    專案管理也是一種管理，管理不光是管事，更重要的是管人。管理者在管人這個方面心態一定要是：你是一個服務者，你是來為大家提供服務的，你是來為大家解決問題的。這篇裡面講的各種管理方法、經驗都只是工具，如果人心齊了你的管理會很輕鬆，可以減少很多管理成本。所有重要的與他們的相處，如果團隊大而你又不能顧及到所有人，這裡建議你重點關注意見領袖，大部分的時候他們是骨幹。而管人的具體方法得看你的情商了，訣竅還是文章開頭所提的，你和他們的共同語言，如果你連和他們溝通的基礎都沒有，就談不上什麼互相理解了