Skip to content

关于tsdm字幕组工作流管理及规范化改进的提案 #66

Description

@RoyYuan2003

一、前言
本提案所列问题及对策,仅针对目前已有工作模式提出,旨在基于目前尚且完善的工作流进行优化,而非从技术层面上提出革新的理念。因个人认为目前已有模式足以应对绝大多数问题,但缺乏系统架构进行连接,故上交此提案。如若之后技术层有所突破,理应具体问题具体分析。

二、当前存在问题及改进方案
1.入组流程

1.1★制作规范
腾讯文档的制作规范文件,我认为是现阶段最需要修改更新的问题,其一在于可以改善“制作规范只存在于老成员的脑子里,所以需要老成员手把手教新人”的冗杂工作,其二则对于日常工作流程起到一个“纲领”级的指导:对于新人来说有一个可以随时查询并能解决大多数疑点的指导性文件,放在二次元人均社恐的大环境下,显然是比让他们斗胆去问对接的老成员要来得顺畅,而这对于接下来的2.1条目更是具有积极意义的。
制作规范可以以现有模版加入GitHub工作流内容进行修改,而对于无基础从0开始学习的萌新,则应该尝试另起草一份各个岗位所需的教程。

1.2人员对接
本条目占权重极低,不认为是重点问题。

新人入组会遇到老成员招待,是我认为最优秀的一个点,但问卷系统或许有些累赘,以下仅代表个人观点:
我是一个信奉“足够轻巧才能方便使用”的人,问卷系统的内容在我看来,其实完全可以成为一个复制粘贴就能发到聊天窗口里的消息:请问您想担任什么职位或是来学习,请问您是否高中毕业,请问您有工作经验吗,请问您每周能抽出多少时间工作。
因为总会有懒人不去看群公告或者一看到要点链接跳转就不想行动,虽说这也可以成为一种筛选,毕竟愿意工作的人一定会去看,但是这种需要新人和对接人员都反复在两个页面之间跳跃的使用方式可能是不太令人愉悦的。

2.工作流程
2.0★以“集”为工作单位
基于现有的管理相对宽松的工作方式,我想提出一个“集单位制”,将每一集而非一整部作品的人员固定或提前固定,以方便在工作推进时能及时落实任务到个人,而非现在的先通知再报名。当任务可以是其他很多人都可以完成的时候,个人对于任务的重视程度就会大打折扣。

2.1如何让新人敢于接第一份任务
PV组转正的新人对于正剧工作流是完全模糊的,这时候1.1制作规范就能及时发力,或是让对接成员指导新人在新人愿意的前提下接下第一份工作以熟悉工作流。GitHub的了解和掌握不强制要求已成为共识,所以写明白挂载系统怎么用、各分区存储的是什么文件就很重要了。

2.2 ★GitHub工作流的现阶段契合与挂载系统可能存在的优化讨论
首先我们需要明确,GitHub确实优秀,其优点在于能够明显提升工作效率、明确工程历史更改,但访问困难甚至很多地方需要挂梯子访问这件事本身就成为了一个门槛,而学习成本则是雪上加霜。文件挂载系统则比较接近很多组常用的群文件管理方案,易于上手,所以个人认为工作流要不可避免地以文件挂载系统为核心而非GitHub。GitHub可以优化成方便工作的自动化手段,但因为“不强制”,所以不可能成为核心。
基于此我想提出:对文件挂载系统的权限及流程进行更改,同样是“上传文件”这个动作,挂载系统需要在用户进行上传时填写文件位置、用户署名、简报,而文件挂载系统则基于此自动创建一条分支(命名标准需额外讨论)并申请合并,也就是让挂载系统承载GitHub Desktop所能实现的功能,以此让两种操作方式结合。
基于此产生的问题可能有:
(1) 工作人员无法收到对应反馈
对应监制在合并分支时发现问题则及时拉聊天窗口回复
(2) 分支管理混乱
尝试在每个工作环节完成对应工作后合并一次以方便下游环节拿到工作材料。若分支数量过多,可尝试每个作品单独开仓库避免互相干扰。

2.3腾讯文档工作流的必要性及优化
同样是基于“GitHub不强制执行”的前提,GitHub工作表就很难完全让所有人都掌握,除非把监制当驴用什么都让监制写,或者在2.2条目里提出的文件挂载系统优化能够融入GitHub表格(但同样因为2.2里提出的缺点导致GitHub表格不能方便所有人使用)。正因如此腾讯文档表格是不可替代的,必须有一种能让绝大多数人接受的无门槛操作逻辑,也就是腾讯文档表格与文件挂载系统。
至于优化,在我的概念里,腾讯文档表格作为大部分人都能接受的操作方式,本应成为第一手的信源,因此腾讯文档应当强要求个人填写而非自动化,也就是2.4提出的纪律性问题。自动化的部分可以留在GitHub作为留档或核验,但由个人亲自填写的内容更能最大限度地保障正确与工作内容落实。

2.4★★工作流程中的纪律性要求
本条目涉及矛盾极大,需严肃讨论。

在我的设想里,一个顺畅的工作流程应该是:①工作内容发布,监制提醒相关工作人员接稿,②相关工作人员接稿并提醒监制,③工作内容完成,上传文件并反馈监制,④监制收到反馈并提醒下游工作人员接稿,⑤重复②-④若干,⑥完成,发布。
在这个设想中,沟通的意义是重大的。我们不能把沟通的这个步骤放在GitHub上或邮件里,因为同样的原因,这不是现代最适合的交流方式。最简洁、直接的交流方式仍然是工作群,所以在这里引入一条新的管理提案:工作群工作化制。
由于现在的管理制度宽松,以及诸多管理明确提出的“无上下级人人平等”的理念,工作群也是理所当然的可以随便聊天的群,也正因为在聊天中会有很多习惯性的随手@,导致@的提醒强度被不断弱化甚至被直接无视。因此我认为应当尽量减少但并非避免在工作群中闲聊,让工作流程上下文连贯,也能及时提醒各方面负责人。
这里的矛盾同样在于,管理出于“人人平等”的理念不愿意让工作群过于工作化,也不愿意产生明确的领导与被领导地位。但个人认为,工作群的上下级地位从“监制”这个职位出现就已经产生了,因为监制熟悉一整套烤制工作的流程,所以他要对整个项目负责,也有权力分配工作为各部门执行。那么我们不妨就激进一点,既然进了工作群,其实就意味着成员愿意为了这个项目而付出,而成员的工作理应受到来自监制的监督,所以我们只在工作群里强调工作纪律,尤其是2.3里要求工作成员填写腾讯文档表格。
仍然仅代表我个人意见,我觉得这是一个一屋不扫何以扫天下的逻辑,需要先让大家接受这个以人为核心的方案才能方便推进以后可能来到的高自动化。诚挚接受各方人员的批评与指导意见。

3.管理规范

3.0对信息普及工作的优化
同样基于2.4,信息的上传下达理应以群聊作为主体,所以对于需要广泛讨论的问题,善用群通知。虽然这样不可避免的会让管理员的“管理”体现得更明显,但说实话,一方面我们不常遇到这种场景,另一方面管理天天在群里吹牛逼已经足够亲民了。
3.1对“提前填表制”的提案
基于2.0“集工作制”的进一步优化,在新一集的工程开始之前提前询问各个方面工作人员是否有意向承接,提前填表,提前落实工作,以方便工程正式下达时顺畅推进。
3.2对“工作群工作化制”的提案
见2.4。

三、结语
以上,梦到哪句写哪句,作为刚入组的新人斗胆提出这些方案,能力一般水平有限,诚挚接受各方批评与指导意见。

Metadata

Metadata

Assignees

Labels

改进现有功能的优化、新功能开发或功能请求

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions