敏捷实践：如何避免我们的营销团队犯的错误

秘密泄露了。敏捷项目管理是一个游戏改变者——开发者和IT人员不再是唯一知道它的人。

作为一名营销人员，你肯定听说过敏捷。你的团队可能正在使用一些敏捷实践，比如项目冲刺和站立会议。如果是这样，你是少数。敏捷的好处在很大程度上还没有被营销团队所利用。根据Workfront和MarketingProfs的一份新报告，只有30%的营销团队使用敏捷方法来管理他们的流程。其他70%的人可能经历了我的团队在我们致力于敏捷工作之前所经历的同样的挫折。

我们在Emplify的七人营销团队已经实践敏捷将近一年了。我们花了六个月的时间才很好地实践了这一点:更好、更快地完成工作，并投入更多的精力和参与。

当我们开始实践敏捷时，我们犯了很多错误。事实上，错误太多了，以至于有一天我们把团队的一半人锁在会议室里，直到我们发现并解决了我们方法中的一些重大缺陷才离开。幸运的是，有啤酒，而且是星期五。尽管如此，这仍然是痛苦的，我们需要时间来挖掘出一些深层次的面向过程的漏洞。

在这篇文章中，我分享了这些错误，这样你就可以避免像我们这样痛苦的锁定。敏捷可以彻底改变你的营销团队的协作能力，更快地交付工作——如果你致力于让这个过程为你服务的话。

在我们开始之前，让我们先了解一些基础知识:

什么是敏捷实践？

敏捷实践(通常被称为“敏捷”)强调在具有可能跨越数周或数月的更大的相互关联的任务的项目上持续交付更小部分的工作(传统上被称为瀑布式管理)。

敏捷基础包括:

Scrum团队: 这个高度协作的团队，在一个scrum master的领导下，解决复杂的问题，并在称为sprints的固定长度迭代中交付解决方案，这可以持续一周到30天。例如，一个处理内容的scrum团队可能会开始一个为期两周的sprint，致力于创建一个新的信息图或数据表。
最低可行产品(MVP): 当计划一个可交付成果时，敏捷原则强调尽可能快地将项目发布出去，这样你的团队就可以尽早对实际问题做出反应。为了实现持续交付的模型，scrum masters鼓励团队定义MVP，并找出最有创造性的方法在sprint的范围内完成产品。例如，如果你开始了为期两周的冲刺，以创作一本电子书作为你的MVP，而你的设计师生病了，你可能会决定将sprint的MVP重新定义为一系列博客文章，并在下一个sprint中设计电子书。
每日站立会议: 团队成员每天早上站成一个圈大约15分钟，讨论scrum团队已经完成的任务、重点领域和可能阻碍他们完成分配的sprint工作的障碍。在sprint结束时，敏捷团队交付一组定义好的项目，然后在下一次sprint中对这些项目进行评估和改进。一些scrum团队也合并了回顾会议，在那里他们讨论可以在下一个sprint中解决的过程缺点。

营销人员为什么要使用敏捷？

国家公共广播电台使用敏捷方法来创建和测试新的节目。在你的下一个“车道时刻”想想这个吧尽管敏捷的根源在于IT管理，但这种形式的项目交付可以应用于企业的许多功能，包括市场营销。

采用持续迭代的敏捷模型可以让您的营销团队快速测试新的消息或活动，更快地对产品更新做出反应，并为向您的团队提出工作要求的利益相关者设定期望。

在我们开始敏捷之旅的近九个月后，我的团队迎来了辉煌时刻，当时我们更新了网站内容，对产品信息进行了一些调整。我们明确了我们在一周内可以完成的工作，并且按时完成了工作。那些我们在冲刺阶段没有时间更新的内容，我们从导航中隐藏了起来。在随后的sprints中，我们一直在不断地添加和更新这些页面上的信息。

应该避免

如果您正在考虑在您的团队中采用敏捷，即使您只是想简化营销团队中的流程，您也会希望避免我们团队犯的以下四个敏捷营销错误:

我们不做功课就自称敏捷。
我们未能指定问题所有者。
我们关注可交付成果，而不是问题。
我们死记硬背，而不是分清主次(并假装我们能完成所有的事情)。

错误1:我们没有做功课就自称敏捷

当我开始和我的营销团队一起工作时，我很快建立了每日站立的习惯，以提供一种快速、无痛的方式来检查项目。我想我在以前的角色中曾经主持过单口相声和组织短跑，所以我有敏捷方面的经验，对吗？不对。

不要像我一样，在周一上班时宣布你正在“变得敏捷”。仅仅因为你在两周的冲刺中工作，并且每天站立，并不意味着你是一个敏捷团队。敏捷的美妙之处在于，它让你的团队有能力共同致力于项目，并在指定的时间范围内定义高质量的可交付成果。如果你只是试图在两周内完成尽可能多的工作，牺牲质量来完成任务，那种美被否定了。

在你的营销团队建立敏捷流程之前，做好你的功课。打开一两本书。我推荐从Jeff Sutherland(许多人认为他是敏捷之父之一)的Scrum和Scott Brinker的《黑客营销》开始。还有，读一些CMI关于敏捷营销的优秀文章。

在你完成了你的家庭作业之后，优先对你现有的过程做一些简单的改变，开始精心设计一个敏捷的方法，为你的团队工作。

错误2:我们没有指定问题所有者

如果下面的场景没有发生，你可以跳过这一节；你已经实现了某种形式的营销过程涅槃，我还没有发现。

剩下的人，想象一下:你完成了一个有明确截止日期的主要团队项目的98%,一个令人惊讶的利益相关者在最后一个小时介入进来，进行了几十次修改。然后，您的团队被迫将项目额外延长两周来解决这些变更，因为没有人可以否认这个涉众是错误的。

还在读书？我想是的。

我们的团队缺乏明确的所有权，这是我们作为敏捷营销部门取得进展的最大障碍。我们被工作压垮了。当多个利益相关者对项目质量进行权衡时，我们感到沮丧。由于最后一刻的编辑和修改，我们没有推出任何东西。

如果你的营销团队和我们的一样，你很难知道项目的最终所有者是谁。谁是交付成果成功的直接负责人？谁为团队可以协调的任务设定可衡量的结果？谁需要这个项目成功，这样他或她最终也能成功？

为了防止最后一刻的返工，我们现在为每个项目指派这样一个人——问题所有者。

每个季度，我们都会为我们的每个主要营销渠道设定一个销售合格的销售线索目标:广告、活动、有机网站线索等等。然后，在我们的团队中，这些渠道中的每一个都被分配了一个负责人，该负责人成为该渠道下任何可交付成果的联系人。

问题所有权对我们的团队来说特别成功，原因有几个:

它把成功的责任放在一个人身上，如果没有达到目标，谁将承担责任。
它迫使渠道所有者尽早发现问题 因此团队可以主动解决这些问题。
它允许整个团队都参与进来 集体讨论解决方案并实施修复。
它赋予一个人力量 指导任何给定项目的质量。

如果你的团队不清楚谁对你的内容项目有最终决定权，那就和你的部门坐下来，问一个简单却极具挑战性的问题:“谁拥有什么？”回答这个问题——并把你的答案记录下来，让所有人都能看到——将会产生不可估量的责任感。

错误3:我们关注可交付成果，而不是问题

对于我们的敏捷团队来说，另一个改变游戏规则的时刻是，当我们不再把我们的工作看作是一组可交付的产品，而开始把我们的工作看作是一组需要解决的问题。

想想你团队中的个人贡献者:开发人员、文案、设计人员和其他类似的实现角色。他们被要求“设计这张幻灯片”或“写这本电子书”的频率有多高，却几乎不知道他们为什么要这样做？

在没有帮助你的团队理解项目背后的真正目的的情况下，简单地在待办事项列表上分配一个任务，会导致没有团队个人投资的暗淡工作。

事实上，缺乏目标导向的工作不仅会对你的营销策略产生严重的影响。在对LinkedIn会员的一项调查中，超过60%没有从事以目标为导向的工作的受访者计划在三年或更短时间内离开他们的公司。

在我们的团队中，我们有一个很强的规则，反对在开始任何项目的时候就在头脑中有一个规定的可交付成果。让我们面对现实吧，利益相关者并不总是知道他们想要什么。解决问题有助于促进协作以获得更好的结果。

相反，我们从一个问题陈述开始每个项目，它遵循一种在开发敏捷世界中通常被称为用户故事的格式。该格式如下所示:

当___________发生时，我想________，这样我们就得到这个可测量的结果:__________。

下面是一个假想项目中这类问题陈述(或用户故事)的例子:

每个项目的问题负责人决定团队将为该项目解决哪些问题。例如，如果网站没有针对某个关键词进行排名，或者如果消息需要为即将到来的贸易展览进行更新，所有者可能会认为这是一个问题。不管是什么问题，问题陈述都不会包含解决方案。在我们决定优先处理一个特定的问题后，我们的团队一起分析这个问题，最终确定一个我们可以在下一次sprint中执行的解决方案。

作为一个团队解决问题让每个人都与结果有利害关系。

此外，这种方法迫使团队发现表面问题背后的痛点，以找到解决核心需求而不是虚荣心要求的解决方案。

例如，我们的销售团队报告说，一些潜在客户没有出席他们预定的演示会议，也没有对重新安排会议的请求做出回应。我们的销售副总裁希望营销团队制作一个动画解说视频，更好地为他们的会议做准备，尽管这样做可能需要几个月的时间。