遊戲專案管理的專業思路探討
專案管理在團隊中的定位是什麼?具體產出什麼價值?PM是監工嗎?…… 在我的從業過程中,無論是PM還是其他職能,都有類似的疑問和困擾。希望能通過此文,大致說清楚思路。
前言:客觀存在的爭議及思考
1.認知撕裂的現狀
PM(專案管理)崗位應該是唯一帶“管理”關鍵字的研發崗位。對於PM崗位,事實上是存在一定爭議的:
- 一方面,組織團隊進行專案攻堅、交付高質量版本,離不開大量的管理排程工作(團隊陷入混亂顯然是更可怕的經歷);
- 另一方面,對於“產能、效率”的無盡追求,也使大部分崗位感受到壓力甚至壓榨感,與進入遊戲行業的初衷“用心創造快樂”似乎有所背離,畢竟如果做遊戲的人自己都不快樂,又怎麼給玩家創造快樂呢?
這兩方面的因素,使大家在對管理的認知上存在撕裂,專案成功是否與團隊的痛苦程度成正比呢?造成痛苦的管理工作及崗位,是否天生是站在團隊的對立面呢(哪怕有很好的個人友誼)?
2.專業上的可行性思考
已經從事研發管理和管理諮詢十多年,做遊戲專案管理6年,前期有2個失敗專案,後續4個連續成功專案。
從做遊戲第一天開始,我就在思考:
- 可行性:我堅信PM職能跟其它職能一樣,一定有相對更正確的方法,是可以同時做到更全面兼顧的改進的。正如程式提升渲染效果,不一定要犧牲效能;美術畫更好看的妹子,不一定要用醜男來襯托一樣。
- 偶然性和必然性:在大家多年的工作經歷中,應該有過個人幹勁十足,團隊協作高效,成績又非常棒的高光時刻。既然這種專案開發的狀態是存在的,那就一定有方法,可以把這種現象從偶現,變成穩定可復現。我認為這就是PM在專業上研究和進步的方向。
幸運的是,從第二個遊戲專案開始(雖然失敗了),我似乎找到了一些規律,且在後續專案中反覆嘗試和驗證,明確穩定的提升了其復現概率。所以可以拿出來跟大家探討一下。
1、現狀及原理分析
1.專業基石:近代管理學
據我觀察,目前我司的遊戲專案管理,主要是基於兩個專業上的基石:
泰勒的科學管理:簡單的說,比如對於搬磚工人,每次搬的重量、距離、頻率,都有一種“最科學”的標準,為所有工作步驟都制定好這種科學標準,即可達到效率最優。
流水線崗位細分:在流水線中,通過崗位細分,可以降低工作複雜度,提升崗位熟練度,帶來效率的提升。比如一個人專門負責做螺絲,一個人專門負責做螺母,效率肯定優於兩個人既做螺絲又做螺母。持續細分即可持續提升效率。
這兩個是近代管理學中最重要的理論基礎,也助力了第二次工業革命的極大成功。
2.遊戲行業的不適症狀
看起來以上的管理邏輯似乎沒什麼問題,但是應用到遊戲行業時,就出現且一直存在兩個不適症狀:
- 標準問題:創意性的工作,真的存在所謂的“科學標準”嗎?比如,遊戲最核心的是好不好玩。好玩該如何定義呢?遊戲行業為這個問題也進行了無數的探討,在最新版的《遊戲設計藝術》中,給出了至少目前為止最權威的答案:“好玩”的標準是無法定義的。
- 效率衡量:創意性工作的效率,又如何確定呢?比如遊戲程式開發,能以程式碼行數,或者最終打包的包體大小,來衡量嗎?100萬行程式碼的遊戲就一定比1萬行的產出高嗎?100G的遊戲就一定比1G的遊戲好嗎?顯然不是的。
無論是遊戲主創對於擺脫束縛創作的訴求,還是友商堅持的“策劃負責制”等,都實際上體現了對“標準化、流水線”的不認同和反抗。
只是因為標準化和流水線是如此的簡明清晰易懂,且也沒有明確的證據可以反駁其不正確,所以遊戲研發一直是夾在兩者之間,製作人在研發過程中不斷選擇和平衡。其難度之大,細節之多,也使整個管理過程的複雜性,隨團隊規模指數級增加。
3.“近代管理學”與“現代管理學”
但是,正如上面說的,這兩個是“近代管理學”的範疇,而不是“現代管理學”。近代管理學是在1910~1920年代成熟的,對應的是第二次工業革命。現代管理學是在1950~1960年成型,且仍然在發展的,對應的是第三次到第四次工業革命。
在現代管理學發展過程中,實際上提出了兩個相關的補充論述:
- 目標管理理論:其基礎是目標理論中的目標設定理論。目標管理強調組織群體共同參與制定具體的可行的能夠客觀衡量的目標。它是在科學管理和行為科學管理理論的基礎上,形成的一套管理制度。與泰勒標準化的核心差異,在於它認為標準不是客觀不變、自上而下的,而是需要群體不斷參與共同制定的。
- 敏捷運動:敏捷運動的核心訴求,是認為,開發效率主要是個體的主觀能動性決定的。與流水線分工的差異是,敏捷支援在一定的分工框架下,個體有更大的選擇和自主權,來決定做自己認為正確的目標和正確的行為。
2、改進思路
1.遊戲研發效率的基礎要素
結合現代管理學的補充論述,我總結的遊戲研發效率的基礎要素是兩個:
- 個人的效率:個人效率需要在合理的分工框架下,激發主觀能動性。主要手段是目標(有價值、可實現、有挑戰)+結果(物質和精神激勵)。
- 兩個崗位間的協作效率:作為協作的最小單位,兩個崗位間的協作流程和標準,不是自上而下的客觀“科學標準”,而是需要雙方參與共同制定的。
其它所有的管理理念、模式、最佳實踐,都是圍繞這兩個關鍵點展開的具體細節,都應視作管理工具而非管理目標。即我們做管理工作,不是工具本身(達成最佳實踐、符合管理模型、達到科學標準),而是為了使個人效率和兩兩之間的協作效率不斷提升,最終導向專案的成功。
2.角色轉變
在這個過程中,PM的角色就從手握標準和績效的“監工”,逐漸轉變為推動目標制定和優化的“教練”。所以,到這裡,我可以首先回答之前的問題:管理工作及崗位,是否天生是站在團隊的對立面呢?
- NO。在遊戲行業,真正的監工應該是自己,對遊戲的熱愛和追求,不斷制定更高的目標,迫使自己進步。而這種進步的樂趣和成就感又最終歸屬於自己。
- PM除了關注客觀的交付產出外,還應該以個體的主觀能動性(個人的積極性和成就感)和團隊的高效協作(團隊積極的氛圍)提升程度,來衡量專案管理工作的產出。
3.職責分工和定義
所以PM工作的價值評判,就與團隊感知統一起來了,即專案管理工作是通過讓團隊變得更好(團隊效率、個人成就感),來讓專案結果變得更好的。
而這對應的就是德魯克在1973年的《管理:使命、責任、實務》中,定義的管理者的三大核心任務之一:使團隊富有效率,讓成員富有成就。大膽的定義一下,遊戲專案研發的管理職責分工如下:
3、從思路到具體行動
有了PM工作的價值評判方向,就進入下一個問題,該怎麼展開做呢?
我認為PM需要建立這三方面的認知:
- 對於管理工具體系的全面認知。以正確使用工具的不同特性,避免自相矛盾和衝突
- 對於管理改進過程的階段性認知。在不同階段,解決主要矛盾問題,弱化次要矛盾。避免全面出擊導致有限的精力投入無限的細節改進。
- 對於自身能力成長的規劃認知。如何才能勝任不同難度的不同業務情境,以及是否需要管理支援,來圓滿完成挑戰任務
因為篇幅有限,這三方面我先論述一下概要,具體案例實踐待後續展開。
1.對管理工具體系的全面認知
首先,是我對近60年主要的管理工具的理解(以下列出的是我學習研究過,大部分在工作中實踐驗證過核心要素的個人體會。因個人經歷有限,可能有缺漏和偏差)
總體來說,我認為現代管理學工具,主要受兩個人物的理論體系影響,德魯克(現代管理學之父),湯姆彼得斯(後現代企業之父)。在他們的理念影響下,衍生出較多層級的工具。同時,與原有的管理工具,是傳承和發揚的關係,而不是否定和對立的關係。
即目標管理雖然重視參與制定標準,但是並不是回到經驗管理來替代標準化管理;敏捷開發也不是否定分工和流程,而是認為需要參與者有合理的自主選擇權,來提升參與感和認同感。
我覺得PM如果體驗和經歷過其中三四種管理模式,應該就可以體會到其中的相互聯絡。千萬不要把不同的管理工具對立起來,就像常見的梗“PHP才是世界上最好的程式語言”,“敏捷開發是最先進的管理模式”這類的爭論也是完全沒有意義的。
2.對管理改進過程的階段性認知
我認為團隊協作,在成長過程中會面臨不同的瓶頸。
- 首先是效率瓶頸,因為團隊最開始一定面臨產能和交付問題。所以需要使用如精益、6sigma等工具來完善團隊的效率產能建設。
- 其次是需求變化導致的質量瓶頸。因為遊戲研發會面臨很多需求和品質迭代。當迭代發生時,往往版本質量會受到較大沖擊。此時需要使用持續整合、持續交付、自動化測試等工具來確保質量穩定。
- 然後當團隊已經能掌控需求變化的協作時,如果想要進一步加強響應變化的能力,就會面臨資訊和溝通瓶頸。此時需要使用精益敏捷開發、特性模式來優化團隊管理結構和溝通模式。
大致的演進過程如下:
另外,在改進階段的演進過程中,團隊會逐步從初級到高階,發展以下能力。這個能力模型是仿照馬斯洛的需求層次來分解的,其上下級關係與馬斯洛需求層次的關係類似,即應該始終確保低階能力的完善,再追求高階能力。
- 初級能力 - 協同:團隊按一定版本節奏能協同工作
- 初級能力 - 有效落地:端到端有效產出(比如從策劃的設計,到產出的內容驗收)
- 中級能力 - 品質保障:確保實時可用性(抓質量),品質穩定可靠
- 中級能力 - 閉環:設計閉環、製作閉環、質量閉環,推動持續改進,並通過自動化工具鞏固流程
- 高階能力 - 組織改進:各職能對於改善自己的組織水平有明確訴求,持續改進;
- 高階能力 - 方法論沉澱:各方面的方法論沉澱,比如設計方法論,創新方法論,質量方法論等
3.對於自身能力成長的規劃認知
對於PM個人能力成長,這塊其實有很多內容和文章了,專業維度也很多,我就不展開說太多。
不過我覺得PM屬於P族通道,應該在崗位定位和發展目標上可以對齊運營和策劃崗位,大致思路如下:
4.PM需要交付的價值
在掌握以上認知後,規劃PM自己的目標就相對比較容易了。因為遊戲行業尤其是手遊行業的快節奏,從業人員比較年輕,團隊靠自然成長到非常高的成熟度水平,是非常困難和偶然的。
PM的最重要價值,就是加速團隊的成熟度和能力提升。比如,如何建設團隊協作能力,來達到行業頂級製作團隊的水平。相信管理水平,與工程技術、專業經驗是一樣重要的。甚至在當前階段,我覺得管理水平是更明顯的短板,也更難建設,因為管理是抄不來的,優秀團隊也無法簡單複製。
來源:騰訊大講堂
原文:https://mp.weixin.qq.com/s/44ukNc7h786n9TEbzYhWYA
相關文章
- 對軟體專案管理的探討(1)專案管理
- 對軟體專案管理的探討(2)專案管理
- 對軟體專案管理的探討 (轉)專案管理
- 對軟體專案管理的探討(轉)專案管理
- 科研專案管理方法探討(轉)專案管理
- 對軟體專案管理的探討(1)(轉)專案管理
- 對軟體專案管理的探討(2)(轉)專案管理
- SAP MM 實施專案裡Open PO 遷移思路探討
- 六西格瑪管理在北京IT專案中的應用探討
- 專案管理理論中關於軟體專案外包採購管理的探討(轉)專案管理
- 專案團隊的信任問題探討
- 探討基於資訊系統的專案型生產管理
- 【穩定性】從專案風險管理角度探討系統穩定性
- 專案團隊的信任問題探討(轉)
- 專案管理經驗談——來自專案管理群的討論專案管理
- 專案經理責、權、利探討(轉)
- 工程專案成本控制若干方法探討(轉)
- 國內外工程專案管理現狀比較與探討(轉)專案管理
- 專案管理經驗談——來自專案管理群的討論薦專案管理
- 《軟體專案管理》的設計思路專案管理
- 組織級專案管理例項分享——來自專案管理群的討論專案管理
- 對日軟體外包專案問題探討(轉)
- 探祕技術專案管理(三)(轉)專案管理
- 探祕技術專案管理(二)(轉)專案管理
- 探祕技術專案管理(一)(轉)專案管理
- 【原創】組織專案管理討論專案管理
- 企業管理模式:從專案管理到企業專案管理(轉)模式專案管理
- [討論]IT專案經理需要很專業的IT知識嗎
- [專案管理]弱勢專案管理與技術牛人的對抗問題延伸討論專案管理
- 勘察設計單位引入現代專案管理有關問題的探討1(轉)專案管理
- 勘察設計單位引入現代專案管理有關問題的探討2(轉)專案管理
- 勘察設計單位引入現代專案管理有關問題的探討3(轉)專案管理
- 技術專家or專案專家-專案管理MSN群線上討論(2009.6.23)專案管理
- 專案管理最佳實踐,企業如何進行有效的專案管理專案管理
- ERP專案實施風險分析與控制方法探討(轉)
- 知識的分享和管理——來自專案管理群的討論專案管理
- 從源頭探討 GCN 的行文思路GC
- 企業的專案化管理(轉)