【案例】我们运营团队在跑迭代,还跑了226期?(流程篇)
2023-12-29 16:05:17
晏瑞宇
|
尽管“敏捷”的概念已经被人翻来覆去讲烂了,我们也还是想再聊聊“业务敏捷”。
先把“业务敏捷”这个概念拆开:
现在已经有很多文章资料告诉我们,开发团队如何转型敏捷、工程实践怎么做、用哪些自动化测试工具提效等等。那非研发团队又要怎么做,才能敏捷起来? 这个话题,我们还是有发言权的。 背景: 我们是新媒体平台运营团队,在2016年8月开始尝试以Scrum的形式运作。团队成员目前为10+1+N(10名全职人员、1个活跃IP、N名兼职人员),主要包括文案、设计、视频三类职能角色。 我们刚开始尝试应用敏捷时,并没有完全复制研发部门同事的流程,而是先自己慢慢摸索。每一期迭代,我们都会进行细微调整,不断地实践尝试,例如改进会议议程,引入一些新实践方法等等,在充分认识到新方法的实际效果后才继续实践该方法。自2016年至今,我们已经跑了200+期迭代,逐步摸索出一套能将敏捷与运营工作相结合的高效工作模式。 转型阶段: 总体来看,从团队组建到现在,我们的转型过程一共经历了四个阶段: 1.起初,我们通过每日待办进行管理,但这种管理方式暴露出来的问题是:待办管理无法做短期、长期任务规划,只能跟进、记录最近一两天的任务,无法合理地进行长期规划。 2.于是我们进入了第二阶段:通过禅道自研的ZDOO全协同办公软件进行任务管理。这种管理方式确实解决了短期任务跟进以及短期任务计划的问题,不过在管理过程中,我们还是发现,需求管理方面的承接稍显不足:那些不同来源反馈的需求或者问题,我们如何记录?如何管理? 3.第三阶段:既然我们是做项目管理软件的,那研发团队能用禅道,非研发团队肯定也能用起来!抱着这个想法,我们尝试转用禅道进行项目管理。最初用禅道时,我们会面临一个选择:用Scrum模型还是用瀑布模型?后面考虑到运营工作比较多为周期性的工作,那不如试试Scrum模型吧。 4.第四阶段:随着对项目管理实践的逐渐了解,我们开始结合看板管理方法,不断优化工作流程。接下来看看我们是如何将敏捷落地到运营工作中的。 落地过程: 一、建立项目集为了方便从高层视角进行资源协调与统筹,我们会把一组相关的项目归纳为项目集。以我们公司为例,公司内部的运营团队包括:
每个团队会根据实际业务,分别建立相应的项目,并通过项目集“蒸蒸日上”进行统一管理,这样能够更方便、及时地跟进项目状态。 二、建立项目在考虑了时间、人力资源以及目前工作项的情况下,我们决定以月为单位建立项目。相当于以月为单位进行整体交付。不过由于运营工作性质比较特殊,基本上,我们输出的内容通过评审后就会按排期发布,因此每个月项目结束后,我们的交付成果主要为各媒体平台的数据统计。 (目前正在进行中的项目名称为“新媒运营2023年11月项目”) 三、找甲方新媒体平台运营工作多为周期性、事务性工作,其实我们的工作没有真正意义上的“甲方”。虽然这样说,但为了交付有价值的内容,为产品进行引流推广,我们还是需要明确:我们的目标受众是谁?
当然,不管是哪一方面,老板的建议与需求自然不能忽略(谁让我们的老板是资深产品经理呢)。 四、落地Scrum的各项事件那前期的种种准备工作都做好了,接下来就要着手落地Scrum的各项事件了。1.明确需求,梳理待办事项列表在项目开始之前,我们需要明确需求。可能大多数人在这里会有一个误区:运营团队也会有需求?像我们比较熟悉的研发团队和产品团队,他们最终交付的可能是一个产品/产品增量,而运营团队交付的则是一篇文章、一个视频、一张设计稿甚至是一本书等等。从这个角度看,我们在某个固定的时间盒内,会对外交付多个“产品”。 那既然交付的都是产品,产品需求自然也不能少,那就以最近我们在做的某个大会的宣传视频举例,我们通过与各个相关人的讨论和沟通,明确了视频应该聚焦产品某一功能的需求、视频应该突出各个社区的需求、视频需要体现公司文化的需求等等,再加上我们对参会用户的分析,也明确了视频需要用哪种基调才能吸引用户。这些在沟通分析过程中出现的建议与方向,自然成为了我们这一宣传视频的“产品需求”。 当然,由于我们产出的内容方向较多,需求管理也是我们必不可少的一环。日常中,我们通过头脑风暴、问卷调查、与团队成员以及相关人员沟通讨论等方式来收集需求,按照用户故事的要求记录在禅道的需求模块中,让需求更清晰、明确、可追踪。 对运营团队来说,待办事项大致可以作如下划分:
2.制定迭代计划需求明确了,接下来我们就要开始制定迭代计划了。每期迭代开始时,我们都会先在禅道中创建本期要做的一些周期性常规任务、认领从需求拆分出来的待办任务,例如书籍出版、活动、文章/新闻稿的撰写与发布、视频剪辑、社群运营等等,并对任务进行工时预估、排列优先级。 由于我们的任务中有一定的比例都是临时性任务,因此在每期迭代中,我们的任务工时通常不会排满,需要预留出一部分时间。在迭代过程中,部分优先级较低的临时性任务会被放入待办事项列表中,等待在后面的迭代中安排。 3.每日站会:跟进任务状态每天早上,在开始一天的工作之前,我们会围成一圈开一个简短的站立会议:团队成员站着轮流介绍自己的工作进展,主要包括三个方面:
这种形式不仅能了解每个成员的进展情况,还能发现团队的潜在问题,及时进行必要的调整与协调。 4.迭代回顾会:总结改进项,输出改进建议这是一个非常简单、也非常重要的环节——回顾会议。回顾会议能够帮助我们对过去一个迭代内做的工作进行复盘,实现持续改进。通常我们会在每周五下午召开回顾会议,时长一般不会超过45分钟(毕竟会议一长,会议的效果也就会直线下降)。 在回顾会议中,我们会分享:
在回顾会中,我们更倾向于突出个人的闪光点,改进团队的整体不足,而不会将问题责任归于某一个人的身上。这样每个人都能有意识地评估所做的工作,了解自己所创造的价值,更好地实现团队协作。 (谁会不喜欢被夸夸呢?)
但……做到这些,就能真正跑起敏捷了吗? 要说有问题吗,也有。比如跑了一段时间迭代,我们发现迭代燃尽图总是在飙升,投入产出比不高、团队协同也开始出现了一些问题,站会开始沦为形式……怎么办? |
晏瑞宇 最后编辑, 2024-01-03 13:19:21