項目管理是個麻煩事兒，我目前在團隊中主要擔任PM一職，負責項目管理方面工作。通過本次BOOOM比賽對項目管理又有了新的認知。
實際上項目管理是個麻煩活兒，團隊中的PM也是幾經週轉最終落到我的頭上。首先作為PM，最先要保證的是作品按時按量完成，在管理項目的時候，你會跟團隊成員有許多博弈在裡面，當然，這裡的博弈是中性的。比如策劃期望自己的想法得到貫徹，於是瘋狂的加功能或者改功能，而程序期望自己的代碼健康又穩定，花的時間也更多，美術也同理。你需要保證儘量滿足每個成員的需求，同時又能夠讓項目正常進行，如果某個改動會影響工期，那麼你應該慎重考慮，必要時一定要堅決地堅持自己的觀點，說服團隊成員將風險項放棄。你的職責是保證作品質量和按時完成，其他人的意見如果與你的核心職責有衝突，你應該堅持自己的立場。假設決議通過而導致項目延期，責任應當在你。
在堅守自己的首要職責外，你需要採取的態度應該是保守的(答應我,做一回老保,就這次)，團隊成員的工期的預期是他們根據自己的情況得出的合理估計，是有偏差的，在你這裡永遠要做好最悲觀的估計，即假設所有人的預計都是不可靠的，如果發生此類情況，項目應當如何調整，你需要有風險對沖方案。假設一個功能程序需要3天，那麼3天后程序沒有完成你要怎麼辦？當場放棄，還是多給幾天？如果多給幾天，勢必會壓縮後續工作進度，那麼你就得考慮放棄後續的哪些需求？你要與策劃核對他對功能的優先級，保證優先級最高的任務優先完成，跟他說明情況，商量著把需求控制在合理的範圍內，多了要砍，少了要加。我根據自己的實踐結果表明，遊戲開發不論小團隊還是大公司，工期延期比比皆是，幾乎是家常便飯，所以延期不可怕，但一定要做好準備。
接下來分享一下我的失敗經驗，本次參賽我組作品雖然最後趕出來了，但最終包卻存在惡性bug，這個功能是在11號下午加上的，也就是最終包前幾個小時，由於時間緊迫，我在測試時也是草草測完就告訴程序可以打包。實際上在之前我已經告訴了團隊成員，在最後一天禁止任何代碼提交，全組只做測試工作。但由於我犯了我前面所提的錯誤，沒能始終堅持自己的立場，導致了最後的悲劇，最後一天我們仍然在瘋狂加功能，策劃不斷地在提出修改意見，程序也不斷的在反覆修改，而我看到一個功能只需要一兩個小時就加上的時候，也沒有提出反對意見，默許了大家的操作，在一旁專心的幫忙測試，到最後大家都很累，我測試也沒那麼仔細了，最終發生了預料之類的風險，我才追悔莫及。如果上天肯給我再來一次的機會，我一定會否決掉大家的所有需求，讓最終包停留在穩定版。
實際上一個小團隊需不需要PM也是值得商榷的事，另外並不是所有團隊都是全職開發，如果不全職開發，項目管理也沒那麼好做。關於這一點，就見仁見智了，這裡只提供一點對PM崗對項目管理的小小經驗分享，另外我本次的作品《魔女破天輪》，大家有興趣可以玩玩看，看看是否能找到我遺留在裡邊的bug，喜歡的話免費的關注和投票也可以來一下，我代表團隊對您報以最誠摯的感謝！