禅道博客

分享专业技术知识,文章内容干货满满

【案例】我们运营团队在跑迭代,还跑了226期?(流程篇)

2024-01-02 08:48:46
晏瑞宇
原创 511
尽管“敏捷”的概念已经被人翻来覆去讲烂了,我们也还是想再聊聊“业务敏捷”。

先把“业务敏捷”这个概念拆开:
  • 业务”很明显,就是公司的收入来源。不过要想让收入实现持续增长,我们的业务就需要“为客户的需求而生”,能够为业务增值的是产品线上的每个团队;
  • “敏捷”则是能预测、及时满足客户和市场的需求变化
一个组织的敏捷程度取决于它最不敏捷的团队。因此,要想做到业务敏捷,我们就要关注“木桶理论”的重点:抓短板

现在已经有很多文章资料告诉我们,开发团队如何转型敏捷、工程实践怎么做、用哪些自动化测试工具提效等等。那非研发团队又要怎么做,才能敏捷起来?

这个话题,我们还是有发言权的。


背景:
我们是新媒体平台运营团队,在2016年8月开始尝试以Scrum的形式运作。团队成员目前为10+1+N(10名全职人员、1个活跃IP、N名兼职人员),主要包括文案、设计、视频三类职能角色。
我们刚开始尝试应用敏捷时,并没有完全复制研发部门同事的流程,而是先自己慢慢摸索。每一期迭代,我们都会进行细微调整,不断地实践尝试,例如改进会议议程,引入一些新实践方法等等,在充分认识到新方法的实际效果后才继续实践该方法。自2016年至今,我们已经跑了200+期迭代,逐步摸索出一套能将敏捷与运营工作相结合的高效工作模式。
转型阶段:
总体来看,从团队组建到现在,我们的转型过程一共经历了四个阶段:
1.起初,我们通过每日待办进行管理,但这种管理方式暴露出来的问题是:待办管理无法做短期、长期任务规划,只能跟进、记录最近一两天的任务,无法合理地进行长期规划。
2.于是我们进入了第二阶段:通过禅道自研的ZDOO全协同办公软件进行任务管理。这种管理方式确实解决了短期任务跟进以及短期任务计划的问题,不过在管理过程中,我们还是发现,需求管理方面的承接稍显不足:那些不同来源反馈的需求或者问题,我们如何记录?如何管理?
3.第三阶段:既然我们是做项目管理软件的,那研发团队能用禅道,非研发团队肯定也能用起来!抱着这个想法,我们尝试转用禅道进行项目管理。最初用禅道时,我们会面临一个选择:用Scrum模型还是用瀑布模型?后面考虑到运营工作比较多为周期性的工作,那不如试试Scrum模型吧。
4.第四阶段:随着对项目管理实践的逐渐了解,我们开始结合看板管理方法,不断优化工作流程。
接下来看看我们是如何将敏捷落地到运营工作中的。

落地过程:


一、建立项目集

为了方便从高层视角进行资源协调与统筹,我们会把一组相关的项目归纳为项目集。

以我们公司为例,公司内部的运营团队包括:
  • 新媒体平台运营团队——负责公司及产品媒体矩阵的运营;
  • 市场活动运营团队——负责市场活动与推广工作;
  • 社区运营团队——负责各个社区与社群的日常运营。

每个团队会根据实际业务,分别建立相应的项目,并通过项目集“蒸蒸日上”进行统一管理,这样能够更方便、及时地跟进项目状态。

二、建立项目

在考虑了时间、人力资源以及目前工作项的情况下,我们决定以月为单位建立项目。相当于以月为单位进行整体交付。

不过由于运营工作性质比较特殊,基本上,我们输出的内容通过评审后就会按排期发布,因此每个月项目结束后,我们的交付成果主要为各媒体平台的数据统计。

(目前正在进行中的项目名称为“新媒运营2023年11月项目”)


三、找甲方

新媒体平台运营工作多为周期性、事务性工作,其实我们的工作没有真正意义上的“甲方”。虽然这样说,但为了交付有价值的内容,为产品进行引流推广,我们还是需要明确:我们的目标受众是谁?
  • 如果是为了传播项目管理知识,我们产出内容的目标受众是行业相关从业者;
  • 如果是宣传产品功能特点,我们的目标受众则是各大IT、互联网公司的管理者(简单来讲,就是能做决策的人);
  • 如果是为了引流,我们的目标受众就会变成热衷于网上冲浪用户群体;
  • ……
通过明确目标受众,我们会更好地理解他们的需求和期望,从而针对不同受众,提供不同价值的内容。

当然,不管是哪一方面,老板的建议与需求自然不能忽略(谁让我们的老板是资深产品经理呢)。

四、落地Scrum的各项事件

那前期的种种准备工作都做好了,接下来就要着手落地Scrum的各项事件了。

1.明确需求,梳理待办事项列表

在项目开始之前,我们需要明确需求。

可能大多数人在这里会有一个误区:运营团队也会有需求?像我们比较熟悉的研发团队和产品团队,他们最终交付的可能是一个产品/产品增量,而运营团队交付的则是一篇文章、一个视频、一张设计稿甚至是一本书等等。从这个角度看,我们在某个固定的时间盒内,会对外交付多个“产品”。

那既然交付的都是产品,产品需求自然也不能少,那就以最近我们在做的某个大会的宣传视频举例,我们通过与各个相关人的讨论和沟通,明确了视频应该聚焦产品某一功能的需求、视频应该突出各个社区的需求、视频需要体现公司文化的需求等等,再加上我们对参会用户的分析,也明确了视频需要用哪种基调才能吸引用户。这些在沟通分析过程中出现的建议与方向,自然成为了我们这一宣传视频的“产品需求”。

当然,由于我们产出的内容方向较多,需求管理也是我们必不可少的一环。日常中,我们通过头脑风暴、问卷调查、与团队成员以及相关人员沟通讨论等方式来收集需求,按照用户故事的要求记录在禅道的需求模块中,让需求更清晰、明确、可追踪。
通过需求管理,我们能更快速地梳理待办事项列表。

对运营团队来说,待办事项大致可以作如下划分:
  • 周期性任务:包括长周期任务,比如出版书籍、每年固定的节假日活动(1024程序员节)等等;短周期任务,比如固定周期进行文章以及视频发布、社群运营、活动发布与回顾等等。
  • 时性任务:包括可预测型任务,比如活动宣传海报的调整;无法预测型任务,比如临时的报表、BP、PPT制作等任务。
梳理完上述任务,我们从任务性质与任务周期出发,选择将团队的迭代时间盒设置为一周(5各工作日),便于任务跟进、迭代复盘。

2.制定迭代计划

需求明确了,接下来我们就要开始制定迭代计划了。

每期迭代开始时,我们都会先在禅道中创建本期要做的一些周期性常规任务、认领从需求拆分出来的待办任务,例如书籍出版、活动、文章/新闻稿的撰写与发布、视频剪辑、社群运营等等,并对任务进行工时预估、排列优先级。

由于我们的任务中有一定的比例都是临时性任务,因此在每期迭代中,我们的任务工时通常不会排满,需要预留出一部分时间。在迭代过程中,部分优先级较低的临时性任务会被放入待办事项列表中,等待在后面的迭代中安排。

3.每日站会:跟进任务状态

每天早上,在开始一天的工作之前,我们会围成一圈开一个简短的站立会议:团队成员站着轮流介绍自己的工作进展,主要包括三个方面:
  • 我昨天做了什么?
  • 我今天计划做什么?
  • 有什么问题阻碍了我?
  • ……
定期进行每日站会,其实帮助我们发现了不少问题,比如有的同事连续几天都在做同一个工作,就需要在会后深入了解一下,是不是出现了什么问题,或者需不需要其他伙伴的帮助等等。

这种形式不仅能了解每个成员的进展情况,还能发现团队的潜在问题,及时进行必要的调整与协调。

4.迭代回顾会:总结改进项,输出改进建议

这是一个非常简单、也非常重要的环节——回顾会议。

回顾会议能够帮助我们对过去一个迭代内做的工作进行复盘,实现持续改进。通常我们会在每周五下午召开回顾会议,时长一般不会超过45分钟(毕竟会议一长,会议的效果也就会直线下降)。

在回顾会议中,我们会分享:
  • 本期迭代的相关数据;
  • 在迭代中遇到的问题;
  • 本期迭代中大家做得好的地方。
同时,我们会在每月月底对当月数据进行一次月度回顾。在回顾会议中,大家通过提出问题、共创解决方案,及时进行团队沟通,能够有效解决协作过程中产生的种种问题。


在回顾会中,我们更倾向于突出个人的闪光点,改进团队的整体不足,而不会将问题责任归于某一个人的身上。这样每个人都能有意识地评估所做的工作,了解自己所创造的价值,更好地实现团队协作。

(谁会不喜欢被夸夸呢?)

但……做到这些,就能真正跑起敏捷了吗?

要说有问题吗,也有。比如跑了一段时间迭代,我们发现迭代燃尽图总是在飙升,投入产出比不高、团队协同也开始出现了一些问题,站会开始沦为形式……怎么办?


这里先卖个关子,预告下一篇文章《运营团队跑迭代之实践篇》。关注我们,继续了解运营团队是咋做敏捷的!
暂时没有记录
评论通过审核后显示。