原文地址：https://thegray.company/blog/writing-seo-tickets

在SEO产品管理中，没有什么比撰写出色的SEO工单更能赢得产品与工程团队的信任了。

这是因为工单的质量，对于工作规划和完成的效率——更不用说最终成果的成功——有着天壤之别。它们不仅仅是记录任务，更是连接SEO策略与技术执行的桥梁。

综上所述，SEO产品经理与开发人员有效协作的能力，很大程度上取决于撰写、提交和管理工单的能力。

那么，让我们深入探讨如何做好这件事，包括你可以根据所在组织的标准系统和格式进行调整的SEO工单示例。

为什么撰写优秀的工单如此重要？
就像拼图盒子一样，工程工单标准化了请求的打包方式，使开发人员能够更轻松地评估难度、理解需求、明确目标并比较项目。

提交一份写得糟糕的SEO工单，就像问别人是否想玩拼图，然后只给他们一些碎片，却没有盒子上的参考图。他们会有很多疑问，完成时间会大大延长，而且很可能，他们会选择去玩另一副拼图。

一份结构良好、清晰全面的SEO工单，就像是给开发人员一个完整的拼图盒子。它能提升效率、传达更大的目标、分享所有碎片——全都包装在一个大家都能理解的形式里。这让开发人员能够运用他们的工具和才能，正确地将碎片拼合起来，形成预期中的大局。

（一张微笑海豹表情包特写，配文：“当开发人员打开一份写得很好的SEO工单时。”）

优秀的工单通过消除来回沟通以获取完整背景的需求，简化了开发周期。前期清晰明了可以为每个人在后期节省大量的时间和精力。

常见的SEO工单类型
不同类型的工作有不同的最终目标，无论是创建新内容、修复问题，还是进行研究。

以下三大类别分别代表了不同类型的工单。根据组织不同，每个类别中可能包含多种工单类型。

作为SEO产品经理，你的部分职责是理解你提交的工单类型。从SEO角度看某件事可能感觉是“坏了”，但从开发人员的角度来看，它可能是一项新功能。

例如，如果某些内容仅通过JavaScript提供，并且这影响了自然搜索表现，这在SEO看来可能像一个bug。但对开发人员来说，以更SEO友好的方式提供该内容是一项新功能。现有功能并没有“坏掉”。

通常，每个组织都会为新增工作、修复现有工作和研究使用不同的工单类型。然而，名称可能有所不同：在某个企业称为“故事”的，在另一个企业可能叫“功能请求”——或者“缺陷”可能被称为“bug”工单。

• 故事与任务工单用于新功能。
  故事工单旨在“讲述”用户想要什么。
  在最常用的格式中，工单通过包含两个主要部分来讲述这个故事（我们稍后会详细讨论每个部分）：
  • 用户故事：“作为一个[X]用户，我想要[Y]，以便[Z]。”
  • 验收标准：“给定[X]，当[Y]发生时，则[Z]。”
    鉴于SEO故事工单的性质，它们通常比来自客户支持或产品团队的典型故事包含更多技术细节。SEO方面的考虑是专业知识（这就是我们有这份工作的原因！），所以SEO产品经理不能假设开发人员了解SEO的内部运作机制。
    值得注意的是，一些组织将“故事”和“任务”工单视为可互换的术语。而在其他企业，它们被用作工程工作流程中不同的组成部分。当它们不同时，“任务”通常是更小、更直接的工单（确切知道要做什么，然后去做）。
  • 实践示例：查看我们的故事工单示例。
• 缺陷工单用于修复。
  “Bug”和“缺陷”通常指同一类型的工单，其目标是解决对SEO性能和/或用户体验产生负面影响的现有问题。
  例如，如果你突然发现大量之前正常工作的重定向链接失效了，就可以提交一个bug工单。
  在极少数情况下，如果组织区分bug和缺陷，bug通常指某个功能无法正常工作。而缺陷可以包括任何不符合要求或未按预期工作的功能。
  bug工单中的关键信息包括：
  • 明确识别的问题
  • 修复或不修复该问题的影响（何种影响、影响对象、影响程度）
  • 重现或验证问题的步骤
  • 实践示例：查看我们的缺陷工单示例。
• Spike工单用于研究和背景调查。
  有些问题在能够勾画明确解决方案之前，需要进行研究或调查。这时就需要Spike工单。
  SEO的Spike任务可能是：记录这个多子域网站的动态站点地图结构。
  Spikes是限时的，其结果是产生知识或对未来故事工单的建议，而不是直接导致任何代码变更。
• Epics用于连接相关工单。
  你无法在单个故事中捕捉那些包含许多动态部分和里程碑的大型项目。
  Epic将多个相关的故事或任务组合成一个大的工作体。或者在某些情况下，它将工单作为它们共享的更大主题的一部分连接起来。无论哪种方式，它都提供了一个高层级的视图，并有助于战略规划。
  SEO产品经理可能会创建一个Epic，例如：实施核心Web指标改进。
  创建任何Epic时，请与相关的产品经理和业务分析师合作，确保你与团队其他成员的使用方式一致。

优秀SEO工单的组成部分有哪些？
SEO工单通常为每种工单类型使用标准化的框架。这确保了请求的传达清晰、完整且一致。

每个工单都包含相同的关键组成部分，因为它们对于设定背景和促进高效工作至关重要。

在我们逐一分析这些组成部分时，我们将跟随一个示例故事工单，以便你能看到它们是如何结合在一起的。

• 清晰的标题
  清晰且立即传达工单的目的，同时尽可能简洁。如果团队在工单间有任何命名约定，遵循它们很重要。
  • 好标题：SEO – 在产品详情页实施Schema.org产品结构化数据
  • 差标题：产品的Schema
  • 在我们的示例故事中呈现为：SEO – 为博客分类页面添加可自定义的H1标签
• 涉及范围内的功能
  站点的哪些功能或特性受此请求影响？无论是需要修复（bug工单）还是将在站点上新增（故事工单）？
  • 在我们的示例故事中呈现为：博客分类页面和列表页
• 示例URL
  站点上哪些URL示例将受到此项工作的影响？如果工作影响站点上的多个页面模板，请确保包含每个模板的示例。
  • 在我们的示例故事中呈现为：https://www.example.com/blog/category（包含所有带列表的子路径）
• 详细描述
  接下来是描述，它应详细阐述标题。通过描述所处理的问题或机会，提供此项工作为何重要的背景信息。
  使用诸如项目符号之类的结构化格式，可以帮助开发团队更容易理解描述。
  在故事工单中，描述应提及包括搜索引擎爬虫在内的用户如何受到此项工作的影响。
  在缺陷工单中，描述应定义站点上当前的（有问题的）行为，以及修复后期望的行为。
  • 在我们的示例故事中呈现为：目前在博客分类页面上，H1标签仅为分类名称且不可自定义。出于SEO优化目的，站点管理员希望能够自定义H1标签，使其对用户和SEO更友好。
  • 在缺陷工单中呈现为：我们的站点使用onclick事件提供内部链接。然而，搜索引擎只能抓取在<a href>标签中提供的HTML链接。我们当前的链接格式阻碍了搜索引擎发现内部链接，因为span、onclick事件和自定义Web组件不会被注册为链接。这限制了搜索引擎发现和索引站点页面的能力，以及在页面之间传递搜索权重的能力。
• 用户故事（仅限故事工单）
  用户故事通常遵循以下格式：“作为[某类用户]，我想要[某个目标]，以便[某些好处]。”包含这一点有助于更好地理解工作的目的，从而使优先级评估更容易。
  适用的SEO故事工单应从三个不同的角度概述用户故事。
  • 搜索爬虫：从技术角度看，此项工作对搜索引擎（爬虫）有何价值？
  • 前端用户：用户如何在SERP或站点体验中从潜在变化中受益？
  • 管理员（内部）用户：为内部利益相关者提供的任何功能有何价值？
  • 在我们的示例故事中呈现为：
    • 搜索爬虫：作为抓取example.com博客部分分类页面的搜索引擎爬虫，我希望每个分类页面都有一个单一、描述性的H1标签，以便我能更好地理解此页面在搜索结果中的相关性。
    • 前端用户：作为访问example.com博客分类页面的访客，我希望立即看到一个表明页面主要主题的标题，以便我理解页面上列出的文章主题是什么。
    • 管理员用户：作为example.com博客部分的管理员，我希望有一个单独的字段来为每个博客分类输入自定义的H1标签，以便我可以在每个分类页面上包含一个SEO优化的标题。
• 站点行为（仅限Bug工单）
  站点行为描述应简短明了，通常包含两个主要要点。
  • 实际行为：站点上当前需要修复的行为是什么？
  • 期望行为：修复实施后期望的站点行为是什么？
  • 在缺陷工单中呈现为：
    • 实际行为：产品Schema中产品价格格式错误。当前包含在Schema标记中的产品价格是产品的“原价”值，而不是当前的“促销价”值。搜索结果中显示的价格并非消费者进入产品页面后实际看到的价格。
    • 期望行为：当产品启用“促销价”时，在Schema标记中包含此价格，而非产品原价。
• 重现步骤（仅限Bug工单）
  对于Bug工单，务必包含详细步骤以重现此工单应修复的当前行为。这意味着要概述产生错误行为的每一次点击和交互。
  • 在缺陷工单中呈现为：
    1. 打开任何浏览器并导航至https://www.example.com/locations/all。
    2. 右键单击/双击并选择“检查”。
    3. 根据需要打开所有部分，查看标签插槽和影子根（shadow root）的详细信息。
• 影响
  你将如何衡量此工单实施的成功与否？通过指定你将用于衡量影响和监控性能的关键绩效指标（例如点击量、展示量、平均SERP排名）来定义明确的成功指标。
  这些KPI应与你的业务衡量计划保持一致，以显示此项工作如何与更广泛的业务目标相结合。
  • 在我们的示例故事中呈现为：我们期望在发布后的三个月内，看到带有自定义H1标签的博客分类页面的自然流量增加20%。
• 技术说明
  从技术角度详细说明“做什么”，概述所需的具体更改、实施或修复。
  • 要精确：例如，如果你要求添加元标签，请指定确切的标签名称、属性和可能的动态值。
  • 提供示例：例如来自竞争对手的、能清晰展示期望结果的模型或示例。
  • 包含视觉效果：如果你请求的是页面上可见的更改——例如新的UI元素——请提供线框图、模型和/或带标注的截图。
  • 链接资源：链接到Google文档或关于该问题的其他技术文档。
  • 串联信息：是否有相关的工单或对站点部分的先前工作可以提供更大的背景信息，并有机会合并工作？
  • 在我们的示例故事中呈现为：
    • 竞争对手示例：https://www.competitor.com/blog/category
    • Google文档：https://developers.google.com/style/headings
    • 相关工单链接：EN-4703
    • 截图/模型：[此处附上]
• 验收标准
  验收标准是可量化、可测试的条件，工作必须满足这些条件，工单才能被视为完成。这是SEO人员、产品经理、QA测试人员和任何处理该工单的开发人员了解实施是否满足所有要求的方式。
  • 在我们的示例故事中呈现为：
    1. 管理员为每个博客分类提供了一个用于添加自定义H1标签的字段。
    2. 页面HTML中只有一个H1标签。
    3. H1标签出现在页面正文中，位于其他页面特定内容（尤其是任何其他标题标签）之前。
    4. 此任务不会改变H1的样式。
    5. 如果未输入自定义H1，则H1将默认为分类名称。
    6. 当输入自定义H1时，它将替换分类名称作为H1。
    7. 如果在分类URL后添加查询字符串参数，自定义H1将保持不变。
• 测试说明
  包含测试说明，使非SEO人员也能测试工作目标是否已达成。
  你的说明应描述超出明显情况之外的测试场景，定义此项工作可能影响用户与站点该部分交互的各种方式。
  同时包括任何有益于开发人员和QA的工具或相关SEO知识——例如在不同环境中测试的工具和注意事项。示例：我们无法在预发布环境中测试robots.txt更改，因为它具有禁止抓取预发布站点的逻辑，且此逻辑必须保持不变。
  • 在我们的示例故事中呈现为：
    1. 当你查看博客分类页面的源代码时，H1标签应显示在响应的HTML中。
    2. 可以使用Screaming Frog抓取页面或在Google搜索控制台中使用URL检查工具来确认H1标签。

撰写SEO工单的最佳实践
在构思工单及其各个组成部分时，作为SEO产品经理，你需要考虑以下几点：

• 采用内部语言：每个组织在工单的标签和管理上都略有不同，比如工单类型命名的差异。不同企业的团队几乎会为开发过程的每个阶段和元素采用自己的内部语言，从工单创建到QA。在你的工单中使用相同的术语，这样每个人都在说同一种语言。
• 具体明确：你的目标是消除猜测和假设，不留解释空间。这意味着要避免使用模糊的语言，如“提高页面速度”。
  要具体明确以创造清晰度，例如下面的例子：
  • “移除文章模板上对英雄图片的次级（阻塞渲染）调用”
  • “压缩主页模板上的CSS文件X和Y”
    （右侧装饰性箭头）
  • 数据：56.7%的SEO产品经理在SEO工单处于流程中时，不参与开发站会。
  • 查看更多数据
• 与SEO路线图和业务案例保持一致：工单是你在开发前创建的最后一份文档。任何创建的工单——尤其是故事和Spike工单——都将反映SEO路线图中列出的更广泛目标和类别。
  同时，影响、优先级和紧急性等要素应与为重要工作内容创建的相关SEO业务案例保持连续性。
• 关注“做什么”而非“如何做”：当你向开发团队提交工单时，你是在告诉厨师你想吃什么——而不是如何烹饪。SEO产品经理的角色是定义期望的结果，而不是详细说明应如何编码。这就是为什么竞争对手的示例和解决方案模型如此有用的一个重要原因。
  授权开发人员利用他们的专业知识，使他们能够想出满足技术要求和验收标准的最佳解决方案。
• 标准化模板和清单：标准化是提升开发效率的关键一环。这始于工单创建：工单在组成部分、语言和格式上越一致，开发合作者就越容易接手并执行。
  为最常见的SEO工单类型创建可重复使用的模板将帮助你节省时间，同时简化开发端的执行。你的模板可能包括工单的关键组成部分、常见验收标准的清单、验证工具等。
• 尽早与开发人员协作：积极主动的协作可以防止返工，并确保从一开始就保持一致。不要孤立地编写工单——在创建过程中就与你的开发负责人或相关开发人员交流。讨论需求、潜在挑战和技术可行性。

在开发生命周期中管理工单
开发生命周期在不同的企业中可能看起来略有不同。

有些团队可能拥有业务分析师、项目经理、交付负责人和/或解决方案架构师，他们在工单进入优先级规划之前做出贡献。一旦工单提交，它可能会经过多人之手，进行细节构建、估算、优先级排序和测试说明的添加。

作为SEO产品经理，你应该精通其中的生命周期和框架。虽然每个阶段的情况可能略有不同，但工单通常遵循以下流程：
工单提交 → 工单梳理 → 在冲刺规划中被选中 → 冲刺期间开发 → 发布前质量保证和用户验收测试 → 发布后QA → 发布后跟踪与文档
（工单管理在开发生命周期中各阶段的规划时间线图）

发布前环节

• 在管理平台中提交和更新工单：SEO产品经理应知道如何在开发团队所有人使用的平台中创建、跟踪和更新工单。最流行的平台通常是Jira、Asana和Trello。
• 冲刺规划：大多数开发团队在敏捷冲刺中工作，通常持续一到两周。在冲刺规划期间，团队估算完成工作所需的时间/资源。结合优先级，团队为即将到来的冲刺安排工作，确保他们不会承诺超过冲刺可用时间/资源的工作量。
  SEO产品经理应积极参与冲刺规划，澄清任何问题，尤其是当待办事项中有SEO工单时。不幸的是，近一半的SEO团队没有代表参加冲刺规划会议。
• 故事点：开发团队在任何一个给定冲刺中可用的时间和资源通常用“故事点”表示。完成一个工单所需的时间和资源估算也用故事点表示。
  这有助于团队量化他们在给定冲刺中可以承诺完成多少工作。如果一个工单的故事点太多，无法放入一个冲刺，它可能会被分解成更小的工单。
  作为SEO产品经理，你应该知道故事点估算对于团队来说意味着你的工单需要投入多少工作量。
• 迭代反馈：这个迭代反馈循环对成功的结果至关重要，所以要准备好回答问题！开发人员在处理工单时，经常会寻求澄清或提出替代解决方案。要保持响应迅速、开放讨论，并准备提供更多细节。
• 用户验收测试（或SEO质量保证）：一旦工单在开发中“完成”，它会在发布到生产环境之前移至QA。作为SEO专家，你负责执行SEO质量保证。验证是否满足所有验收标准，测试功能，并确保SEO实施正确。
  使用像Google搜索控制台、Screaming Frog或浏览器扩展等工具进行验证。记录发现的任何问题，并根据需要创建新的Bug工单。

发布后环节

• 发布说明：分享发布说明，告知相关利益相关者（市场、产品、领导层）已上线的SEO变更。
  发布说明是将技术变更转化为业务价值的练习，使用更广泛的团队能够理解的术语。解释实施了什么、为什么重要，以及业务在收益和/或影响方面可以期待什么。
  例如：我们增加了为博客分类页面提供自定义H1标签的功能，这将帮助这些页面在更有价值的搜索词上更具竞争力地排名，并为网站带来更多流量。
• 知识库文章：团队学到了什么对未来的团队成员和计划有价值的背景信息？对于重要的SEO实施，创建一个知识库文章，记录技术细节、原理和持续维护的考虑因素。它应捕获背景、决策、范围外事项和关键历史。
• 跟踪与报告：你已经指导了工作，现在通过设置分析和报告仪表板来跟踪与此工单相关的关键绩效指标（KPI），以展示其价值。这展示了SEO工作的投资回报率，并为未来的计划提供了数据驱动的见解。
  （装饰性元素）
  • 数据：64.7%的SEO产品经理不使用发布说明。
  • 我们调查了SEO人员、产品经理和市场领导者，以衡量各品牌间SEO产品管理的实施情况和成熟度。
  • 查看更多数据

从一个经过验证的模板开始。
在你为不同的SEO工单构思和微调模板时，无需从零开始。使用我们使用的相同模板作为起点，在撰写能赢得开发团队青睐的工单方面抢占先机。

记住：每个团队在工单方面都有自己的细微差别，因此请调整模板以符合内部语言和期望！