技術策劃（Technical Designer）這個崗位真的是有必要的嗎？

最近無意中看到網易有在招收技術策劃，大致jd如下：
技術策劃作為隨著遊戲開發規模的擴大和流程的複雜而產生出來的新興崗位，主要在遊戲開發中負責以下工作：
-理解策劃的需求，並根據策劃的需求和技術部門一起制定解決方案。
-設計遊戲策劃所需數據的架構，協助開發和優化數據製作工具和流程。
-協調美術，動畫，聲音和程序等部門具體實施遊戲所需功能和整合數據。

-制定和執行遊戲策劃相關數據的規範。
-為遊戲策劃以及其他相關部門提供技術支持，包括編寫技術文檔，提供指導和培訓。
-負責遊戲策劃相關數據的質量。
這個崗位之前從來沒有出現過，在國內大多數策劃只要考慮設計問題就好了，系統架構交給程序去設計，編輯器提好需求基本也是交給程序搞，那麼需要一個專門的技術策劃到底有什麼意義？畢竟大多數項目人數規模不上百，其實功能歸納不如找一個小組長來統一管轄調度，工具怎麼設計也是誰用誰提最方便，這種職能完全可以融入其他職能，由功能的主要負責策劃兼任。

按照TA的職能強行套TD不可取。

TA是程序和美術之間的黏合劑，但是策劃跟程序之間不需要黏合劑啊，策劃自己就是黏合劑。實際上TD的出現就是遊戲程序員把一些重邏輯輕數據的工作外包給了有能力的策劃，這不是技術推動的變革，而是商業推動的變革。

傳統的工作流程是：

策劃寫文檔
策劃給程序講文檔
程序實現
策劃驗收
策劃向程序反饋修改

加入技術策劃之後的工作流程是：

技術策劃寫文檔、實現、自測、迭代

這樣一來，流程縮短了，效率提高了，信息丟失少了。資本家可以多僱傭便宜的策劃，少僱傭昂貴的程序，以便在同樣的成本下產出更多的遊戲內容。

賣家多賺錢，買家少花錢，豈不美哉？

隨著項目複雜度和體量的提升，各職能細分和分工協作是製作開發從作坊模式走向工廠模式的必然要求。所以專精技術的策劃（TD）產生是必然，十多年前這個職位就存在於歐美大廠中了。

但是其他很多回答卻說好的策劃必須要懂程序，我覺得是一種無知：

首先開發者的長板決定了遊戲產品的上限，上限高也就競爭力更高，遊戲行業就是贏者通喫。一個策劃5程序5的人做的產品上限肯定不如一個策劃8+一個程序8合作的上限高。當然如何配置、協調、賦能團隊也是一門學問，國內的管理模式一向粗暴，996搞定一切。

其次一個人的精力是有限的，除了牛頓、達芬奇這種牛人，大部分還是普通人，如果做不到一專多長，就應該把有限的時間花在自己感興趣、有天賦、提升快的專業方向，這樣才能在團隊中凸顯自身價值。尤其在國內給你的試錯機會更少，很多公司已經明確不招35以上的打工者了，啥都會啥不精可能讓你在遊戲行業提前退休。當然如果入行就奔著自己創業做獨立遊戲的則不在此列。

最後國內遊戲市場發展時間較短，環境不成熟，資本助推，也導致了業內人心浮躁，不求積累喜歡賺快錢，遊戲產品的做法更像是流量變現的互聯網產品。很多遊戲策劃是隨著熱錢流進來的，壓根沒有專業素養或是正規的項目實踐積累，這也導致了這些上限低的策劃只能做些打雜或是口胡，讓團隊覺得這個工種對團隊的價值貢獻很少，只會腦洞、需求不明、設計挖坑、迫於各方勢力要求團隊做需求變更勞民傷財。

很多項目裏一個技術策劃可以讓策劃們的工作效率提升30%甚至以上，但對國內的資本家來說這並沒有什麼卵用，因為讓員工們多加30%的班反正又不要錢

從今天的情況來看，是需要的。

其實從道理上來說，遊戲策劃應該是具備這些能力的，這本應是作為一個遊戲策劃的最基本的能力，這個問題我在2017年開年（3年多前）就回答過：

為什麼策劃和程序之間沒有產生技術策劃（Technical Designer）這個職位？?

www.zhihu.com

因為如果遊戲策劃不具備一定的編程邏輯，那遊戲項目幾乎是做不好的。所以，如果每一個策劃都有這個能力，完全不應該存在TD這個職位。所以今天的TD，其實是從「兵種」上彌補了遊戲策劃的缺陷。

其實我在知乎發過一篇文，是幫助回答一個問題用的，這篇文章的內容是關於一個刷怪系統的：

猴與花果山：適用於所有ARPG遊戲的刷怪機制?

zhuanlan.zhihu.com

刷怪系統看起來不是一件大事，但是實際上很多遊戲的刷怪系統卻完全不合格，這很簡單，因為團隊裏缺乏一個我這樣能「跟程序談策劃，跟策劃談程序的廢物」（事實上我一般不跟策劃談程序，也不會跟程序談策劃，雞同鴨講的事情沒啥意義），所以設計不了這樣的結構。

設計好遊戲的數據結構好處是什麼？我們不談對於程序運行來說的重要性，那都是廢話。我們就說策劃這裡，好的數據結構會讓填表等工作更加的輕鬆——我見過很多公司有很多100-300列的數據表，這些表的數據還都是上萬行甚至上10W行的（有人吐槽過老版本excel都打不開），這其實是數據結構建立和抽象的嚴重問題，這導致了策劃絕大多數的工作時間和經歷不在設計，而在維護表，所以別小看這件事情的重要性。

而就拿你們這代遊戲人眼下最關注的東西之一——UE4的藍圖來說，藍圖本質上是一個類似excel功能的數據輸入工具，但是能做出藍圖，需要的是一個好的抽象——怎樣把邏輯數據化，怎樣建立數據之間的關係，怎樣建立依賴性都在藍圖的模塊設計中（即策劃在ue4的UI上拖拽的每一個用於連線的方塊）。

每一個能做出項目（不說項目最後有多成功，因為項目能否成功，跟開發的關係基本不大）的團隊，裡面一定有至少一個人能遊走於程序和策劃之間遊刃有餘，可能是製作人、可能是主程、可能是主策。但事實上今天的招聘制度下，我們往往要求「專業人才」從而忽略了這件事情，像我這樣的「綜合型人才」只能失業在家，自己創辦公司做遊戲了。但是公司裏如果沒有我這樣的人呢（因為本來就容不下而已）？項目就會變得不太好做，甚至多半難產，所以特地招募這個崗位，做到名正言順。這說明什麼？說明越來越多團隊終於發現了這些早在上世紀任何做遊戲的人就知道的道理了。到今天還不明白為什麼要TD（這裡僅指工作內容，而非職位），那真的只可能是你主導項目的經驗太欠缺了（注意，所謂主導，是你帶領團隊開發出遊戲，而不是以什麼職位參與過項目，誰成就了誰是key）。

巧了，剛好羣裏發生了一個問題，恰好就是缺少TD的表現：