ftrack/ShotGrid/CGTeamwork：流程管理工具选型对比

每次聊到流程管理总会有人把ftrack、ShotGrid和CGTeamwork这三个名字摆到一起问我到底该选哪个。说实话工具参数表我背得再熟也很难直接给一个标准答案这三款产品虽然都叫制作跟踪工具但底层思路完全不是一回事。ftrack让人最舒服的是“审片反馈”闭环打开浏览器就能和异地合伙人同步批注ShotGrid则像一张自由度极高的生产数据大表适合有人专门维护流程的大型团队CGTeamwork把任务分配和文件交接这些国内工作室最没耐心的环节做得极轻。我在不同项目里把三款都亲自推过、改过、踩过坑这篇就按实际使用体验聊聊怎么选才不至于项目做到一半想换系统。1. 三个工具三种管理哲学1.1 别急着比功能先看团队是怎么工作的很多团队选工具时喜欢拉功能对照表比谁家的控件多、谁家字段全。我后来发现这个思路容易带偏。ftrack的设计前提是“所有人都围绕审片反馈来协作”它把所有功能都往Review上面收拢ShotGrid的前提是“生产数据应该像数据库一样可查询、可关联、可统计”所以它提供海量自定义字段和视图CGTeamwork的前提更朴素“把活派下去、把文件传到位、把完成进度数清楚”把复杂度留在界面之外。换句话说三款工具根本是在解决不同层次的问题。如果一个二十人的动画小组核心痛点是导演和外包团队每天要花两小时开视频会审片那ftrack的媒体审查几乎是为这个场景量身定做的。如果一个百人规模的制作公司需要同时管理资产、镜头、版本、任务、权限、发布记录并且有专门的流程TD去维护数据规范那ShotGrid的灵活模型更好发力。如果团队多数成员不擅长用新软件只是想找个带进度管理的派活工具CGTeamwork的轻量和中文界面能省掉大量培训成本。我给了一个比喻ftrack像一间带专业审片室的办公室ShotGrid像一套可自由拼装的生产管理系统CGTeamwork像一个剧组用的任务白板。三样东西都能帮上忙但买错类型越大越难受。1.2 三个项目里试了三套方案为了避免纸上谈兵我说说我实际接触过的三种场景。A项目是一个二十多人的动画短片组周期三个月导演和主美在不同城市办公。我们最后用了ftrack的云端版本把所有镜头、资产、任务和审片都放进去。导演每天晚上把意见画在Review评论里第二天美术打开软件同步任务效率提升非常明显。B项目是一个中大型长片项目人数接近百人有资产、绑定、动画、灯光、特效多个环节制片还要求每周出一份跨环节进度表。那个项目沿用了ShotGrid。数据模型够强各种视图和筛选能满足制片需求但配置工作量和日常维护压力都不小。C项目是一个外包比例很高的游戏美术组核心团队三十人外包分布在不同地区。团队最终选了CGTeamwork理由是上手快美术外包只需要装个客户端就能接收任务、上传文件、看到进度不用学一堆流程概念。三个项目跑下来我才真正确认了那句话流程工具选型本质上不是技术问题是团队管理和协作习惯的匹配问题。2. ftrack使用体验这些细节决定流程能不能跑起来2.1 项目架构设计模板带来的秩序感与约束感ftrack里有个核心概念叫Architecture也就是项目空间的任务层级模板。默认思路是从Project项目往下挂Episode剧集或Sequence场次再挂Shot镜头和Asset资产最底层挂Task任务。这个结构比ShotGrid更“强制性”好处是新人不会把层级建乱坏处是遇到非标准资产时需要手动调结构。我在第一个项目里就碰到了这类问题。比如某个特效镜头既要出角色模型又要出镜头专用场景默认模板里没有这个组合软件层面又不像ShotGrid那样可以自由造Entity类型于是需要我们自定义Schema把Task类型配好再给对应镜头单独挂资产。这块的配置经验是前期花半天时间和制片一起把“最小任务层级”定清楚不要什么环节都开Task。像灯光环节内部的“内部自检”放到任务备注里即可否则看板会堆满状态标签反而看不清关键卡点。另一个需要留意的点是Task状态流转。ftrack默认提供的状态通常就是“未开始、进行中、待审、审核中、完成、失败”这一套。我们当时按自己项目习惯改了状态名结果发现导出报表时状态字段的映射逻辑跟着变了统计口径对不上。所以改状态前最好先和负责统计的人确认字段语义别让流程系统变成了一个需要解释数据的额外工作。2.2 Review与异地审片比预期更重要的一环ftrack最让我意外的不是任务跟踪而是内置的Media Review。打开一个镜头可以直接加载视频、序列帧甚至多版本并排播放用绘图笔在上面批注评论会按帧号和图层保存下来。异地导演第二天打开同一视图所有批注都在不需要再开视频会议对着画质稀烂的会议软件沟通。但Review用起来有几个实操上的坑。第一转码问题。第一次我们往里面直接传了高码率的序列帧和MP4结果转码队列排队排了一个多小时导演那边刷新半天看不到画面。后来统一改成低码率的代理文件传上去再把原片放在文件服务器里情况才有改善。转码参数别选太低不然放大看细节时糊成一团批注就没意义了。第二打点偏移。不同软件之间帧号起点不一样Maya、Nuke和剪辑软件对同一镜头的帧号定义经常有偏差。如果在Review里直接用默认时间轴打点很容易出现“意见标在了错位帧上”的情况。我后来要求所有上传版本在文件名里带上起始帧信息并统一软件工程帧起始一致批注错位的问题就基本消失了。第三权限要留神。ftrack的角色权限可以控制谁能访问Review页面。有一次我图省事给外部审核角色只勾了“查看任务”权限结果对方打开镜头一片空白以为我们没传素材。检查后发现是Review模块权限没开。权限配置完一定要用测试账号走一遍审片流程别只看后台有没有权限树。2.3 用Action和API搭自动化光靠界面手动点流程工具用半个月就会让人失去耐心。ftrack提供了Python API和Action机制Action简单说就是在界面上注册成“按钮”的服务点一下就会执行一段脚本。我们当时用Action做了两件很基础的事把本地文件注册到当前任务版本以及一键把任务状态从“待审”推进到“最终”。一个最简单的Python会话大概是这样的import ftrack_api session ftrack_api.Session() # 查询项目 project session.query(Project where full_name is demo_project).one() # 查询该项目的所有任务 tasks session.query(Task where project.id is {}.format(project[id])).all() for task in tasks: # 输出任务名称和当前状态 print(task[name], task[status][name]) session.close()写Action时候最后悔没早点做的一件事把所有Action的日志输出到文件里。因为Action如果脚本报错网页端经常只返回一个笼统的失败信息具体情况要看服务端日志。我们第一版Action偶发失败网页上看不到原因排查了好久才发现是文件路径里中文目录导致的编码问题。把日志落盘再遇到问题十分钟内就能定位。体验下来API文档写得不错但曲线不算平缓。如果你没用过这类API别急着写复杂Action先跑通一个查询再试着创建Task最后再做状态流转一步一步来坑会更少。2.4 私有化部署背后的维护账ftrack有云版本和Server版本前者官方托管后者要自己部署到CentOS或RHEL服务器上并且依赖MySQL、Nginx等一系列组件。我们其中一个阶段考虑过Server模式理由是数据不出内网。但评估下来TIM每月的补丁更新、数据库备份、转码资源规划都要专人跟进不是装上就完事。后来确实用上了Server模式感受是如果你没有一个愿意周末更新补丁的人这个维护成本是实打实的负担。数据备份这件事不能只做数据库备份ftp存储目录、转码缓存、用户上传附件都要纳入备份范围。我曾见过只备份数据库、没备份媒体文件的案例结果服务器故障后任务结构都在但所有Review评论对应的版本文件全丢了等于审片脑白质被挖走。如果团队规模不大也没有硬性要求数据必须留内网我建议直接上云版本把精力留给流程设计。3. 换上ShotGrid和CGTeamwork后真实差别比参数表更大3.1 ShotGrid的自由度与维护成本ShotGrid以前叫Shotgun在VFX和动画行业沉淀多年它的强项是数据模型自由度。几乎所有Entity都能加字段字段之间能做各种关联还有Pipeline Configuration这套框架让TD可以按项目定义加载项、工作区模板、自动命名规则。简单说它是可以“造体系”的工具。但自由度是有代价的。没有TD带队的中型团队很容易把ShotGrid用成一张没人维护的大型Excel。有一次我们想配置一个“模型审核未通过自动退回动画环节”的规则涉及状态枚举、字段联动、hook脚本前前后后调试了两天确实能做但复杂度远远超出预期。对比起来ftrack的Action逻辑更轻CGTeamwork则基本不提供这么细的控制面。另外海外云服务对国内团队的访问延迟问题很现实。美术同事上传文件、刷新页面时经常会遇到转圈。后来团队加了加速或换网络才勉强可以接受但这类网络层面的事情不应该由制作团队来操心。ShotGrid对需要自由建模和深度自动化的中大型团队而言仍旧是首选。它适合那些已经有流程规范、有人专门维护的成熟团队不适合从零开始、没有TD的团队。3.2 CGTeamwork的轻量与务实CGTeamwork给我最直观的感受是“不端着”。它的菜单基本都是中文美术外包装上客户端就能看懂。任务分配、文件上传下载、状态更新、消息提醒整个闭环做得很直白。团队里老一辈制作人员也能很快上手。它解决的是国内工作室最常见的痛点沟通靠喊文件靠手动拖进度靠日报。用上CGTeamwork之后至少派活、文件交接和状态同步这三件事有了固定渠道。审批逻辑也不需要像ShotGrid那样搭体系界面本身就很近似国内软件的习惯。当然它的局限也很明显。数据模型相对简单想在“镜头级资产”和“版本责任归属”之间做复杂检索比较吃力。审查功能更适合粗看文件做不到ftrack那种帧级批注的粒度。API和插件生态也偏封闭跨软件自动化基本靠官方提供的插件和自己写独立脚本和另两款工具的开放性不是一个量级。适合CGTeamwork的团队画像我总结是国内项目为主、外包比例高、没有专职TD、需要一个月内让全组跑起来。会有上限但解决80%的日常问题。3.3 三种团队怎么选我在项目里慢慢形成了一个选型判断供参考团队规模20到50人动画或广告项目为主有人负责流程维护选ftrack。团队规模100人以上长线项目多数据模型自由度和自动化需求高选ShotGrid。团队以外包接包和内部管理为主希望快速上手、少维护选CGTeamwork。这个判断不是定死的。国内很多团队也会混用内部流程用CGTeamwork管派活审片环节单独用ftrack数据台账用ShotGrid做统计分析。但混用会带来数据割裂除非你确实需要不同工具解决不同环节的问题否则不太建议一开始就搞多系统并存。4. 横评对照表与迁移成本4.1 一张表看完三款工具对比维度ftrackShotGridCGTeamwork核心定位审片反馈 任务跟踪全链路生产数据管理轻量任务分配与文件交接数据模型架构式层级清晰但约束多自定义Entity与字段自由度极高简单模型贴近常规任务列表部署方式云版 自托管Server版云端托管为主可本地私有化客户端模式常用报价模式订阅制按用户档位计费订阅制按用户计费按人数和期限的授权方式审片能力内置Review包含帧级批注与同步基于集成播放器进行版本审查流程靠配置基础文件查看批注粒度较粗API与自动化Python API、Action、Webhooks丰富API、Hook与Pipeline Config开放程度有限以官方插件为主中文支持一般以英文界面为主一般原生中文界面学习曲线中等审片功能容易上手深度功能需钻研偏高没有TD较难发挥低美术外包可快速适应适合规模中小型团队、分布办公中大型团队、有流程维护能力国内中小团队、外包协作多这张表不是要分高低而是用来做快速排除。比如你团队最关心审片反馈那ShotGrid再强也得先确认自己是否愿意花精力把审查流程配置出来。而如果团队连角色权限模型都懒得研究CGTeamwork上手确实更快。4.2 换工具的隐性成本换流程工具最大的成本不是软件授权费而是迁移过程中的历史数据和用户习惯。历史数据里最重要的是“版本与审片记录”因为这属于无形资产。我们当年从旧工具换到ftrack时想把过去项目里的评论和备注导出来结果发现旧格式的时间戳、用户ID和当前工具对不上最后只导出了纯文本评论和帧号的关联全丢了。作为教训建议在换工具之前先做一次数据导出测试别等老平台即将下线时才害怕。用户习惯同样费时间。老同事用惯了旧界面的看板式视图换成ftrack的表格视图后每天都会有人问“我这个任务怎么跑到这个状态里了”培训成本远高于预期。这里给一条经验换工具期间新旧系统并行运行两个星期所有任务以新系统为准旧系统只读不写能大幅度减少适应期混乱。4.3 小团队月内落地的简化路径如果团队在30人以下又没有专职TD我推荐一条简化落地路径直接上ftrack云版先不要碰Action和复杂自定义Schema用默认的项目模板跑通流程。顺序是这样的第一天建好项目和用户分配好角色第三天让各组把任务补录进去把资产上传、版本创建这些基础操作跑顺第一周导入一批真实镜头做一次完整的Review流程第二周根据反馈微调状态枚举和默认页面布局第三周开始接Webhooks比如任务状态变化后自动通知到企业微信群替代一开始想做的复杂自动化。这样一个月内团队就能稳定使用风险小、见效快。等稳定几周后还能再用API把数据导出到自己公司的数据看板里做更细的统计。这时候你会发现比一开始就想搭建所有功能靠谱得多。5. 一些实在的收尾建议5.1 如果只保留一个功能我选审片记录用过的工具多了以后我最深的感受是流程系统的价值不在任务看板在“决策可追溯”。那次美术改了一版镜头导演说“这不是我上次批注的样子”结果大家翻聊天记录、翻网盘、翻邮件折腾了一个小时最后在审片评论里找到原话。有了帧级批注和版本关联这类沟通成本能大幅下降。选工具时我建议优先看重这个能力而不是谁家状态栏更好看。5.2 我踩过之后不会再踩的三个坑第一权限配置过紧。流程工具越管得严越没人愿意用。上线初期尽量把审核角色的权限放宽等运行顺畅后再逐步收紧。第二转码格式不测试就上线。多人审片场景一定要提前用真实素材跑一遍代理文件转码确认各人的电脑都能流畅播放而不是等到导演开始批注了才发现卡成幻灯片。第三自动化和手工操作混用。如果同一种任务有时候用Action自动流转、有时候人工拖拽状态数据会有双份逻辑统计报表就说不清了。要明确分工哪类任务走自动化、哪类任务走人工写在一页纸上所有人都遵守。这也是我在这个项目里得到的最大教训。如果问我现在自己会怎么选我的答案很直接看有没有人愿意为流程操心。有人选自由度高的ShotGrid或者功能最顺手的ftrack没人选能让所有人平稳接手的CGTeamwork。工具只是把大家的协作习惯固化下来真正把流程跑起来的永远是团队自己。