您是否感觉您的SEO建议和项目在混乱中被遗漏或被其他团队降低优先级？

如果您在公司内部工作，那么在为您的优化工作获取适当的资源并加以实施时，您可能会体验到“害怕错过”（FOMO）的感觉。

好消息是，一种名为“敏捷”的项目管理方法可以帮助跨职能团队自我组织并更有效地协作。

通过了解敏捷仪式（会议）和流程，您可以更好地融入和影响开发周期，以确保您的 SEO 要求不会被忽视。

在本文中，我们将介绍敏捷方法的关键方面，规划您应该参加的各种敏捷会议，并提供有关如何编写有效票证和验收标准的提示，以便您的 SEO 更改得到优先处理和启动。

告别 FOMO，开始通过敏捷流程的力量完成您的 SEO 工作。

敏捷项目管理如何阻止 FOMO

敏捷方法使您成为团队完成任务的一部分。 

人工智能可能正在流行，但我相信敏捷框架将会经久不衰。与依赖人工智能或软件智能的人工智能不同，敏捷依赖于团队如何自然地组织起来完成任务。

它优先考虑有形的功能和改进。越来越多的主要技术团队开始采用敏捷方法，因为它能够提高业务价值和管理复杂项目的效率。

敏捷方法的快速概述

敏捷项目管理是一种将项目工作分为小的增量部分进行管理的方法，这些部分可以在称为迭代或冲刺的短时间内轻松分配、轻松管理和完成。 

传统上，项目管理采用瀑布式方法。在这种方法中，所有工作都是在前期完成的，之后再收集客户反馈。

该过程可能需要数月才能完成，这并不总是理想的，特别是当您想在竞争对手之前向市场发布产品 MVP 时。（听起来很熟悉？） 

敏捷风格更具迭代性，因为工作旨在在短周期（冲刺）内完成，其中反馈和改进（对产品本身和所涉及的团队）被融入到流程中。 

敏捷起源于软件开发领域。其关键要素包括： 

• 计划
• 递送
• 学习

就上下文而言，这是敏捷软件开发的宣言： 

敏捷建立在12 条原则之上：

我最喜欢的是： 

• 在整个项目过程中，业务人员和开发人员必须每天一起工作。
• 持续关注技术卓越性和良好设计可提高敏捷性。
• 团队会定期反思如何提高效率，然后相应地调整其行为。

看到了吗？当团队使用敏捷时，沿途的每个人都会成为从事实际工作的团队的一部分。大家齐心协力，成就大事。

敏捷原则本质上是关于协作和持续改进。任何组织都可以使用这种方法进行精益思考和运营，从而为客户提供价值。 

在之前的文章中，我提到了敏捷方法以及如何使用 Scrum 框架来执行它。

基于 Scrum 的流程非常适合处理大型或复杂的解决方案，因为它具有迭代性，可以快速进入市场。它使团队能够从客户反馈中学习并不断改进。

另一方面，看板和瀑布方法通常采用更线性的方法。 

核心敏捷团队通常由以下人员组成： 

• 一名产品经理。
• 项目/计划经理。
• 来自工程、用户体验、QA 和 SEO 等 SME 等支持团队的领导。 

在这种结构下，每日和每周的仪式（或会议）有助于每个人协调工作并推动事情向前发展。

这项工作旨在在规定时间内完成，通常为 1-2 周。给定冲刺中的所有票证都应在该时间内完成，以便团队达到其期望的速度。 

深入挖掘：SEO 产品管理：关键框架和基础知识

这是一个连续的循环。因此，使用所谓的敏捷发布列车可以实现渐进式改进。

对于电子商务网站，这些团队改进了产品详细信息页面、现场搜索功能或结帐流程等方面。 

---

如何融入敏捷团队 

从概念上讲，这是关于理解使用敏捷的跨职能团队的工作流程。现在，SEO 专业人士 Aleyda Solis写道： 

“将 SEO 与你的网站开发、设计和产品团队的目标和目的结合起来，有助于让每个人都保持一致。这将使你能够确定优先考虑 SEO 需求的最佳方式，并与其他团队的同事制定行动计划，让每个人都步入正轨，朝着同一个方向前进。例如，如果网站开发团队以冲刺的方式工作，那么了解每个冲刺的时间长度可以帮助你协调每个冲刺的合理目标。”

除了了解冲刺持续时间外，了解何时何地参加关键会议也至关重要。业务利益相关者在冲刺的不同阶段参与。因此，掌握更广泛的敏捷 Scrum 流程将提供更多背景信息。

如果不花时间学习和熟悉使用敏捷 Scrum 的团队的会议仪式，混乱的感觉就会一直持续下去。你不知道该去哪里、该做什么或如何让其他团队帮助你完成工作。

关键是要发现其中的规律。

我将指导您识别这种模式，以便您可以弄清楚与谁合作、会议何时举行以及需要准备什么。

让我们从参与敏捷过程的个人开始。

找到导体 

首先，找到产品经理。

如果您是业务利益相关者，那么您基本上不参与此日常流程。此人是您的联系人，可帮助您了解敏捷团队的会议节奏，并可就提交工单的位置和方式为您提供建议。

企业主主要在开始时（向团队明确“要求”）和结束时（验证输出）参与。 

要找的第二个人是发布列车工程师（基本上是首席工程师）。

此人负责推动敏捷发布流程的执行，管理过程中的风险和依赖关系。此人将在很大程度上指导您的请求如何实施的技术细节，以便成功发布。 

顺便说一下，你最好也确定一下项目经理。（这个角色可以有不同的名称，从 Scrum 主管到交付经理。）

从功能上讲，他们支持产品经理组织团队当前的冲刺和积压工作（需要处理的票据阵容），并且他们通常向更广泛的组织报告工作的持续状态。 

一旦您在组织中确定了这些角色，他们就可以帮助您指导您参加各种会议。 

敏捷项目管理仪式（会议）

第二步是了解要参加哪些会议以及如何帮助团队前进。 

在本节中，我将规划您作为业务利益相关者需要计划参加的会议、会议类型、会议时间以及出席人员。作为SEO 产品经理，我既是主题专家，又是业务利益相关者。 

参加这些支持敏捷项目管理方法的会议有助于我了解情况，同时与跨职能团队合作完成工作。 

由于敏捷允许团队自我组织，以下是此过程中一般会议术语和类型的概述。 

起来

这通常是每周每天或每隔一天举行一次。这些会议通常持续 15 分钟，议程是召开圆桌会议，讨论团队最新动态和/或他们工作中遇到的任何阻碍。

业务利益相关者通常不会参加站立会议，但参加几次站立会议还是有帮助的，特别是当你注意到团队对他们正在为你的团队处理的票据有疑问时。

作为业务利益相关者，您希望被邀请参加每日站立会议。这是一个论坛，可以了解每个人的工作内容、遇到的障碍，或者如果他们对您的票有疑问，您可以帮助回答。

请注意，站立会议不是介绍新工作的地方。适合介绍新工作的时机是冲刺规划。 

美容

这通常是一场持续一小时、每两周或每周一次的会议，具体取决于冲刺节奏。产品经理和项目经理会与团队（工程、设计/用户体验等）讨论工作内容以及每张工单所涉及的工作量，然后再将其添加到冲刺中。

一旦了解了每张票的大小和范围，它就会被添加到冲刺中。 

这是业务利益相关者需要参加的一次重要会议，因为他们会向负责此事的团队介绍情况、回答问题并提供任何其他背景信息，例如优先级或严重性。做好准备、简短、有帮助且透彻是很重要的。 

在准备进行整理时，请通过确定您要带给团队的工单类型来创建工单。在大多数情况下，它要么是问题，要么是增强功能，可以归类为以下类型： 

• 一个错误（即曾经可以运行但现在无法运行的东西）。
• 新特征或功能。
• 回归（即以前的功能不再按预期工作）。 

我将更详细地介绍SEO 团队如何编写有效的票证，您可以将其用作指南，以适应整合您自己团队的规范。 

提示：在验收标准中使用定量指标，并提供工作被查看和批准为完成的来源。（对于 SEO，通常是源代码。对于其他团队，可以是“客户体验将是 X”） 

作为企业主，当您的要求和宣传在您的票据中清晰明了时，您更有可能完成工作。 

细化

这些会议可以是长达一小时的会议，并根据需要进行，因为它们可以应用于冲刺的当前票证集或积压票证。 

持续的改进会议旨在使团队聚集在一起，确定需求，调整工作量级别（LOE）、QA 输入等。 

我们都知道技术变化很快。敏捷流程的这一部分可帮助团队规划需求并根据现有市场条件进行调整。 

冲刺规划

团队在此规划即将进行的冲刺中将包含的工作。每个冲刺通常有 1-2 周的时间限制，在此期间所有票证（预定工作）均已完成。 

有效的冲刺规划可使整个团队确定每张票的工作量并在冲刺中完成。理想情况下，他们的 KPI 速度输出趋势向上且向右。  

参加冲刺计划会议将有助于您了解团队在短期内将开展的工作和交付成果。

有了计划工作的可预测性因素，团队就可以专注于消除技术债务或与增长相关的计划。为整体改进提供了进攻和防守策略之间的良好平衡。 

待办事项细化

当团队需要整理和/或优先处理他们排队的积压票时，可以按需召开此会议。通常，此会议涉及产品经理、项目经理和工程主管。 

敏捷 Scrum 方法论的一个重要部分是始终拥有“健康、精心整理”的工作积压，以便队友在能力允许的情况下继续处理。 

虽然业务利益相关者通常不参加此会议，但向项目经理询问团队积压情况会很有帮助，以便更好地了解团队在哪些方面需要或机会承担更多工作或可以分解的大型项目。 

这里的关键词是“分解”。在敏捷中，大项目总是被分解成单独的工单。 

演示/展示

当功能可用并且准备在投入生产或实时环境之前向利益相关者展示时发生。 

当工程团队准备好向更广泛的受众分享和展示他们的进展时，项目经理会安排会议。利益相关者的参与是关键，因为这是一个接触点，团队可以借此验证所构建的内容是否符合预期。 

如上所述，如果您在票证中彻底包含了可量化的验收标准，那么在开发过程的这个阶段，就很容易确认票证已完成。 

回顾（复古）

此会议由项目经理组织，在冲刺完成后举行。在此，整个团队聚在一起讨论最近冲刺中哪些地方做得好/哪些地方做得不好，以及他们未来可以如何改进。 

外部利益相关者需要参加这次会议，特别是当他们的工作是冲刺的一部分时，因为这是一个建立友情并帮助每个人进步的时候。 

一个好方法是准备好 1-2 张罚单作为例子，并说明发生的好事或坏事。坚持事实，并强调事情可以如何改进。您的反馈应该来自团队合作的集体成长和改进。 

这里最重要的一点是：当您向敏捷团队提出时间和精力请求时，利益相关者应在请求单中提供清晰、简明的信息，说明“需要什么”（而不是“如何做”， 这是敏捷团队要决定的）。您的回复应简洁明了，以帮助团队做出决定，这样他们才能继续构建解决方案。

FOMO 正在消退，是吗？因为你正在成为解决方案的一部分。 

不，更多的是恐惧。

我怎样才能再次被邀请与敏捷团队合作？

你知道吗？做事有点让人上瘾。 

一旦实施了某件事，你就会想要更多。由于你正在合作，FOMO 实际上开始消退。

您拥有团队会议节奏的所有日历邀请。您知道促进联动和沟通的 POC，以及您的票何时可以审核和签署。

如果您做得好，您甚至可能会被邀请加入他们的内部 Slack 频道！ 

确保再次与这些团队合作的最佳方法是帮助团队完成他们共同承诺在时间限制冲刺中完成的工作（头韵很有趣）。您可以通过参与和准备来做到这一点。 

如何避免您的要求被忽视

写下来：让它们可量化！

首先，用简单的术语定义要求：这里有一些有效（和无效）票证的例子和用户故事提示，以帮助您明确问题和要求。

再次引用Solis 的话： 

“验证与 SEO 相关的开发请求或票证是否已正确实施是实现 SEO 执行期间预期结果的关键一步。”

是的！您可以通过在票证中定义清晰且可量化的验收标准 (AC) 来实现这一点。 

作为企业主，您可以提供 AC 来规定您对某些功能的期望和/或所需的客户体验。 

你越能量化它，就越容易验证，并且让团队认可工作已经完成。 

可量化的输出比定性的输出更可取，因为后者是主观的，您可能无法得到您想要的结果。 

例如，作为一名 SEO 产品经理，我对 SEO 相关的链接经常遇到的 AC 之一是，它们的格式如下： 

• <a href> 必须位于 view:source 中。 
• <a href> 必须不带参数。 

当您在代码中看到该标准时，它就是一个简单的“是/否”答案。它要么以该格式存在，要么不存在。通过/失败 QA。 

因此，要点是将可量化的 AC 包含在票证中。这将使您能够与 DoD（完成的定义）团队保持一致，并轻松抽查和验证其完成情况。  

我如何知道我的组织是否正在使用敏捷？

确切地说，就是问。找一个有产品经理头衔的人，问他们：“嘿，问个快问题：我们是否使用敏捷方法进行项目管理？如果是，我可以受邀参加每日站立会议，以了解团队在当前冲刺中制定的计划吗？”

当你收到邀请时，一定要准时出席（确实如此，因为这些会议很短）。倾听。做笔记。你参加团队的礼仪会议越多，你就越能记住。 

这就是你完成任务的方法 

现在，您掌握了完成任务的最佳秘诀。我知道这很复杂。这对您来说可能是新的或陌生的。而且这一切都是您日常工作之外的。但找到这些团队是值得的。加入敏捷流程是您与更广泛的团队一起完成任务的方法。

如果你不相信我的方法有效，那就继续按照你之前的方式操作吧。不要参与其中；就看着你的所有工单都被归入某个团队的待办事项。但是，如果你想启动大型项目并创造变革，那就试试吧。实施我在这里概述的内容，承担责任并以这种方式运营。我保证你会得到结果。敏捷是为输出而设计的。 

作为一名内部 SEO 产品经理，我可以亲口说，学习和操作敏捷框架（以及在不同公司这样做）花了几年时间才适应。如果我说实话，我还在学习。但是，就像任何事情一样，你做得越多，与队友互动和沟通越多，事情就会变得越容易。