关于什么是pipeline的一些思索
CG流程管理从何而来？
首先，把为什么一定要在CG制作流程中，引入流程管理（下面简称pipeline）的理由明确出来。
我认为他可以是任何琐碎的理由，希望不拿错文件，希望能够知道现在的制作进度。
对我来说。最开始的想法就是，开始制作的时候，能一次性拿到符合规范的文件，好开始我的工作。
当我把大家的想法汇总起来之后，我的总结是4个字：
降本增效
我目前在流程管理中的资历尚浅。目前得到的结论和推论或许还有问题。
只有在我整理出来我的想法之后，才有可能跟前辈们请教问题在哪里。而这个文章就是我梳理自己思想的一个存档。
我希望能以此机会，自我论证想法，并加以打磨。
在学习CGpipeline的过程中遇到的事情
这里有几件事情可以分享
在公司A时遇到的背叛
在公司B时开阔的眼界
在公司C时实践的困难
以及在平时生活中看到的一个现象。
A公司的故事
首先聊聊在公司A的事情。
那个时候我刚从一个具体的业务岗位转职到开发岗。算是同时兼职了业务和开发两个职能。我希望能够通过这次工作机会实现向开发岗的转变。
不过在开发岗工作中，我还有另外一个同事。我们之间相处的并不是很愉快。
问题出在公司的结构上。这个公司是个小型公司。管理业务的老板是华裔美国人，项目管理员是韩国人，总监是台湾省的。
这个项目管理员（下称PM）带了另外的几个韩国人作为主管直接和他对接。而我和另外一个人是国内这边的做技术的主管。明面上平级，实际上低了半级。
我进公司的时候。已经是运行了一段时间了。不过还很初期，业务也不多。把我招进来，就是为了他们的一个原创项目。所以为了这个项目能够顺利铺开。我发起了对pipeline预先开发和铺垫的提议。我也拿到了许可便开始了初期工作。
或许是我刚刚从业务岗转开发岗。一开始是被小看了。我拿出来一整套文档。在我现在的水平回看当时的工作。我拿出来的是一份白皮书草案以及实施方法。以及文件管理系统的雏形。
当时被PM说，这里还有很多问题。你应该这里改改。那里改改。我认为OK。
但是当我第二次在例会上说这个事情的时候。事情出现了变化。韩国人认为这个项目应该由他们去主导，并且因为工作繁忙没办法马上给出来路线图以及任何指导文档。他们在拖延时间，让pipeline无法开发出来。
我认为他们没有时间做这个事情，就不要揽在自己手里。并为这个事情在管理层之间发生了一次会议。我的另一个开发同事认为应该自己开发，而我错以为他和我一个阵营。对这次我认为十拿九稳的会议，产生了根基上的动摇。
我的另一个同事认为这些全部都要开源，不能引入第三方的闭源工具来辅助，包括cgteamwork，ftrack，shotgun。而我的观点是，这些东西的开发我们目前没有人力物力去做。可以先借力，之后再替换成自己写的。
我当时，主观上认为是这个原因才造成了他的反水。多年后再回看，这位同事在媚洋。
当他喊出那句“I will follow you,PM”。我就闭嘴不说话了。因为我知道在关键投票上，他背叛了我。或许从一开始他就没站在我这里？
顺便说点题外话。从之前的夺权但是拖延的时候，我就发现了PM手下另一个韩国人（下称狗腿子）并没有半点实力。毕竟在例会上被我阴阳了很多次。在跟我沟通的时候。路线图画的跟涂鸦一样，没有标注，没有文字，只有线和圈圈，然后圈圈画的满黑板都是，分不清你我。
从这件事情上，我事后分析。PM认为产线是重要的，需要开发的。但是我的方案和他的预期有差距，所以希望狗腿子能够作为一个钳制，来让我服从PM的安排。可惜狗腿子并不会武功，并没有得逞。因为，我设计的产线是具备监督性和量化性的。所有人，包括PM参与的业务工作。以及狗腿子以及其他韩国人的工作。都会被纳入监督和记录。
另外，产线还有一套运行规则，类似于法律一样的东西（现在我把他叫做白皮书）。谁制定他并为他赋权，谁就掌握了话语权。韩国人会把我喊停，是因为我从下到上夺了他们制定规范的权利，并用“为了公司和老板的利益”的理由为其赋权。而他们却不敢把自己的标准强制下发执行，因为做不出来不被骂的规范，这个算是我的主场优势。
其实事情讲到这里。我已经在面试其他公司了，只是没找到合适的。顺便说一下。当我找到好去处的之后的两天。背叛我的那个同事对我说“大远，你是对的，那些韩国人什么都做不出来，浪费了一年多时间”。可是我没准备去原谅他。恶狠狠对他的说“你活该。” 。
毕竟，当他在韩国人手里当成宝发光发热的时候。可完全没有帮我说过一句公道话。
也希望大家也能从我分享的这个故事中，不盲目崇洋媚外，也应该切记产线的重要性，不要盲目激进的推进。会发生什么。我也在故事中简单描述过了。
B公司的故事
接下来说点开心的。我在公司B中遇到的一些事情。
这是一个200多人的大型公司，光是我的开发同事就有十来个。很爽。讲个程序员笑话，随便都找得到接梗的人。
我在这里跟着主管做个大头兵。我觉得很好，这样我才能了解到产线的运作方式。让我受益良多。当我开始熟悉了产线的工作内容时，得到了一个很好的锻炼机会。根据主管提供的原型功能，补充作为润滑的代码，向主管提出修改需求，并实践产线自动化的功能。我尽可能去描述的就是。当绑定师发布了一个角色之后。自动套用毛发设定（groom），给一个动画，加一套预设好的灯光，并发送到农场去渲染，结束后出一个合成好的动态图片。同时在对应环节的对应动作上。留下记录。
这是一个激动人心的工作。如果能够跑通这套流程。就代表着可以节省大量的人力在文件的制作验证上，需要手动制作的工作，也可以使用自动化功能，一键解决。非常的重要，并且充满了想象力。比如，在作为控制台的shotgun上，点一个按钮，就能把当前最新的供应商文件刷入产线并自动跑一遍领取发布，刷新最终数据。
很荣幸我在公司其他同事的帮助下，回应了主管的期待。完成了这个功能。并陆陆续续的增加了多余3个的大型项目。增加了不少眼界。也对国内的动画电影制作流程。有了一个大概的认识。不过在这个过程中，我也意识到了一个问题。给钱的老板，对研发非常的漠视。甚至曾经问我，物理学家有什么用？我竟一时无法回答。但是我现在可以回答他：“在你的公司失去竞争力，只能拼廉价劳动力的时候，你会后悔把研发部搞黄”。很直观的能够看出来，老板对业务的看重和对研发的轻视。
在这个公司的经历中，我学习到了，自动化是产线中非常重要的一个硬指标。只有具备了这个能力，才能与普通用户，或者对产线管理的理解懵懵懂懂的人。一个提手来明白
产线 == 自动化 == 减少人力成本 == 增加效益
当然。产线远不止于此，而对普通人去解释，这样已经足够了。
回到对上个故事的总结中。我想补充一点，既然聊到了自动化，那么就需要明白，他有一个先决条件。规范化。
C公司的故事
这样正好引入到了我们第三个分享的故事
在公司C中。我总结了前面时间线中发生的事情，并以小型自动化产线框架为目标去工作和努力。要做的第一步，就是规范化产出。
对于规范化的事情。无外乎是一些文案的工作。比如正确填写资产的名称，文件结构中要有什么，不要有什么，具体细节是什么样子的，最终把文件命名成什么样子，存放到什么位置，在哪里存一个备份。相关的过程文件，拍屏，预览都准备一个。
听起来很细碎？雀实是这个样子的。
我在工作的第五年遇到了这样的事情，手动去做这些事情。很遗憾我没坚持到第二个文件，就跟老板说。这个我做不了。太影响我工作效率了。每次提交上去都要改，很麻烦，很耽误我的工作进度。
我当年很理解这些痛苦。所以即使是我现在身份互换，成为了发号施令的那个人，也不会对艺术家们做出来这种无理的要求。
这些工作充满了规范性，为什么不用python代码来解决呢？只要我付出一点时间，就能让艺术家在手指轻点的一瞬间，做到我想要的。两全其美。
甚至我可以揉进去更多的功能。这一切只需要看一遍提示来做确认，然后点一下，其他什么都不需要做。这样就把学习成本控制在了合理的区间。艺术家们很容易就能接受。
那么第一个挑战就有了合理的解决方案。
紧接着随之而来的是，功能在调试过程中，会出现很多bug。如何及时修复bug，并安抚艺术家的情绪变成了工作重点。
艺术家烦躁 == 工作效率降低 == 老板问责
我虽然进行了详尽的测试再发布出去，依然会有一些问题出现。此时老板只会听到大部分人在抱怨产线不好，而不会有人站出来说，这个功能写的很好。所以一定要做好老板的工作。告诉他，现在工作是在做规范化，这是之后自动化的基础，并且是之后找供应商时可以节省成本的理由，在他心里植入一个规范化很重要，产线很重要的认识。以及一五一十的解释清楚，为什么会有人去抱怨，是他们的问题，还是产线的问题。自己承认不足也很重要，并且要给出解决的日期。这样就可以在老板心中画一条线，某某日之后的抱怨雀实减少了。并且有证据证明大部分是员工被限制了一些不好的工作习惯造成的。
老板或者负责人的信任在这个阶段尤为重要。现在的我，一定会夸奖当时的我没有把步子迈得太大。有意的放慢新功能上线是正确的。
故事越来越接近现在了。资产的槽位已经超过了1500个了。在有限的人力下，我通过pipeline的辅助，妥善管理好的项目。至少我对自己的评价是及格了。但是还有很多要去学，要去做的。
一些其他的故事
对于产线的理解，影响我的还有几件事
徐国梁大哥，机器猫大哥等等。都是我的前辈和同行。他们曾经发起了一个讨论就是《为什么没有出现一个标准且统一的pipeline系统供大家使用》
我简单的总结一下大家的看法，主要有以下三点：
这是公司核心竞争力，不会轻易分享
每个公司都有不同的架构，不具备可复制性
每个公司艺术家的水平不同，不具备可替代性
都很有道理。但是我认为，还有一个原因：
对pipeline，大家还没有达成一个统一且核心的认知
为什么会这样，我们先看一下，我目前了解到的，大家对pipeline的看法：
对于制片人，项目负责人，制片。他们需要的是自上向下的管理。通过一个可视化的数据系统，对整个项目运筹帷幄。
对于做业务的艺术家，这是一个方便的领取工具，提交的时候有自动检查，还能方便的发布。
对于投资人，这是一个保证我的资产不会丢失的保险系统。
对于TD，这是一个需要写工具，方便各环节艺术家轻松工作的软件系统。
这仿佛盲人摸象一般，大家都窥见了其中的一角。
不错。这些都是pipeline流程管理系统需要实现的。
所以我尝试着去定义什么是pipeline。或许他是一个
用于协调，组织/收集，跟踪和优化项目资源和工作流的工具。
我们使用这个工具，要去实现的目标是
提高生产效率
确保各个环节之间顺畅衔接
简化团队协作
听起来。这是一个只有大型团队才需要的工具，像是《哪吒魔童降世》《小夜游神》《深海》这样的项目才用得到。而我做小型化是不是有点没抓住重点？
是的。听起来是这个样子的。但是，多小的团队才不需要产线。或者说。多小的项目才不需要产线呢？您很难给他下出一个定义。
在找寻这个答案的路上，我遇到了另一件事情。这是一个机缘巧合。我和一个跑量视频的老板交换了一些想法。从中我得知了几个事情。
他的工期很短
人员流动性极强
没有研发需求
当我继续询问，就连组长都留不住，那这视频里的绑定动画材质渲染是不是也没有规范？
他说是的，很简单的一个镜头，能出图就行，都这么简单了，员工也要做很久。
为什么呢？
我猜测问题出在文件整理上。换做是我，整理一两个文件我还能忍受。但是几百个的话。
员工就只有一个半的选择。尝试加薪并被拒绝，然后离职。
这个故事没有其他后续了，萍水相逢的缘分，也尽于此。
不过带来的启示也很明确。
两个人，在一个月内，能够制作的资产数量上限，约莫是300个。这就是小型项目的起点。
终点大概在20个人一个月内的数量，也就是3000个，以此为小型项目的分界线。
以管理300到3000个范围内资产的流程系统，就是我的目标。
而这个体量，也在项目完成1/3的时候，时间上的收益和损耗就产生了交叉。从初期的损耗，开始向节省时间的趋势发展。比如，因为无论资产有多少。你都可以通过产线软件进行精确的查找，找到正确的文件。避免了没有产线的情况下，问很多人找到正确的文件后，发现是旧版本的尴尬情况。或许一两个文件还能接受。那么几百个文件都要这样去找呢？这太糟糕了。
去做产线，也有了现实上的意义。
我的故事分享到这里，洋洋洒洒也说了很多了。
现在对pipeline的理解
上面稍微提到过了。pipeline是一个用于协调，组织/收集，跟踪和优化项目资源和工作流的工具。那么如何去实现这些目的。
我目前的划分规划如下
任务管理：ftrack，用于安排和分配任务，追踪项目进度。
版本控制：自开发框架，基于shutil和paramiko实现的文件储存系统，用于管理文件版本，确保多个艺术家可以共同修改内容，并且不会导致数据丢失。
资产管理：自开发框架，用于领取/提交项目资产，如模型、Lookdev、CFX、动画等，便于查找、更新和检查。
渲染管理：目前有了规划，但是还没有实施，尝试基于alembic和usd进行跨DCC渲染
工具脚本：基于Python和DCC自有脚本语言，用于编写工具或脚本来优化特定任务。
在这个规划的基础上。还能够继续细分详细的任务来优化体验。
但是这些内容，还没办法自豪的拍胸脯说。我可以适用于任何公司的任何流程。
依然需要大量的人力去在现有框架下适配。不过这已经相较于几年前，重新开发的方式要温柔多了。
关于接下来想做的一些事情。我会另外开贴聊一聊的。感谢您看完我这5000多字的逼逼叨叨。
谢谢您的捧场。
