基于JIRA的产品需求全生命周期管理实践

作者 杨勇      

本文将以有赞零售产品为例，介绍需求全生命周期的管理实践，包括：商家的原始需求收集、产品设计与评审、研发的需求实现、上线后运营反馈、新一轮迭代优化，构成了需求全生命周期的反馈回路。

在整个过程中，我们是如何对需求、项目、任务、缺陷、线上质量和功能优化进行有效组织和管理的呢？让我们一起揭开这个神秘面纱吧！

为了让产品和研发过程更可控，让彼此间协作更顺畅，让共同努力的结果更靠谱，我们设计了“1 个项目 +3 块看板”模型。

“1 个项目”指有赞零售事业部只使用 1 个 JIRA 项目管理产品需求、技术需求、技术任务和测试 Bug），“3 块看板”指：

• 给产品经理提供的“有赞零售产品需求看板”；
• 给研发过程提供的“有赞零售项目看板”；
• 给测试阶段提供的“有赞零售 Bug 看板”

其中，“有赞零售项目看板”是 Scrum Board，而另外两块看板是 Kanban Board，它们通过不同的 JIRA 过滤器来实现。由于我们需要对产品需求和技术需求做拆分、估算和迭代规划，所以“有赞零售项目看板”设计成 Scrum Board，该看板提供了两种视图：整体视图和局部视图，我们可以通过该看板的活跃 Sprint 视图查看当前正在进行中的所有 Sprints（包括项目迭代和日常迭代）的需求和技术任务，同时也支持单个 Sprint 查看视图。在正式进入“1+3 模型”之前，让我们先从需求的源头入手，介绍下商家原始需求的管理方式。

商家反馈的需求主要来源于客满、商家服务、渠道销售、用户研究同学和 BBS 需求帖，BBS 需求帖由产品同学定期处理和反馈，而其他来源的需求会统一提交到共同的 JIRA 看板“客户服务需求反馈／同步看板”中。

该看板提供多种视角查看各产品线的需求，同时，提供“用户体验问题”和“大客户需求”的专属泳道。每张需求卡片上会显示其产品名称、预处理结果和预计发布日期。商家反馈的需求为原始需求，无法直接用于生产，由产品经理来跟进处理，所以，该看板不需要技术同学介入。

选择 JIRA 看板工具做管理的好处是：

1. 通过搜索查询类似需求是否已被提交，以减少不同来源需求的重复提交；
2. 能捕捉需求经过的每个过程；
3. 邮件通知机制，需求卡片的更新（如：备注、状态更新等）会以邮件形式通知到报告人和关注人等需求干系人。

产品经理过滤出与自己相关的需求，如果是新提交的需求，那么会对其进行预处理：

1. 判断价值很低或肯定不会做的需求，直接将需求卡片拖动到“已完成”列，选择解决结果“不会被修复”，并备注原因；
2. 判断有一定价值或需要再分析的需求，将需求卡片拖动到“产品需求池”列，在弹窗中选择“预处理结果”为需要再分析、可以很快开始或已规划到项目。

我们会以报表形式展示多种统计结果，用于管理决策，比如：“产品需求池”列中需求的预处理结果和不同产品线的需求累积流图。接下来，我们介绍下“已规划到项目”中的需求管理方式，该类需求来源于“客户服务需求反馈／同步看板”，经过产品同学设计后，以“功能”粒度在各事业部的产品需求看板中以“Story”类型来管理。

产品经理使用产品 PRD 文档将需求输出给研发同学，产品 PRD 的标准模板可在 Confluence 的“创建”右侧的“…”中找到。该模板主要包括：需求的基本信息（作者、优先级、来源和期望上线时间）、需求的背景、简介、目标、总体需求（功能列表、业务流程和业务规则）、原型和视觉稿、详细需求（各功能的详细说明）、数据需求、其他说明和风险。

“总体需求→功能列表”会罗列出需求所涉及的所有产品功能点，这种“将大需求拆分成功能点”的需求管理方式叫需求条目化。通过条目化的功能列表可以让需求干系人简要了解到要做的功能，同时，细粒度的功能清单也方便需求在研发阶段的管理。

我们使用 JIRA 来管理产品功能列表，需求根据大小可以分为两类：a）史诗级需求、大需求或产品特性使用 JIRA 问题类型 Epic（史诗）；b）产品功能点、用户故事或日常需求使用 Story（故事），它们使用如下统一的 JIRA 工作流。该工作流看起来有点复杂，其实它主要由两个阶段组成：a）产品阶段：需求池【Open】 → 设计中 【Product-In Design】→ 评审中【In Review】 → 待开发【Product-Waiting for Development】 ···> b）研发阶段：···> 开发中【In Progress】 → 已完成【Resolved|Closed】。

为了让需求的过程管理更直观，我们使用“产品需求看板”来管理功能 Story（如下图所示）。一个 Story 既可以表示产品 PRD 中的一个功能，也可以表示一个线上待优化的功能。前者将规划到某个项目中完成，而后者将规划到日常需求周迭代中完成。

由于有赞零售产品包含了多条业务线，我们使用 JIRA“模块”来区分来自不同业务线的 Story，跨多个业务线的 Story 需要标记为多个模块，通过“业务模块快速过滤器”查看仅该模块的需求。需求看板上每张 Story 卡片可以显示 Story 的描述信息、所属史诗名和被规划到的发布版本名。

我们通常直接从 PRD 文档中批量创建产品功能点 Story 到产品需求看板中，方法是：在功能列表中点击三次某个功能名称，会弹出 2 个“快捷菜单”，右侧那个为“创建 JIRA 问题”菜单（如下图所示） → 点击“Create JIRA issue”后进入”创建问题“弹框 → 选择“从表格创建多个问题” → 选择相应项目和问题类型：Story → 选择“总结”（JIRA 主题）为：功能列表的“名称”列，描述（JIRA 描述）为：功能列表的“说明”列 → 点击“创建”即可完成“从 PRD 文档批量创建产品需求到 JIRA”。

在每个功能名称右侧插入了“JIRA 链接及状态”，以后 Story 状态的任何更新都会在产品 PRD 中同步更新，JIRA 中也自动添加了产品 PRD 的链接，实现了 JIRA 与 Confluence 之间的数据互通。我们在“有赞零售产品需求看板”的“需求池”列将显示这 2 个 Stories。

在每个月月末，有赞会召开月度规划会，主要由各产品线的产品负责人和技术负责人参加，旨在就需要下一个月做的需求的优先级顺序达成一致。

当产品 PRD 文档通过了产品内部的方案评审后，产品经理会给研发同学做产品需求宣讲。待 UI 设计和交互稿完成后，设计师还会给产品经理和前端同学做 UI 设计评审，以确保传递的信息有效性和完整性，避免后期产生不必要的沟通浪费。

像 PHP 转 Java 这种技术改造型需求，不会对线上产品功能产生影响，我们简称为“技术需求”。为了与功能型需求 Story 区分开，我们使用 JIRA 问题类型 Feature 表示技术型需求（注：官方对 Feature 的解释为产品特性，也属于功能型需求）。其工作流比较简单：待办【To Do】|【Reopened】→ 进行中（开发 / 测试中）【In Progress】→ 已完成【Resolved】|【Closed】（挂起【On Hold】暂时没使用），如下图所示：

为了简化研发同学的使用姿势，技术需求的管理与产品需求使用同样的数据存储结构，即：Epic → Feature → Technical Task（产品需求为：Epic → Story → Technical Task）。创建好的技术需求 Feature 会直接显示在 Scrum Board 的 Backlog 中，而创建好的产品需求 Story 必须流转到研发阶段（即：待开发或之后的状态）才会显示在 Backlog 中。

我们在系统分析阶段会使用统一的技术方案模板进行技术评审，包括不同系统之间的依赖分析、业务流程分析和系统接口约定等。

技术任务的工作流与技术需求的工作流类似，不管是产品需求（包括产品日常需求），还是技术需求（包括技术优化）在开发前将被拆分为可分配给单个研发同学执行的技术任务，且每个任务的原预估时间为 8H 左右（最多不超过 16H），技术任务的类型包括前端、后端、数据、Android、iOS、小程序、开发自测、用例编写和用例执行等。

至此，我们形成了需求拆分的三层模型，即：史诗 Epic->功能 Story/ 技术需求 Feature → 技术任务 Technical Task。产品经理只需关注业务需求 Story，而研发同学除了要关注 Story，还需要关注技术需求 Feature。我们配置了 Backlog 的卡片布局，显示了三个扩展字段：Σ 原预估时间、Σ 进度和到期日，可以很容易看到需求的预估工作量、当前完成进度以及完成日期，如下图的项目看板 Backlog 所示。

当迭代 Sprint 启动后，我们可以在项目看板的“活跃 Sprint”中跟踪技术任务的执行，常用操作有：a）通过拖动任务卡片来更新状态；b）给被阻塞的任务卡片增加 Flag（右键点击卡片→增加 flag），提醒项目成员注意。待风险解除后再删除标识；c）将任务卡片分配给自己，选中卡片，然后点击键盘”I”键；d）每日登记工作日志或在将任务拖到“已完成”列时记录工作日志。

我们使用 Sprint 燃尽图和定期站会对 Sprint 整体进度进行评估和风险识别，在实践中，我们需要了解到每个人在该 Sprint 中的进度情况。为了满足这个需求，我们设计了 Sprint Task Completion by Assignee 报表，展示每个人的原预估时间、实际花费时间、任务的完成率和时间的消耗率等信息。

在 Sprint 完成后，我们会使用“海星图”、“KISS”或“做的不错的／应该做的更好的”方法进行复盘，复盘的改进措施会被录入到“有赞零售复盘 Action 跟进看板”，每个 Action 必须是可执行的具体措施，且有一个主要负责人（JIRA 经办人）和完成日期（JIRA 到期日）。

迭代 Sprint 测试阶段发现的 Bug 提交到“Bug 看板”中，其工作流与技术需求 / 任务的工作流类似。但是，Bug 看板的列名与活跃冲刺看板的列名差别较大，主要是：增加了“测试中”（Resolved）和“挂起中“（On Hold）。当 Bug 暂时不需要修复时，我们可以将其拖到“挂起中”列，挂起的时候需要在 JIRA 备注中说明原因。

提交测试 Bug 的弹窗会提示报告人按“Bug 描述标准模板”（包括：重新步骤、实际结果、期待结果和抓包数据）来填写，此外，测试 Bug 必须关联到 JIRA 模块、影响版本和解决版本。这样，我们将 Story、Feature 和 Bug 都关联到了 JIRA 版本后，就可以在发布版本中按照“版本”查看已发布、未发布和归档版本信息。我们可以根据“模块”和“经办人”来统计某个版本中遗留的测试 Bug 存量分布，如下图所示：

我们不仅要管理研发过程中的测试 Bug，还要管理需求上线后运营阶段产生的问题和故障。线上问题一般是对业务影响很小的缺陷、任务和查询，而线上故障指提供给客户使用的 IT 服务全部或部分不可用，包括服务性能的降低（详见：“有赞 coder”公众号 2016 年 11 月的技术博客《有赞线上故障管理实践》）。

由于两者的严重程度和影响面不一样，所以我们使用不同的流程进行管理，当前线上问题处理流程如下图所示，使用 JIRA 看板来辅助流程的管理（流程图中的红色为 JIRA 状态）。依然针对线上问题的跟进，我们每天都会在产品和研发群发布“线上问题日报”，以报表形式展示每个业务团队的问题存量，以及这些问题的持续时长。

在新功能上线后，商家会将使用过程中遇到的问题和建议反馈给我们，比如：对功能的改进建议或相关的新需求。这些需求会被提交到“客户服务需求反馈 / 同步看板”中，有价值的小需求会在各事业部内部以日常迭代方式快速反馈给客户，而有价值的新需求一般会项目制方式处理。不管采用哪种方式，有赞零售事业部会以功能 Story 方式在零售产品需求看板中管理，待产品方案设计完成并通过评审后，进入研发阶段，然后以 JIRA 迭代 Sprint 方式来管理整个研发过程。

日常需求周迭代 Sprint 周期固定，从周五启动到下周四晚上结束（如下图所示），未完成的产品或技术需求会被移至 Backlog 或下周 Sprint 中。而以项目制方式管理的 Sprint 的周期不固定，项目排期排到什么时候，Sprint 就到什么时候结束，还可能存在延期情况。

有的事业部或产品线使用独立的事业部日常需求池（JIRA Kanban Board）中管理日常需求，产品负责人会定期拉上需求方产品经理和相关研发同学一起对待办需求列表进行优先级排序，选择出最有价值的需求作为下一阶段的目标，这样可以很好地增进上下游之间的协作关系。

任何新流程的推行都会遇到很多阻碍，从 2016 年下半年将 JIRA 系统导入有赞零售项目以来，我一直在努力引导大家按规范流程来执行，但是又不适合强推，比如：对实际花费时间的登记，在任务跟进过程中，只能靠经常提醒大家。当采集了一些项目过程数据后，我会使用 EazyBI 工具制作各种数据报表，当大家对数据报表有感觉后，他们对流程执行的配合程度也会提高，比如：统计某个 Sprint 的测试 Bug 存量，经常公开同步这个报表，可以有效促使开发同学更新 JIRA 状态。

另外，我们还可以借助“下游拉动上游”之力来推动流程的落地，比如：在测试 Bug 看板中，只有开发同学修复了 Bug 后且更新了 JIRA 状态为 Resolved 才能到“测试中”列，这时测试同学才会继续验收是否已修复，测试同学也会提醒开发同学修复好的 Bug 要及时更新状态，否则他们不会验收。我们要记住：任何流程或工具都不是完美的，适合当下才是最重要的。随着业务要求的变化和团队规模的扩张，这些流程需要与时俱进，团队“涌现”出来的改进建议可能让流程更贴近业务和贴近团队所需，会让管理成本更低。

“需求的全生命周期管理”是个很大的课题，本文仅介绍了有赞零售产品的一些实践方法：

1. 使用统一的看板管理来自不同反馈渠道的商家原始需求；
2. 使用“1+3”模型管理产品需求条目化和研发过程；
3. 使用线上问题和故障流程管理需求发布后的线上运营质量；
4. 使用日常需求看板快速迭代商家反馈的功能优化建议。

但是，我们仍存在很多需要改进的地方：

1. 从“需求收集完”到“产品开始设计”之间缺乏市场需求分析（输出：MRD 文档），前期对需求的价值评估不够；
2. 需求发布前对市场、客满和服务同学的信息同步或培训不够，降低了服务响应水平；
3. 需求发布后的线上运营数据分析不够，无法有效评估需求的 ROI；
4. 有赞的业务敏捷性仍有提升空间，目前 1 个月内发布的需求占比仅 40% 左右。

此外，JIRA 无法满足整个公司对项目集或项目的运营诉求，在使用 JIRA 和 Confluence 系统的同时，我们还在自主研发“有赞效率平台”，目前对需求月度规划会和项目制管理方式有很好的支撑。

该平台的愿景是：赋能团队，通过助力团队协作来管理“产品全生命周期”，提升公司生产效率。2018 年有赞将“需求生命周期”提高到公司战略高度，我所在的“研发效率”团队目前还需要更多优秀的小伙伴加入。

最后，非常感谢田莹、郦斌、秦阳、白月月、廉恒睿和崔等有赞小伙伴对本文提供审核和支持！

备注：

1. JIRA Feature（特性）用作表示：相对于产品需求的“技术需求”，该用法不够专业，实际含义指：产品特性，粒度要比 Story 大，比 Epic 小；
2. JIRA Sprint（冲刺）用作表示：一个独立项目、一个大项目的多个迭代或一个日常需求周迭代等，为了达到某个 Sprint 目标，将与该目标相关的 Story 和 Feature 规划到一个 Sprint 中；
3. JIRA Version 用作表示：从产品路线图角度，需求的一次发布，每次发布会包含一到多个产品新功能或功能优化及技术优化，它与 JIRA Sprint 无直接关系，但是一个 Version 中的需求可能被放在多个不同的 Sprints 中完成；
4. 通常，我们将 JIRA Scrum Board 简称为敏捷看板，将 JIRA Kanban Board 简称为普通看板（无“规划”特性）；
5. JIRA 看板的每列对应一到多个 JIRA 状态，每一列都可以配置“在制品数量限制”（WIP），目前只有极少数团队在使用 WIP；

转自 http://www.infoq.com/cn/articles/requirement-lifecycle-management-based-on-jira