最近跟行業朋友們聊，發現一個有趣的點，很多團隊，甚至是很大的團隊，都忽略了一個很基本的能力，就是工程能力。也許是很多團隊沒有工程的意識，也許很多大公司團隊並不在意（錢多人多），遊戲就是一個複雜軟體工程，如何高效地把這個工程實現出來，是一門不簡單的學問，是團隊能力的基礎標杆，是一個遊戲水下的冰山。
包括我們團隊，也是自己摸爬滾打，也踩了很多工程上的坑，才逐漸具備還算高效的落地能力。
本篇文章，不敢說分享，只是基於自己的淺薄理解，總結一些經驗教訓，記錄下來提醒自己，也拋磚引玉，希望大家看時多多評論指教，斧正我的錯誤認知，讓我可以反覆運算自己，感激不盡。
一、一切的起點
大方向的變動，搖擺，導致的返工，重做，比任何東西都拖延進度，且打擊士氣。
做好這一點沒有捷徑，就是得項目負責人/製作人想清楚。
最重要的是立項，大多數專案的立項過於草率，之前專案用了接近三個月立項，各種原型進行驗證，砍掉了無數選型，不斷推敲，最後才定下核心玩法。現在看來，還是不夠，當時隱隱也有感覺，有些細節沒有完全推敲到滿意，然後結果就是，這些細節都在未來讓我們花了至少10倍以上的代價去解決，具體可以參考之前的設計復盤。
立項如果能多花一天時間，多想清楚一分，多驗證一點，後面省下的時間可能是10天，100天，也可能是成與敗之分。
有朋友問如何避免另一個極端，在立項時長期過度打磨，怎麼樣才算思考清楚？
首先我定義的立項，是核心玩法的立項，這個階段最少只需要一個設計師，如果沒有程序經驗，最多再加一位程式師。這個核心機制的立項階段，我還沒見過哪個團隊有耐心做的足夠久的，遠談不上過度打磨。絕大多數情況，反而是跳過了這個階段，直接拍腦袋一個想法就拉起團隊開始搞了，或者做了大半年，美術資產一堆，核心玩法還沒想清楚。
怎樣算思考清楚，核心意圖明確，推出不變的定點，定點作為評分依據，進行理性客觀的評分，設定一個閾值，超過閾值後，一定時間內沒有更好的方案，就停手。其實在長時間的思考推演下，會有明顯的感知，就是已經是短期內最優解，不太可能有質變的提升空間，這時候，就可以往下一步推進了。
關於立項，不再贅述，是另外一個大話題。
立項的審慎，換來一個值得篤定堅持的方向，這是一切的起點。
二、什麼時候做什麼事情
（僅代表我們類型的專案）
知道什麼時候應該做什麼，是做過0-1后的寶貴經驗。有了全域的視角，能説明新的專案更好推進，快了慢了，什麼時候該做什麼不該做什麼，做到心中有數。
前期驗證期
中期切片期
驗證美術風格，世界觀，做成品品質切片版本，用作以美術相關管線為核心的流程定標。這個階段，可以適當進行一些打磨工作，利用免費測來試探短期留存上限。
後期推進期
驗證通過後，全力推進鋪量，經過合理的驗證期，大方向不能也不會去大改，這時候就是士氣，效率為王，可以不斷改的是，管線流程潤色微調，周邊系統的驗證反覆運算。
最後打磨期
首先控制自己加功能的小手，大部分功能，上線后加也沒有任何區別。至少預留兩個月作為打磨期，一切以穩定性和提升細節為主。應做好內容量預留，上線後三個月-半年的內容量最佳。
三、小步快跑，敏捷開發
以反覆運算為核心，每周一個衝刺，1-2個月見一次玩家，作為一個里程碑，不停做目的清晰的驗證，並提升士氣，凝聚團隊。
並且，利用里程碑控制進度，防止微小的延遲被累積，里程碑的本質是一段足夠長的時間緩衝器，用於將微小任務分配的不確定性中和。
尊重里程碑節點，合理的規劃時間，估時留好預留時間應急，修bug等，延期比加班更損害團隊，因為這會讓團隊逐漸變得不尊重節點。
另外，很值得反思的是：是在小步快跑還是布朗運動？或者說是在反覆運算還是亂改？
想清楚的是反覆運算，沒想清楚的是亂改。
舉例，測試前，目的是看玩家在遊玩A功能時的某某行為參數，設計上認為參數最有可能的表現是X，結果符合預期，應該怎麼繼續前進。但結果也有可能是Y，如果是Y，應該怎麼優化。這就是反覆運算。
測試前，搖擺不定，沒想清楚，感覺這個方案A更好，測測試試。測了結果也不知道是為什麼，那改成方案B測測試試，“測試測試，不就是測測試試嘛”，這就是亂改。
四、快就是慢，債都要還
警惕技術債，設計債。這是來自軟體工程的經典描述，指的是為了短期方便快速做的臨時操作，在未來爆發出問題，結果付出更多代價去解決問題，就像還之前欠下的債。
經典技術債：“先寫死吧”，“時間不夠先臨時實現一下”，“打個補丁處理一下，先保證不出錯”。
經典設計債，“先這樣設計，玩家小概率才會體驗到，問題不大”，“這個遊戲成績好，也有這個系統，照著來吧，又快風險又低”，“還沒想清楚，但先這樣試試吧”。
那應該如何做？
1.可配置
一切都可配置，警惕代碼寫死。
2.基建優先
基建功能，自動打包，熱更等功能，一定越早做越好，整體上省時間。
3.重視QA
重視QA，用例規範，開需求會。排期時，至少四分之一的時間應該排給測試QA。重視回歸測試。
4.避免臨時需求
盡量避免為了當前測試節點，老闆要求等等，做一些臨時需求，應以長遠更高效為先。
5.多問工程問題三問
這個功能目的是什麼，是否有實現性價比更高的替代方案？
怎麼拓展，如果要改動這個功能，是否好改，是否需要程式，能否策劃改配置就能改？
該功能是一個穩定的功能嗎，萬一未來要刪掉，是否好刪，是否會影響其他功能？
等等。。
五、溝通
人月神話大家都知道，本質上是隨著人數提升，協作成本上升速度遠超人力產出上升速度。在沒有合理的管理方法時，理想狀態下，前者指數上升，後者線性上升，因此實際產出是一個對數曲線，邊際效用快速遞減。實際狀態下，前者不是單純的指數，而是有多個質變點的，後者也不完全是線性增長。
以程序來說，成本最高的是溝通成本，其次是設計成本，最後才是編碼實現成本。因此，程序進度，是最符合《人月神話》中提到的Brooks 法則：向進度落後的專案中增加人手，只會使進度更加落後。（Adding manpower to a late software project makes it later）
總結來說就是：因為協作成本的存在，加人不能解決問題，反而應該找准質變點，一般質變點就是從一層管理變成兩層，兩層變三層這些節點。在這些質變點加人就該收手了，先提升團隊管理水準更優。
那怎麼解決呢？溝通成本最高的就是程式，還是以程式為例：
1.任務分解
最好的分任務的方式，是將功能點邏輯劃分合理，然後將其分配到一個前端一個後端能做的顆粒度，減少溝通成本。或者將兩個系統間的輸入輸出埠規劃好，互為黑盒，無需關注對方具體實現。另外，盡量瞭解程式，最好有一定程式設計經驗，維護統一規則文件，作為溝通的橋樑之一。最好了解架構師做的事情，對於設計整個工程結構有所瞭解后，自然能更合理的分配任務。
2.拓展性
考慮到未來可能的變化，越通用，越底層的實現方式，拓展性越強。實現的時候要注意拓展性，更重要的是提出方案時要注意拓展性。
3.文件化
溝通問題，文件化，不要口頭需求。不要私聊要群聊保障資訊同步。文件留痕，減少battle成本，但不要用文檔來做追責，找問題分析問題，而不是追責。多用checklist，摒除專案中一切需要人記憶的部分。
4.傳遞設計意圖
程式徹底了解設計意圖很關鍵，實現起來更明確有動力，也會主動補完一些細節。很偶爾的，程式還會在實現過程中，會發現違反設計意圖的點，這往往很有價值，因為有些東西實現和設計相差很大，可以發現一些隱藏的問題。
5.明確靈活處理的空間
只有一個標準，設計目的，以此為前提，明確什麼是能妥協變通的，什麼是不能妥協必須實現的？
6.分支管理做好
分支管理也是溝通的重要一環，要保證協作的順暢，必須把分支管理做好。每個功能新拉分支，分支命名清晰，不能偷懶。
等等。。
六、士氣
團隊的士氣很大程度上決定了團隊效率，理想的士氣就是每個人都對專案充滿熱情，願意主動做更多，去思考更多，對專案有主人翁意識。
怎麼維護士氣，點燃士氣？
1.里程碑
尊重節點，按期完成里程碑，本身就會增長士氣，就如前文所說：延期比加班更損害士氣。
2.利用反覆運算成果
反覆運算開發的成果是一種增強士氣的利器，數據好就不說了，即使數據暫時不是很好，只要明確方向是對的，只要做的東西可以打動自己，那一定會有玩家喜歡。某些玩家徹夜暢玩，某些玩家發了長帖，做了啥UGC的內容，這些都可以去告訴團隊，讓團隊夥伴感受到做的東西是有人喜歡的，值得為自己的遊戲驕傲，大家在翹首以盼等著我們更新。這樣大家自然士氣更高。
3.主觀能動性
分佈任務時，強調模組的重要性，每個模組都有其意義，就是其設計目的，放大這個意義即可。小技巧，這個意義往往是說為什麼要這個系統，可以反過來說，如果沒有這個模組，我們將損失什麼，往往更能傳遞其重要性。
4.權責明確
控制自身越權管理的慾望，權責明確，充分授權，疑人不用用人不疑。除了設計案，減少細節微操。
5.高效氛圍管理
所有人工作時完全專注，不能允許做任何其他事情，來影響高效專注的氛圍，工作時長上盡量想辦法縮短。這點不能有任何妥協，避免滑坡效應。
6.強力團隊
建立外科手術式的團隊，只招優秀的人，和優秀的人共事本身就在提升士氣。
7.最最重要的！
做自己喜歡，擅長，認可的事。負責人的狀態會很大程度的影響團隊，自己有沒有想清楚，喜不喜歡，認不認同自己的遊戲，大家其實很容易能感受出來，做對的事情的狀態，那種辛苦卻充滿激情的狀態，大家都能感受到，並且被帶動起來。
總結：
工程能力是一個大話題，篇幅有限，這裡只是簡單記錄總結一下，拋磚引玉，希望大家多多斧正。道阻且長，不斷進步！