騰訊專家級製作人：10年5款遊戲，專案從不延期，我怎麼做專案管理？

本期《論道》欄目，專家制作人任志國將分享從業10多年積累沉澱的專案管理方法論，期望幫大家保證專案質量的同時，提升效率，避免加班。

2009年，任志國剛剛離開盛大，入職騰訊，擔任《軒轅傳奇》的專案經理（Project Manager，簡稱PM）。當時他面對的是一個焦頭爛額的局面：專案做了三四年仍未上線，一週才能出一個版本，反饋很不及時，狀況十分凌亂。

但上任之後，任志國用3個月樹立了一套專案管理的流程，解決了效率問題，也獲得了團隊的信任。如今10年過去，他已經成為了一名專家級的製作人，帶領團隊研發了5款遊戲，而且每個專案都沒有delay的情況發生。他也在騰訊內部多次分享過專案管理的心得。

近日，由遊戲葡萄擔任獨家合作媒體，騰訊遊戲學院製作的《論道》欄目邀請到了任志國，也請他講述了一些專案管理的方法。在Q看來，其中很多方法都可以應用到每個崗位的日常工作當中，提升效率，避免加班。

你可以通過下方的精選視訊，或者後面的採訪文字摘錄來了解任志國的分享。




專案從不delay的技巧：如何切分里程碑和關鍵節點？

Q：在遊戲行業裡，PM的存在感似乎一直不高。你覺得這個崗位的核心難點是什麼？

任志國：很多PM沒有實權。他們沒辦法把控專案方向，沒有人員管理的實權，也沒辦法做考核。所以很多PM就是老闆說要做這些事情，那我就幫老闆排計劃；今天出了風險，我就彙報給老闆，最後做成了一個“祕書”。

有些PM一聽主策劃要排計劃，就去和策劃談：“你今晚能不能加個班？”結果策劃常常說：“對不起，我今晚有事。”因為他不服你，覺得你的安排不合理。

那PM怎麼突破這一點？你要培養足夠的影響力，熟悉業務，在推進計劃時提出有建設性的意見。這樣雖然別人不是你的下屬，但他們認為你對產品有價值，願意服你，慢慢你就能成為核心。

Q：你剛來騰訊的時候，用了多久樹立自己的影響力？

任志國：大概3個月。當時整個團隊有140多個人，專案做了3，4年還沒上線，我過來之後發現有兩個問題：

1.產品的目標和方向不夠清晰，大家不知道這個階段做什麼事情，要達到什麼標準；

2.產品的反饋節奏太慢，這周研發的東西，要到週五才能看到反饋，然後才能調優。

這兩個問題怎麼解決？我的方法是抓一頭，抓一尾。

什麼是抓一頭？就是先制定計劃，找製作人、主策劃、主程共同討論不同階段的目標，把目標細化到每一天，每個人都做什麼，然後每一天都回顧昨天做的事情，對計劃做相應的變更和調整。




什麼是抓一尾？就是抓版本。當時我提出要以版本為綱，每天構築一個版本，當天就反饋當天做的事情。

這麼做了幾個月，大家明顯感受到了團隊的進步。


Q：每天出一個版本？剛開始這個難度會不會太大了。

任志國：要用流程和工具解決這個問題。最開始大家構建版本的方法很原始，一款遊戲分為客戶端、伺服器、美術、策劃、測試等小組，每個組都有一個負責人，這些負責人要把所有資源統一，做出一個版本。後來我們做了一個工具，要求大家每個人都把工作直接提交上去。

現在這個流程可能很常見了，但當時大家有很多反對的意見，說我一天要做的事情這麼多，最後還要做版本？太浪費時間了。

但最後大家發現，這個方法的價效比遠大於消耗在流程上的時間。因為每個人每天都能知道今天做的事情合不合理，這就相當於迭代速度比之前快了5倍。

Q：你會怎麼梳理一個專案的里程碑？

任志國：很多人做專案管理會採用順序法。比如一個專案要做12個月，那就分成4個里程碑節點，3個月，3個月……一直到專案完成。

這裡面有一個問題：如果第一個里程碑做了3個月，有些工作沒有完成，拖到了下一個里程碑；下一個里程碑又出現了新的需求，那做到第四個里程碑，大家發現做不完，就只剩下一條路：專案delay。所以業內普遍認為，一個原計劃用1年做完的專案，做1年半是非常正常的。


但我喜歡採用逆序法，以終為始，優先考慮最後的環節。比如商業化測試至少要做21天，那這個版本的目標要達到什麼程度？要把所有功能做完，並且準備至少體驗30天的內容……就這樣一步步推算，推出擁有基礎玩法的版本，只有核心玩法的版本，Demo等等，列出每個階段相應的目標。

這樣思考之後，每個階段要把事情做到什麼程度，才能做下一個階段就非常清晰了。這樣每個階段你都會向著下一個目標來做事，最終專案就基本不會delay。

Q：你做的專案都沒有delay？

任志國：在定好宣傳期的前提下，我們都是準時上線，甚至可以精確到天。我做專案比較喜歡前緊後鬆。

Q：前緊後鬆？

任志國：很多人做專案是前鬆後緊。比如專案開始時，前3天的計劃是每個職業都做一個技能出來，驗證核心玩法。但很多人覺得時間還長：這個專案要做2年呢，這幾天做不出來沒關係，我們先早點兒回家，出去玩一玩。聽上去也有道理，但你這就浪費了好幾天的時間。

而我做專案要求第一天大家就立刻進入狀態，如果前3天計劃要把技能做出來，那大家寧可加班，也要把這件事情做完。因為如果第一天的工作沒做完，就會影響最後一天的工作。沒有這個信念，你的專案一定會delay。


Q：做PM最常見的風險是什麼？

任志國：最常見的風險是溝通時的資訊不對稱。比如策劃把需求交給程式設計師，等到需求做完策劃一看，這個東西的質量和方向和自己想的都不一樣，那怎麼辦？再NB的人也沒辦法，只能再給你10天時間把事情做完。

PM不只要保證事情能按時做完，還要保證事情能按時按需地做完。所以針對這個風險，你就要確定關鍵節點，比如第3天，第7天，第12天，第15天，第18天……每個階段都檢查一下結果。

Q：每個關鍵節點的切分邏輯和驗收標準是什麼？

任志國：這個節點不是按3-5天隨便分出來的，而是每個節點都要保證可量化，視覺化。我們的標準不是指“寫1200行程式碼”，“把圖畫了70%”，而是要拿著你的手機，讓我確實看到這個場景，體驗到這個玩法。

比如第3天我要看到可實現的功能；第7天我要看到一個臨時的，可以沒有UI，互動非常醜陋的介面；第12天我要在客戶端伺服器裡看一下表現效果，同時讓你對細節問題做微調；第18天修完所有bug，把穩定性調好；第20天對外發布。

在這個過程中，節點的時間也可能會隨時改變。比如主程說這個需求不用3天，2天就做好了；或者對技術難度預估不足，需要4天才能完成，那還要對其他節點進行調整。


Q：在專案上線之後，你們會怎麼做版本管理？

任志國：我們團隊是每45天更新一個大版本。版本的大方向由製作人、主策劃提出，之後PM再做細化。在這45天裡，一般會拿30天用來開發，10天用來測試和穩定調優，提前5天拿1-2臺伺服器做灰度測試，最後全服更新。

我們的版本線一般會分為4條：

1.釋出線：針對運營產品的緊急問題的修復，穩定版本分支；

2.運營線：針對運營產品的重要不緊急問題的修復，穩定版本分支；

3.開發線：針對長期特性開發的版本線，研發重要不緊急問題的修復，不穩定版本分支；

4.特性分支：多條，不穩定版本分支。



Q：在研發過程中，發現中途計劃要delay，需要更長時間完成一項工作怎麼辦？

任志國：delay的問題很常見。調整優先順序，把一些特性拆分到之後的版本中就好了。因為不是你做的功能越多產品就越好，PM也要幫助專案做減法。

比如做《軒轅傳奇》手遊的時候，我們想保證策略足夠豐富，於是決定把端遊的17-20個技能都復刻進去，但這至少要做3-5個月。

後來我們發現手遊螢幕就這麼小，其實一個職業做8個技能就足夠了，這樣還可以把每個職業都做得很精緻。如果需要新的玩法套路，那我們可以再推出新的職業。最後產品上線效果很好。

所以做專案管理要不斷調整計劃，試著尋找更好的目標。比如你的目標不是“把端遊的技能復刻到手遊裡”，而是“保證玩家的爽快和策略性”。

團隊溝通的技巧：勤開會，提前溝通

Q：專案組內部的溝通方式一般是怎麼樣的？

任志國：每週一會開一次核心團隊的週會，這個會大概持續1個小時，主策、主程、主美、主測試等等都會參加，一起同步這一週的工作內容和大概目標。

然後每週三，也就是每週的中間，我們會把策劃拉進來開一個同步溝通會，大家一起同步一下這周自己小組的情況。

在週五下午，我們還會開一個版本串聯會。這個會所有策劃都會參加，大概持續2-3個小時，大家整體review一遍這周做的新特性、新內容，再決定未來要對哪些內容進行優化，優化的排期是怎麼樣的——一般大家會列出50-100條優化意見。

最後我們還有很多和特性小組開的小會，用來拆解計劃，討論技術問題，資訊溝通，解決臨時問題等等，這種會每天都可能會開，持續時間一般在半小時到1小時左右。


Q：這些會議PM都要參加？

任志國：其他崗位的同學也會嘗試自己解決問題。如果涉及到人力資源的分配，那PM就要參與。

每個崗位都有自己的本位思想，比如主策想把功能做好，主程更在意效能和效果，而PM可以用更中立，更全域性的角度看問題。所以遇到緊急事件，一般也是PM牽頭，拉著大家去大會議室開會。


Q：團隊的組織架構大概是怎麼樣的？是分成不同的職能部門，還是分成不同的業務模組？

任志國：團隊還是會分為策劃組，客戶端組，伺服器組，美術組和測試組。但針對不同的特性和功能，我們也會分出很多有策劃，有程式，有美術的虛擬組，由策劃負責全程跟進——Ta就起到了小PM的作用。這樣開小會的時候，PM只要找到特定虛擬組的策劃就可以了。

Q：PM應該會遇到很多協調和溝通的問題吧。

任志國：對，這份工作對情商的要求很高，有時候你要強硬，有時候你要懂得認錯，有的時候你還要和一和稀泥。

比如一個需求可以客戶端做，也可以伺服器做，那到底讓誰來做呢？大家都不知道，那你就需要強硬一點兒，比如直接拍板，拜託客戶端來負責。

如果最後大家發現其實伺服器做的價效比更高，那你就去請客戶端主程吃個飯，賠禮道歉，說上次處理得有問題，這樣問題反而變成了增進感情的機會。雖然說對事不對人，但事還是人做的。很多事情如果你們關係好，那人家還是會願意加個班，幫你搞定。

PM還會遭遇很多溝通的僵局。比如程式跟你說，現在策劃案沒寫好，這個事情我不能做，不然做了容易返工；但策劃跟你說，今天我策劃案真的出不來，週五才能給你。

這個時候怎麼辦？你其實可以和一下稀泥，跟策劃說，你可以不寫策劃案，但先寫一個簡單的概要，跟程式講講核心玩法的體驗，週五再補一個完整的策劃案給程式。

Q：你覺得跨部門溝通時最常見的問題是什麼？該怎麼解決？

任志國：最常見的是雙方目標不一致。比如我覺得這件事很急，希望你趕快幫忙，但你也有自己的分工和規劃，沒辦法那麼快地完成任務。

這個問題怎麼解決？一定要提前溝通，這樣其他部門才有足夠的時間調配資源。有90%的緊急需求其實本來都不緊急，只是拖到了最後一刻，才變成了緊急的事情。至於剩下的10%，如果你們的關係比較好，那對方可能也願意幫一次忙。

做版本規劃，我們一般會提前2個月做計劃；做具體的內容細節，我們一般會提前1周做計劃；如果要開會，我們要求至少提前24小時和大家溝通。所有事情都提前安排，才不會出現很多臨時的情況。

Q：舉個提前溝通的例子？

任志國：比如在梳理里程碑節點的時候，一般會規劃團隊要在30天內做多少系統和特性，其中幾個系統需要策劃出策劃案。但如果策劃案出來，主美說不可行，主程說技術搞不定，那工作肯定就做不完了。

一些PM可能會等著主策自己寫，但我們一般會先找到主策，說能不能明天或後天先把策劃案過一遍——主策不可能當天給你策劃案，因為Ta也要思考。

這個時候主策可能說，這個方案沒那麼快，我週五才能寫出來。那我就會問，你能不能分兩期？這兩天先對一下大概思路，下週再確認更多的細節。所以在寫一些策劃案前，我們甚至會拉主策先和美術、程式預溝通2次，正式溝通1次，最後再把策劃案定下來。

Q：如果團隊中某個人突然出了問題，比如突然請假怎麼辦？

任志國：要提前做好人員培養，保證另外有1-2個人也熟悉這份工作，避免“這份工作只能Ta來”的情況。

另外我們會讓工具更加完善，減少口口相傳的經驗，減少對人的依賴。這樣Ta今天請假，另外一個人也可以幫忙做Ta的工作，只是做的時間可能會長一些。

超過30人的團隊，就應該配備一個專職的PM

Q：你們現在面試或者招聘PM時，最看重的特質是什麼？

任志國：如果是招聘比較高階的PM，我會希望對方有成熟的大型專案的經驗，然後如果是程式出身，或者邏輯思維能力比較強也會加分。另外PM的情商很重要，因為這個崗位與人互動特別多。

Q：招人之後你會怎麼培養？

任志國：先以導師的形式帶Ta三個月，讓Ta熟悉你的工作方式。這個里程碑階段我把大方向告訴你，然後具體讓你來細化執行。過了1周我發現你犯了一些問題，比如這個技術問題應該及時處理，不應該拖到下週；這個問題應該找主程、主策討論清楚；這個跨部門的溝通不應該拖等等。

用這種方式培養，經歷過一個2-3個月的里程碑階段後，新人往往會成長得很快。如果事情做得足夠好，那我就可以不斷放手，讓Ta去承擔更多的事情。

Q：新人PM最容易犯的錯誤是什麼？

任志國：過於關注進度，不關注質量。PM的工作是要保質保量，製作人、主策覺得這個事情要延後一天，那他們為什麼會這麼想？這個想法合理麼？會不會沒考慮到一些風險？

比如主策可能在外網反饋之後發現了很多問題，決定大改一通，提出了很多點子和想法。但站在PM的角度來看，這些想法根本做不完，或者做完品質也不高。那你就要提醒主策，我們要不要分階段地實現這些功能？有些地方如果要調整，就和剛開始的計劃產生了偏差，是不是要和大家同步？

這就是上下級溝通的重要性，你要及時向上級反饋風險，而不是上級說什麼，你都說好的，我馬上把這個計劃安排下去。

Q：你們會怎麼平衡時間進度和質量打磨？

任志國：把一個東西做好肯定需要足夠的時間，在安排計劃的時候，如果開發要用4周，那我們至少要留2周時間來打磨。甚至有的時候不是4+2，而是3+3——用3周做完功能之後，再用3周打磨細節。

當然，產品的打磨是無止境的。如果這個功能特別核心，大家表示加了50%的時間還不夠，這時就要交給主策、製作人判斷，如果值得，那下一個階段就要繼續打磨。

Q：那PM也要定一個新的計劃？

任志國：你是為專案服務的，而不是為計劃服務的。總不能說我是PM，你們不能改我的計劃吧。遊戲要適應市場的變化，使用者的需求。假設上一個階段做的東西玩家發現真的不好，那就一定要改。

Q：PM存在專家路線和管理路線麼？是不是好的PM都會成為製作人？

任志國：製作人這條路肯定可以走通，我自己就是一個例子。因為你每天都在把控整個專案，比較有全域性觀，只要你再多花心思關注產品，那3-5年後你是可以成為製作人的。專家路線也可以走得通，比如你可以帶一個小型PM團隊，專門幫助製作人把產品做成功。

Q：不同人數的專案，對PM的需求可能是怎麼樣的？

任志國：如果團隊規模在30人以下，製作人和主策劃往往可以兼顧。但如果團隊超過30人，那就要考慮匹配1個專職的PM了，如果有100多人的話可以匹配3-4個。

Q：同一個專案，有PM和沒PM的差距有多大？

任志國：我覺得很大，甚至一倍都有可能。

Q：專案管理是不是一份非常瑣碎，或者非常辛苦的工作？比如必須要留到最後做驗收。

任志國：一些驗收工作往往會由策劃牽頭來做，如果大家都養成了提前溝通的習慣，也很少會出現特別緊急的任務。所以我們團隊的加班情況都不嚴重，很少會有22點之後下班的情況。

你可能會問我，一個遊戲至少要做300個特性，怎麼可能忙的完？但又不是讓你每天都要全部跟進這300個特性，它們是錯開的。只要把工作理順，每天你要處理、溝通的事情只有7-8件，其實並不多。



來源：騰訊遊戲學院
原地址：https://mp.weixin.qq.com/s/n5N3uOcy1mUkkVS2h7kvNA