每日堅持一篇，反思自己，總結經驗。
玩法、系統的跟進，是游戲策劃，特別是系統策劃在工作中常見的工作內容。一個策劃案，從思路提出到設計案形成，經歷的是思辨的過程。之后經過程序、美術的工期評估，開始進入制作周期，就進入到執行的過程了。由于游戲開發是藝術和軟件研發的綜合體，所以在推進過程中，我們經常會遇到延期，功能被迫刪除，完成效果不佳，沒有時間調優等問題，進而有可能導致完成效果不佳，功能上線延遲等一系列的問題。有沒有辦法在推進周期中降低這些問題出現的頻率，減少研發質量下滑的風險呢？介于今日我開始跟進自己項目版本的功能系統，我決定在這個過程中梳理一下自己的經驗，并總結每日的跟進心得。
昨天是項目研發的啟動日，我的反思為“排除腦海中不切實際的想法”。今日的總結，我決定從哪些可能存在的風險點入手，談談項目流程跟進中那些可能出現的坑，那些需要我們時刻警惕的問題。
坑一：被卡主的節點
并行開發是一個在開發過程中需要無限去靠近的理想值，越接近這個理想值，開發的效率就會越高。網游開發一般都會涉及客戶端與服務器，涉及這兩者，就意味著期間同一個模塊會有很多耦合，交叉的部分。更不用說這期間還有策劃的體驗調試、配置、美術的資源提供等流程線。當這些流程線交織在一起時，極其容易出現某個人卡主，另外一群人的工作全部卡主的情況。如UI界面遲遲不出，客戶端卡主；服務器同步協議接口制作時，客戶端卡主等諸多問題（好像被卡主的都是客戶端？）。這時，作為項目的負責人——策劃，就需要進行及時的協調了。這種協調可以通過如下幾種手段推動：
1、分析前提：拆分清楚的功能模塊。開發所涉及的功能模塊拆分類似于一張導航圖，可以讓策劃明白客戶端與服務器實現最終目標，要經歷的環節。進而可以從中抽出哪些環節是需要雙方聯調，或彼此依托的。
2、不斷的總結：敏捷開發的三問。昨天我做完成什么？今天我做了什么？誰卡主了我？策劃每日可發起會以，讓開發小組的同事進行總結。在總結過程中，只談問題，會后在尋找解決方案。這樣可以讓開發過程中相互耦合、制約的問題及時的暴露出來，以此讓大家調整優先級。優先解決卡點問題，避免互相等待。
3、創造挑戰：提前聯調的時間點。無論是處于保險，還是為了偷懶，不給自己太多壓力。人都會有過少預估的情況，這種情況需要適度的控制，否則在高協作的研發過程中，一個人腳步的放緩會傳播到所有人身上。作為產品推動者，一定要給予“能否提前”的壓力，讓每個人尊重時間節點。以避免出現一環出錯，環環出錯的問題。
坑二：失控的需求增加
自《人人都能成為產品經理》大火后，人人都想成為產品經理了，這其中就包括你的老板，或者，或者其他人吧。所以我們會發現，在項目研發的過程中，需求會不斷的加入，變更和更新。上次文章有提到，奢求游戲研發存在一種從不改變需求的情況，那是不存在的。所以我們需要敏捷迭代，小步試錯。但這也并不意味著在項目的研發過程中，我們的需求可以隨時變更。因為每一次的變更，或者需求的新增，都有可能使得最初的節點承諾成為一紙空文。這種影響將是災難性的，當計劃完不成時，計劃也就沒有計劃的價值了，截止時間就將變得不可控。所以，有效的辨別需求，控制變更在項目推進過程中也必不可少。同樣，面對要新增需求這種想法時，最好先在內心問如下三個問題：
1、我能否拒絕？無論這個需求源于你的老板還是你自己，能否拒絕都是應該放在第一優先級的去考慮的問題。當你能夠找到足夠充分的理由來證明自己可以拒絕這件事時，都不要在往下想了。有效拒絕是控制需求的第一步。很多問題，往往你放幾天，他就不是問題了。
2、這真的可以解決這個問題嗎？項目開發就是一個創造問題，解決問題的過程。所以，當你想要為解決某一個問題，而提出一個需求時，一定要看看這個方法是不是真的可以解決這個問題，會不會帶來其他更復雜的影響。如果需要評估的關聯項過多，那冷靜的放下來思考。先思考好了再推動效率會更高。
3、解決這個問題是否會打亂當前研發的節奏？實在無法回避上述兩個問題，必須要解決這個問題時（或被動、或主動）。你需要評估的就是這個需求是中間插入，還是放到最后來做會好些。這很難明確的給出標準，畢竟有的需求，是越早改越好的，但是一定要想好，再決定是否插入。這種插入一定不能過于頻繁，否則我們就會陷入失控的需求狀態了。
游戲開發過程中的坑，想必也是很多產品研發中的坑。作為一個推動者，負責人。我們今天不談設計，先想想自身推動設計實現的方法。爭取在明天做到更好吧！
未經允許不得轉載
