“ 感知技术 · 感触CG · 感受艺术 · 感悟心灵 ”

本文转自公号：真的起名无力

我们在工作中会碰到如下问题：

我们把上述的问题，按照相关的工作岗位，聚类一下：

Pipeline 就是来解决上述问题的。

更概括一点说，Pipeline 是管理项目的信息和数据的流动。

• 信息被高效、正确、及时地传达到位

• 数据的来龙去脉、前世今生、脉络关系管理地清清楚楚明明白白

它是谁，它从来哪里，它要到哪里去

非常重要的前言：

没有放之四海而皆准的Pipeline系统，一定要根据项目的实际情况，只有适合你的Pipeline才是好的Pipeline。如果是一个几人的小团队，喊一嗓子就能沟通到位的事情，没必要花时间精力去折腾Pipeline系统，得不偿失；或者项目的美术资产很少，也确实没必要。

看到我们的标题了吗，如果你的目标是工业化，或者想知道工业化应该包含什么方面，可以继续往下读了。

开发和维护Pipeline系统的人，在影视行业，叫做Pipeline TD（Technical Director）。

下面一张图片，展示了一个动画电影的完整制作流程，你能找到 TD 在哪里吗？（友情提示，图超长）

高清原图链接：https://www.illuminationmacguff.com/wp-content/uploads/2018/08/PIPELINE-D.jpg

可以看到，（Pipeline）TD 们都是在小房间之外（不参与内容制作）走动，负责监控和维护，保障整个管道正常运行的人。

继续我们的话题，本文我们从刚开始提到的三个岗位的工作内容角度，将 Pipeline 要管理的范畴，分为三大类：

• 项目管理

• Review

• 资产管理（文件和 metadata 的管理）

这三者并不是隔离的，而是紧密结合在一起的，之间的数据和信息流动是要丝滑的、无缝的。

其实 Review 是包含在了项目管理中的 ，但在游戏这边，由于大家经常忽视 review 这一块的重要性，所以我就把它单独拎出来。

按照影视的说法，就是分 Production Management 和 Asset Management。

项目管理

我们这里不涉及项目管理模式，什么Agile还是Waterflow。

这里的内容主要包含：

• 任务分配、排期

• 任务的上下游关联

• 任务的资产关联

• 跟踪资产完成度、发行版本、项目进度等

这里涉及到的数据表有：

• Project（最顶层的，游戏项目、电影项目，或者因为某些原因拆分出来“子”项目）

• Phase（或者叫Sprint，指一段时间，加很多个 milestone，用来做阶段性排期，比如游戏要上线的6.0 版本等）

• Asset（包括影视的 Sequence/Shot、游戏的美术资产、关卡等）

• Task（将 Asset的制作拆分出来的最小级别的、可以分配到具体人的任务，并且有期望起止时间和预计时长）

• People（干活儿的，可以是个具体的美术人员，也可以是家外包公司）

• TimeLog（记录每个 Task 的制作实际制作时长，用来衡量工作效率或者是任务预算是否合适）

大概的关系是：

上述涉及到的内容，最好有甘特图来协助查看和便捷编辑。

另外要有多样的filter，协助项目每个人筛选查看他感兴趣的部分，比如：

• 列出所有动画任务

• 列出所有两周内要过期的任务

• 列出包含在xxx版本要上线的任务

该系统必须可以应对变化，大到比如外部环境变化导致的延期（疫情啊版号啊什么的）、比如老板突然要调整游戏上线日期，小到人员离职，多增加美术、多外包、系统可以快速调整和更新排期，确保每个人都知道自己该做什么、该什么时候做、先做哪个后做哪个。

有一些是为跟踪 bug 而设计的系统，bug 跟踪系统通常不是时间管理的理想选择：它们的主要目标只是确保问题得到解决而不被遗忘，而不是在未来的截止日期之前安排它们

具有项目管理功能的软件/系统有很多，影视或游戏行业在这方面的基础需求也没有太多的特性，强烈建议直接使用一个用户量多的、适合你项目体量的商业系统就行，前提是这个系统必须支持二次开发，因为只满足基本需要可远远不够，按照之前的经验，我们 Pipeline 开发在这个部分的主要精力放在了

• 将生产数据进行各种角度的可视化，帮助PM 精细化管理项目周期和人力安排，把控项目风险，避免空转/过载

• 开发各种自动化监听脚本，比如 当A任务完成80%就把 B任务状态改为“可以开始”，减少 PM 手动、重复工作量，减少人为出错

• 开发各种RTX 通知机器人，比如提醒美术临期任务。及时提醒，避免遗漏

• 开发各种小工具，包括并不限于浏览器插件、基于管理系统的菜单拓展等，减少PM 操作步骤

• 生成产能报告，展示进度、落后的部分、资源闲置等等状况

另外，提到它必须提供二次开发接口，还因为这里的信息，是要出现在美术的工作环境中的，比如DCC、引擎里的

再次，还需要强调的是，该系统的数据库支持一定程度的自定义：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加column。（具体原因，以后再讲）

随着项目越来越复杂，需求量增多，Pipeline岗位再次被细分，甚至前几年国内都有公司招聘制片TD（在游戏可以理解为配给APM 的TA）

在我查找小黄人那张图片的时候，看到做小黄人的Illumination公司竟然也有招Production Technical Director

Review

主要包含两方面：

• review 工具（如何更好地review）

• 管理和跟踪反馈

美术上传工作内容，总监对其进行反馈；美术拿到反馈继续修改，不断迭代，直到效果通过。

这里涉及的数据表有：

• Task（上个部分中的Task）

• Version（内容一般是图片或视频，美术的一次迭代）

• Playlist（将多个 Version 放在一起的播放列表，方便开 review 会议时查看）

• Note（反馈，一般有文字描述、示意图片、或者其他文件作为附件）

• People（这里指上传 Version的美术/外包公司，和负责 review 的组长或总监）

大概的关系是：

影视的几种Review形式：

• 直接日常线上系统里review，美术/外包随时提交，组长或总监随时反馈，review流程超快

• rounds，直白翻译叫巡视，走一圈：总监带着PM，走到Artist的工位上，直接查看其 DCC 内容，之后协调(APM 的助手) 会将反馈内容记录在系统里

• 正式的 Review 会议，有专业投影仪，标准的色彩显示，有组长、总监、PM，兴许有客户，预先准备好的Playlist进行挨个review，期间有PM 或协调将反馈内容记录到系统里

游戏还会有直接打开游戏，边Play边review，我们的反馈方式就要加上录音、录屏、截图

另外，不得不提一下Client review，就是客户，或者是导演、大大老板、IP方等，在内部已经迭代了不少版，总监觉得已经离定稿不远了，可以拿出来给客户看看。

client review的note需要做隔离，不能直接让相应的美术看到。一方面，确实有语言翻译的原因，另外，还是需要“翻译”一下客户的反馈，再一方面，需要“过滤”一下客户的反馈，懂的都懂哈。

Review系统需要具备的功能

• 可以写文字描述

• 有各种画笔功能，可以直接在画面上涂鸦

• 可以录音、录屏、截图

• Ghost and Hold Annotations（可以把视频其他帧画面的涂鸦半透明显示，适合动画环节 review）

• Live review（多人在线协作review ）

• 多版本对比看：并排着对比、叠在一起对比

• 可以查看历史 Note 反馈

• 可以切换历史Version 版本

• 可以切换其他环节的Version 版本

• 影视：可以看到前后shot，串起来看

• ... ...

没有全部功能都有的产品，各个产品有差异、有自己的护城河，我们可以把某一个功能做的特别好的小软件纳入进来，一起使用，然后将它们反馈信息同步到我们的 Review系统中。

同样的，该部分的软件或者系统必须支持二次开发，我们 Pipeline 在这个部分的主要精力放在了：

• 让美术及时看到反馈，可以是发邮件、发即时消息

• 甚至让美术直接在自己的 DCC 里面看到，把反馈图片贴在场景里

• 根据新的Note反馈，自动创建Task，方便追踪后续是否解决了该反馈

• 美术可以更方便地上传Version

• 批量上传Version

• 视频标准化：画面水印、文件分辨率、文件编码、色彩空间、规范命名......

• 统计：task  有多少个version、多少个note，跟task 的bid比，滞后了还是超前了，反向修正排期，让排期更合理。

• 增加更多格式支持，比如支持3d文件预览

• ... ...

总结

游戏跟影视不同，额外需要有软件开发管理的部分，这部分如果让诸如ShotGrid来管，也不是很合适（虽然它的确有软件开发管理的模块）

所以，可以两个都用，并对关键的数据进行实时双向同步。比如ShotGrid就自带了和 JIRA 的双向同步工具。

这时候，肯定有人说，用两个商业系统，那成本多高啊。

这里他肯定是忽略了隐形成本，因为觉得贵：

就使用excel来管理，带来了协作难题，多版本信息不同步，历史修改丢失，直接影响了生产，这个成本呢？

如果选用了不合适的或者成熟度低的系统，再雇一个TA/TD 来全职开发补齐功能，请问他年包几何，开发能不能按时完成、bug有多少，这个成本呢？

非要Google Docs/腾讯文档，支持协作，也能高级查询过滤，但公式、SQL查询复杂的逆天，PM能不能学会、啥时候能学会、要不要直接招个已经会的，这个成本呢？

当然，再次强调那句话，美术资产量不大，确实没必要。

洋洋洒洒又写了三千多字，竟然还还还还没提到Pipeline的重中之重，资产管理。

本来上面两个部分本不需要提，影视这边稍微有点追求的公司，好赖都有一套，丰俭由人。

但游戏这边.....em.....不得不对APM肃然起敬

难以想象有十几个群，你想找到xxx模型的上周的反馈.......算了不找了......

因为这三个部分的紧密结合，而且前俩还是个重要前提，不阐明这俩的重要性，非常影响第三部分的开发。

其实，能加快美术资产的迭代流程，本身已经能提升不少效率了。