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

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

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

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

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

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

为了让需求的过程管理更直观，我们使用“产品需求看板”来管理功能 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 到期日）。

测试 Bug 管理

迭代 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）中管理日常需求，产品负责人会定期拉上需求方产品经理和相关研发同学一起对待办需求列表进行优先级排序，选择出最有价值的需求作为下一阶段的目标，这样可以很好地增进上下游之间的协作关系。

备注：

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；