【案例】我们运营团队在跑迭代，还跑了226期？（流程篇）

尽管“敏捷”的概念已经被人翻来覆去讲烂了，我们也还是想再聊聊“业务敏捷”。

先把“业务敏捷”这个概念拆开：

“业务”很明显，就是公司的收入来源。不过要想让收入实现持续增长，我们的业务就需要“为客户的需求而生”，能够为业务增值的是产品线上的每个团队；
“敏捷”则是能预测、及时满足客户和市场的需求变化。

一个组织的敏捷程度取决于它最不敏捷的团队。因此，要想做到业务敏捷，我们就要关注“木桶理论”的重点：抓短板。

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

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

背景：
我们是新媒体平台运营团队，在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.制定迭代计划

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

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

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