pipeline, dataflow, workflow 简述

前言

很久没写什么东西,主要也是因为感觉自己的水平不够。所知道的东西也没有什么好写的,索性就不写了。今天心血来潮,就写点什么吧。可能会写得比较片面,毕竟我经历的项目少,实践的东西也不多,是不是有普适性,就不清楚了。

背景知识

如果你所在的团队是一个学生团队或者小的团队,是没有必要去搞清楚这三者的区别的。因为在这样的团队里,沟通不是问题,时间不是问题,效率不是问题。阻碍一个大团队的发展,一般是由于前面所提的三个方面互相制约和影响的。那么理清这三个概念对于大团队的发展有没有什么好处呢?

在顶尖的 CG 电影制作过程中,往往需要几百人的相互协作才能完成。因为每一部电影都有大量的数据要产生,如果要管理好这些数据就需要大量不同方面精专的人才。而且在电影制作中分工会极为细致,后面如果篇幅允许会讲讲为什么会那么细致。一般情况下,如果制作人数低于150人,那么每个环节的分工可能不到10人。一部电影可能会有上千个镜头,那么这10个人就需要平均处理100个镜头。一般情况下,难度比较高的镜头一个月能产出2-3个,难度一般的镜头一个月能产出5-10个,简单的镜头一个月能产出15-25个。

这里可以忽略特别简单和特别难的镜头,一个月一个人的产出量大概是5个镜头。100个镜头平均下来大概需要20个月的时间,也就是大概两年的时间。这里不包括人员的变动,还有一些不可抗因素。

你的困境

上面对于时间的统筹,用的是简单的小学加减乘除,但是现实并不是如此。项目中并不是你简单地往上面堆几个人,工作效率就能去到你想要的程度。

你可以想象一下,如果你的团队里只有10个人,你是可以确保这10个人都能按你的指挥做事。但是当这个数目扩展到了50人,在一天只有短短8个小时的情况下,你平均分下来,每个人只有9.6分钟。现实是你必须管好这50人的将来,以及现在。于是从谈合同,公司的规划,挖人,跟外部团队的沟通就会逐渐占用你大量的时间。这个时间最后会缩短到每个人只有短短的1分钟。在这一分钟里,你没有办法有足够的时间去跟这个人好好聊聊,甚至都不可能知道这个人到底对团队有没有意见,有没有好的建议。最终你会渐渐把时间分配从每个人拉出来分配到具体的人,具体的事情上了。

这时你就需要物色具体的人来领导你的团队。对于管理人员的甄别和使用不在这篇文章的讨论范围,就不去细说了。那么说到这里大概你已经感觉到需要有一个必要措施能够让这些人跟着你的节奏来运行。在技术如此发达的时代,云计算,人工智能超级普及的年代,为什么还需要人和人之间的沟通?直接利用电脑完成这一切事情不就好了么?

这个想法是美好的,但是现状短时间内计算机还无法完成那么高级的任务。

pipeline,dataflow,workflow 是什么?

如果你要管理一个150人以上,甚至几百人的团队,那么时间不够用是家常便饭。在这么庞大的人数面前,你会发现不管是你跟成员沟通,还是成员之间相互沟通都是一件极其奢侈的事情。那么要想把电影制作这件事情推进下去,让每个人都知道自己在整个制作中应该做哪些部分的事情,应该怎么处理?

现在你需要一个强大的 pipeline 管理系统。这个系统不为别的,就是把项目里的所有事情进行分工。不管你按照什么原则去分,最后一定是划分越细致越好,每个人负责的模块越简单越好。然后把所有人的工作内容跟这些划分挂上钩。前提是你不能够自己亲自去分配这些任务。因为你并不了解每个人,也不可能清楚你分配给每个人的工作量是否合适。你也没有时间去管理这些人是否完成工作,是否需要进行催促等等。所以就需要一批人去维护这个 pipeline 管理系统。在不出意外的情况下,一切难题都会分割,然后分配下去,最终完成。

意外总是会无时无刻产生的。你会发现上了管理系统以后,每个环节看起来是独立的,但是他们要想彻底完成一件事情,还是需要合作去做的,于是又回到了奢侈的沟通问题。这个沟通问题一般看起来很诡异,比如说 A 做完了他的任务,但是 B 认为 A 并没有做完,因为实际上 B 在拿到 A 的数据的时候,根本产生不了对应的结果。于是乎,他们起了争执。时间被这种无效沟通占用了。为了缓解这种问题,你会被迫去解决他们之间数据的传输问题,也就是 dataflow 。在 dataflow 里,一般情况会存在检查内容,目的是为了保证上下环节对接的时候,能够得到正确,而且完整的数据。看起来团队的成员之间已经能够完好的工作了,应该可以完成这个项目了。

简单的来说,并不是有了 pipeline 和 dataflow 就足够支撑完一个项目了。因为你根本不知道你的团队效率。你可能需要花10年,或者20年才能做完这个项目。如果雄心勃勃的你能够支撑那么久,不知道你的资金和财团们是否也能支撑那么久。那么你现在有了一个新的需求,那就是要提高团队的效率。比如说 A 环节做得比较慢, B 环节等着 A 环节的东西。那么 B 环节是否永远等待呢?这就涉及了工作的时间安排,也就是 workflow 。 workflow 很有意思,涉及面也比较广。但是总而言之,就是优化工作,或者说是最佳实践。这取决于你赋予管理权利的那帮人,也取决于你招的人的层次水平。

于是乎,现在稍微大一点的 CG 制作团队都会聘请这么一批人来设计以上这三个东西,一般称为 pipeline department。

如何管理这些概念

在 pipeline 管理团队里,一般性认为低于150人的团队,几乎不需要自己开发管理软件。除了市面上已经有的 shotgun,ftrack,cgteamwork,strack 等。他们更重视的是数据流,因为这个部分通常在大部分团队里并不完善。而且浪费大量时间去开发 pipeline 管理工具,而收效甚微,显然也是不明智的。

简单做个算术可以得出这个结论,如果按照目前最贵的 shotgun 来说,150人一年的购买大概在20W左右。自己开发一个 shotgun ,功能完整并且健全的情况下,5人的开发团队大概需要2年的时间。那么按照市面目前平均工资,2个开发者一年的工资已经远远超过了shotgun一年的费用。其实说到这里肯定会有人说了,2年以后,shotgun还要再买。可是开发完成的东西就不用再改进了,资金就节省了。其实稍微懂点开发管理,或者看过开发管理书籍的人会晓得,一个软件的使用寿命会在维护结束后大约1年的时间就结束了。换句话说,也就是你停止维护以后1年时间内,市面上的产品会生产出更多你想要的功能,进而逼迫你不得不进行更新换代,或者再次投入开发。

似乎行之有效的方法是招一个大型的 pipeline 团队去维护 pipeline,workflow。当然,如果你有能力那么做确实会有好处。但是通常情况下,你并没有足够的项目和经费去招揽那么多能人来帮你。所以通常情况下,你会发现你的大部分时间会徘徊于 pipeline,workflow 上面。你做的事情有没有意义呢,肯定是有的,但是几乎没有在你想要做的点上。

当然有效的管理方法,使用更少人的 pipeline 团队,都是可以实现的。只不过基于我目前还没有理顺所有的思路,没办法讲得更细。只能留这么一个大大的问号在这里了,也许有一天等我阅历更丰富了,我可以就这个话题再聊下去。

相关文章

适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题...
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结...
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容...