關于什么是pipeline的一些思索
CG流程管理從何而來？
首先，把為什么一定要在CG制作流程中，引入流程管理（下面簡稱pipeline）的理由明確出來。
我認為他可以是任何瑣碎的理由，希望不拿錯文件，希望能夠知道現在的制作進度。
對我來說。最開始的想法就是，開始制作的時候，能一次性拿到符合規(guī)范的文件，好開始我的工作。
當我把大家的想法匯總起來之后，我的總結是4個字：
降本增效
我目前在流程管理中的資歷尚淺。目前得到的結論和推論或許還有問題。
只有在我整理出來我的想法之后，才有可能跟前輩們請教問題在哪里。而這個文章就是我梳理自己思想的一個存檔。
我希望能以此機會，自我論證想法，并加以打磨。
在學習CGpipeline的過程中遇到的事情
這里有幾件事情可以分享
在公司A時遇到的背叛
在公司B時開闊的眼界
在公司C時實踐的困難
以及在平時生活中看到的一個現象。
A公司的故事
首先聊聊在公司A的事情。
那個時候我剛從一個具體的業(yè)務崗位轉職到開發(fā)崗。算是同時兼職了業(yè)務和開發(fā)兩個職能。我希望能夠通過這次工作機會實現向開發(fā)崗的轉變。
不過在開發(fā)崗工作中，我還有另外一個同事。我們之間相處的并不是很愉快。
問題出在公司的結構上。這個公司是個小型公司。管理業(yè)務的老板是華裔美國人，項目管理員是韓國人，總監(jiān)是臺灣省的。
這個項目管理員（下稱PM）帶了另外的幾個韓國人作為主管直接和他對接。而我和另外一個人是國內這邊的做技術的主管。明面上平級，實際上低了半級。
我進公司的時候。已經是運行了一段時間了。不過還很初期，業(yè)務也不多。把我招進來，就是為了他們的一個原創(chuàng)項目。所以為了這個項目能夠順利鋪開。我發(fā)起了對pipeline預先開發(fā)和鋪墊的提議。我也拿到了許可便開始了初期工作。
或許是我剛剛從業(yè)務崗轉開發(fā)崗。一開始是被小看了。我拿出來一整套文檔。在我現在的水平回看當時的工作。我拿出來的是一份白皮書草案以及實施方法。以及文件管理系統的雛形。
當時被PM說，這里還有很多問題。你應該這里改改。那里改改。我認為OK。
但是當我第二次在例會上說這個事情的時候。事情出現了變化。韓國人認為這個項目應該由他們去主導，并且因為工作繁忙沒辦法馬上給出來路線圖以及任何指導文檔。他們在拖延時間，讓pipeline無法開發(fā)出來。
我認為他們沒有時間做這個事情，就不要攬在自己手里。并為這個事情在管理層之間發(fā)生了一次會議。我的另一個開發(fā)同事認為應該自己開發(fā)，而我錯以為他和我一個陣營。對這次我認為十拿九穩(wěn)的會議，產生了根基上的動搖。
我的另一個同事認為這些全部都要開源，不能引入第三方的閉源工具來輔助，包括cgteamwork，ftrack，shotgun。而我的觀點是，這些東西的開發(fā)我們目前沒有人力物力去做?？梢韵冉枇Γ笤偬鎿Q成自己寫的。
我當時，主觀上認為是這個原因才造成了他的反水。多年后再回看，這位同事在媚洋。
當他喊出那句“I will follow you,PM”。我就閉嘴不說話了。因為我知道在關鍵投票上，他背叛了我?；蛟S從一開始他就沒站在我這里？
順便說點題外話。從之前的奪權但是拖延的時候，我就發(fā)現了PM手下另一個韓國人（下稱狗腿子）并沒有半點實力。畢竟在例會上被我陰陽了很多次。在跟我溝通的時候。路線圖畫的跟涂鴉一樣，沒有標注，沒有文字，只有線和圈圈，然后圈圈畫的滿黑板都是，分不清你我。
從這件事情上，我事后分析。PM認為產線是重要的，需要開發(fā)的。但是我的方案和他的預期有差距，所以希望狗腿子能夠作為一個鉗制，來讓我服從PM的安排?？上Ч吠茸硬⒉粫涔?，并沒有得逞。因為，我設計的產線是具備監(jiān)督性和量化性的。所有人，包括PM參與的業(yè)務工作。以及狗腿子以及其他韓國人的工作。都會被納入監(jiān)督和記錄。
另外，產線還有一套運行規(guī)則，類似于法律一樣的東西（現在我把他叫做白皮書）。誰制定他并為他賦權，誰就掌握了話語權。韓國人會把我喊停，是因為我從下到上奪了他們制定規(guī)范的權利，并用“為了公司和老板的利益”的理由為其賦權。而他們卻不敢把自己的標準強制下發(fā)執(zhí)行，因為做不出來不被罵的規(guī)范，這個算是我的主場優(yōu)勢。
其實事情講到這里。我已經在面試其他公司了，只是沒找到合適的。順便說一下。當我找到好去處的之后的兩天。背叛我的那個同事對我說“大遠，你是對的，那些韓國人什么都做不出來，浪費了一年多時間”。可是我沒準備去原諒他。惡狠狠對他的說“你活該?！?。
畢竟，當他在韓國人手里當成寶發(fā)光發(fā)熱的時候?？赏耆珱]有幫我說過一句公道話。
也希望大家也能從我分享的這個故事中，不盲目崇洋媚外，也應該切記產線的重要性，不要盲目激進的推進。會發(fā)生什么。我也在故事中簡單描述過了。
B公司的故事
接下來說點開心的。我在公司B中遇到的一些事情。
這是一個200多人的大型公司，光是我的開發(fā)同事就有十來個。很爽。講個程序員笑話，隨便都找得到接梗的人。
我在這里跟著主管做個大頭兵。我覺得很好，這樣我才能了解到產線的運作方式。讓我受益良多。當我開始熟悉了產線的工作內容時，得到了一個很好的鍛煉機會。根據主管提供的原型功能，補充作為潤滑的代碼，向主管提出修改需求，并實踐產線自動化的功能。我盡可能去描述的就是。當綁定師發(fā)布了一個角色之后。自動套用毛發(fā)設定（groom），給一個動畫，加一套預設好的燈光，并發(fā)送到農場去渲染，結束后出一個合成好的動態(tài)圖片。同時在對應環(huán)節(jié)的對應動作上。留下記錄。
這是一個激動人心的工作。如果能夠跑通這套流程。就代表著可以節(jié)省大量的人力在文件的制作驗證上，需要手動制作的工作，也可以使用自動化功能，一鍵解決。非常的重要，并且充滿了想象力。比如，在作為控制臺的shotgun上，點一個按鈕，就能把當前最新的供應商文件刷入產線并自動跑一遍領取發(fā)布，刷新最終數據。
很榮幸我在公司其他同事的幫助下，回應了主管的期待。完成了這個功能。并陸陸續(xù)續(xù)的增加了多余3個的大型項目。增加了不少眼界。也對國內的動畫電影制作流程。有了一個大概的認識。不過在這個過程中，我也意識到了一個問題。給錢的老板，對研發(fā)非常的漠視。甚至曾經問我，物理學家有什么用？我竟一時無法回答。但是我現在可以回答他：“在你的公司失去競爭力，只能拼廉價勞動力的時候，你會后悔把研發(fā)部搞黃”。很直觀的能夠看出來，老板對業(yè)務的看重和對研發(fā)的輕視。
在這個公司的經歷中，我學習到了，自動化是產線中非常重要的一個硬指標。只有具備了這個能力，才能與普通用戶，或者對產線管理的理解懵懵懂懂的人。一個提手來明白
產線 == 自動化 == 減少人力成本 == 增加效益
當然。產線遠不止于此，而對普通人去解釋，這樣已經足夠了。
回到對上個故事的總結中。我想補充一點，既然聊到了自動化，那么就需要明白，他有一個先決條件。規(guī)范化。
C公司的故事
這樣正好引入到了我們第三個分享的故事
在公司C中。我總結了前面時間線中發(fā)生的事情，并以小型自動化產線框架為目標去工作和努力。要做的第一步，就是規(guī)范化產出。
對于規(guī)范化的事情。無外乎是一些文案的工作。比如正確填寫資產的名稱，文件結構中要有什么，不要有什么，具體細節(jié)是什么樣子的，最終把文件命名成什么樣子，存放到什么位置，在哪里存一個備份。相關的過程文件，拍屏，預覽都準備一個。
聽起來很細碎？雀實是這個樣子的。
我在工作的第五年遇到了這樣的事情，手動去做這些事情。很遺憾我沒堅持到第二個文件，就跟老板說。這個我做不了。太影響我工作效率了。每次提交上去都要改，很麻煩，很耽誤我的工作進度。
我當年很理解這些痛苦。所以即使是我現在身份互換，成為了發(fā)號施令的那個人，也不會對藝術家們做出來這種無理的要求。
這些工作充滿了規(guī)范性，為什么不用python代碼來解決呢？只要我付出一點時間，就能讓藝術家在手指輕點的一瞬間，做到我想要的。兩全其美。
甚至我可以揉進去更多的功能。這一切只需要看一遍提示來做確認，然后點一下，其他什么都不需要做。這樣就把學習成本控制在了合理的區(qū)間。藝術家們很容易就能接受。
那么第一個挑戰(zhàn)就有了合理的解決方案。
緊接著隨之而來的是，功能在調試過程中，會出現很多bug。如何及時修復bug，并安撫藝術家的情緒變成了工作重點。
藝術家煩躁 == 工作效率降低 == 老板問責
我雖然進行了詳盡的測試再發(fā)布出去，依然會有一些問題出現。此時老板只會聽到大部分人在抱怨產線不好，而不會有人站出來說，這個功能寫的很好。所以一定要做好老板的工作。告訴他，現在工作是在做規(guī)范化，這是之后自動化的基礎，并且是之后找供應商時可以節(jié)省成本的理由，在他心里植入一個規(guī)范化很重要，產線很重要的認識。以及一五一十的解釋清楚，為什么會有人去抱怨，是他們的問題，還是產線的問題。自己承認不足也很重要，并且要給出解決的日期。這樣就可以在老板心中畫一條線，某某日之后的抱怨雀實減少了。并且有證據證明大部分是員工被限制了一些不好的工作習慣造成的。
老板或者負責人的信任在這個階段尤為重要?，F在的我，一定會夸獎當時的我沒有把步子邁得太大。有意的放慢新功能上線是正確的。
故事越來越接近現在了。資產的槽位已經超過了1500個了。在有限的人力下，我通過pipeline的輔助，妥善管理好的項目。至少我對自己的評價是及格了。但是還有很多要去學，要去做的。
一些其他的故事
對于產線的理解，影響我的還有幾件事
徐國梁大哥，機器貓大哥等等。都是我的前輩和同行。他們曾經發(fā)起了一個討論就是《為什么沒有出現一個標準且統一的pipeline系統供大家使用》
我簡單的總結一下大家的看法，主要有以下三點：
這是公司核心競爭力，不會輕易分享
每個公司都有不同的架構，不具備可復制性
每個公司藝術家的水平不同，不具備可替代性
都很有道理。但是我認為，還有一個原因：
對pipeline，大家還沒有達成一個統一且核心的認知
為什么會這樣，我們先看一下，我目前了解到的，大家對pipeline的看法：
對于制片人，項目負責人，制片。他們需要的是自上向下的管理。通過一個可視化的數據系統，對整個項目運籌帷幄。
對于做業(yè)務的藝術家，這是一個方便的領取工具，提交的時候有自動檢查，還能方便的發(fā)布。
對于投資人，這是一個保證我的資產不會丟失的保險系統。
對于TD，這是一個需要寫工具，方便各環(huán)節(jié)藝術家輕松工作的軟件系統。
這仿佛盲人摸象一般，大家都窺見了其中的一角。
不錯。這些都是pipeline流程管理系統需要實現的。
所以我嘗試著去定義什么是pipeline?；蛟S他是一個
用于協調，組織/收集，跟蹤和優(yōu)化項目資源和工作流的工具。
我們使用這個工具，要去實現的目標是
提高生產效率
確保各個環(huán)節(jié)之間順暢銜接
簡化團隊協作
聽起來。這是一個只有大型團隊才需要的工具，像是《哪吒魔童降世》《小夜游神》《深?！愤@樣的項目才用得到。而我做小型化是不是有點沒抓住重點？
是的。聽起來是這個樣子的。但是，多小的團隊才不需要產線。或者說。多小的項目才不需要產線呢？您很難給他下出一個定義。
在找尋這個答案的路上，我遇到了另一件事情。這是一個機緣巧合。我和一個跑量視頻的老板交換了一些想法。從中我得知了幾個事情。
他的工期很短
人員流動性極強
沒有研發(fā)需求
當我繼續(xù)詢問，就連組長都留不住，那這視頻里的綁定動畫材質渲染是不是也沒有規(guī)范？
他說是的，很簡單的一個鏡頭，能出圖就行，都這么簡單了，員工也要做很久。
為什么呢？
我猜測問題出在文件整理上。換做是我，整理一兩個文件我還能忍受。但是幾百個的話。
員工就只有一個半的選擇。嘗試加薪并被拒絕，然后離職。
這個故事沒有其他后續(xù)了，萍水相逢的緣分，也盡于此。
不過帶來的啟示也很明確。
兩個人，在一個月內，能夠制作的資產數量上限，約莫是300個。這就是小型項目的起點。
終點大概在20個人一個月內的數量，也就是3000個，以此為小型項目的分界線。
以管理300到3000個范圍內資產的流程系統，就是我的目標。
而這個體量，也在項目完成1/3的時候，時間上的收益和損耗就產生了交叉。從初期的損耗，開始向節(jié)省時間的趨勢發(fā)展。比如，因為無論資產有多少。你都可以通過產線軟件進行精確的查找，找到正確的文件。避免了沒有產線的情況下，問很多人找到正確的文件后，發(fā)現是舊版本的尷尬情況?；蛟S一兩個文件還能接受。那么幾百個文件都要這樣去找呢？這太糟糕了。
去做產線，也有了現實上的意義。
我的故事分享到這里，洋洋灑灑也說了很多了。
現在對pipeline的理解
上面稍微提到過了。pipeline是一個用于協調，組織/收集，跟蹤和優(yōu)化項目資源和工作流的工具。那么如何去實現這些目的。
我目前的劃分規(guī)劃如下
任務管理：ftrack，用于安排和分配任務，追蹤項目進度。
版本控制：自開發(fā)框架，基于shutil和paramiko實現的文件儲存系統，用于管理文件版本，確保多個藝術家可以共同修改內容，并且不會導致數據丟失。
資產管理：自開發(fā)框架，用于領取/提交項目資產，如模型、Lookdev、CFX、動畫等，便于查找、更新和檢查。
渲染管理：目前有了規(guī)劃，但是還沒有實施，嘗試基于alembic和usd進行跨DCC渲染
工具腳本：基于Python和DCC自有腳本語言，用于編寫工具或腳本來優(yōu)化特定任務。
在這個規(guī)劃的基礎上。還能夠繼續(xù)細分詳細的任務來優(yōu)化體驗。
但是這些內容，還沒辦法自豪的拍胸脯說。我可以適用于任何公司的任何流程。
依然需要大量的人力去在現有框架下適配。不過這已經相較于幾年前，重新開發(fā)的方式要溫柔多了。
關于接下來想做的一些事情。我會另外開貼聊一聊的。感謝您看完我這5000多字的逼逼叨叨。
謝謝您的捧場。
