本文将以有赞零售产品为例, 介绍需求全生命周期的管理实践, 包括: 商家的原始需求收集产品设计与评审研发的需求实现上线后运营反馈新一轮迭代优化, 构成了需求全生命周期的反馈回路
在整个过程中, 我们是如何对需求项目任务缺陷线上质量和功能优化进行有效组织和管理的呢? 让我们一起揭开这个神秘面纱吧!
1 个项目 +3 块看板模型
为了让产品和研发过程更可控, 让彼此间协作更顺畅, 让共同努力的结果更靠谱, 我们设计了 1 个项目 +3 块看板模型
1 个项目指有赞零售事业部只使用 1 个 JIRA 项目管理产品需求技术需求技术任务和测试 Bug),3 块看板指:
给产品经理提供的有赞零售产品需求看板;
给研发过程提供的有赞零售项目看板;
给测试阶段提供的有赞零售 Bug 看板
其中, 有赞零售项目看板是 Scrum Board, 而另外两块看板是 Kanban Board, 它们通过不同的 JIRA 过滤器来实现由于我们需要对产品需求和技术需求做拆分估算和迭代规划, 所以有赞零售项目看板设计成 Scrum Board, 该看板提供了两种视图: 整体视图和局部视图, 我们可以通过该看板的活跃 Sprint 视图查看当前正在进行中的所有 Sprints(包括项目迭代和日常迭代)的需求和技术任务, 同时也支持单个 Sprint 查看视图在正式进入 1+3 模型之前, 让我们先从需求的源头入手, 介绍下商家原始需求的管理方式
商家原始需求管理
商家反馈的需求主要来源于客满商家服务渠道销售用户研究同学和 BBS 需求帖, BBS 需求帖由产品同学定期处理和反馈, 而其他来源的需求会统一提交到共同的 JIRA 看板客户服务需求反馈 / 同步看板中
该看板提供多种视角查看各产品线的需求, 同时, 提供用户体验问题和大客户需求的专属泳道每张需求卡片上会显示其产品名称预处理结果和预计发布日期商家反馈的需求为原始需求, 无法直接用于生产, 由产品经理来跟进处理, 所以, 该看板不需要技术同学介入
选择 JIRA 看板工具做管理的好处是:
通过搜索查询类似需求是否已被提交, 以减少不同来源需求的重复提交;
能捕捉需求经过的每个过程;
邮件通知机制, 需求卡片的更新 (如: 备注状态更新等) 会以邮件形式通知到报告人和关注人等需求干系人
产品经理过滤出与自己相关的需求, 如果是新提交的需求, 那么会对其进行预处理:
判断价值很低或肯定不会做的需求, 直接将需求卡片拖动到已完成列, 选择解决结果不会被修复, 并备注原因;
判断有一定价值或需要再分析的需求, 将需求卡片拖动到产品需求池列, 在弹窗中选择预处理结果为需要再分析可以很快开始或已规划到项目
我们会以报表形式展示多种统计结果, 用于管理决策, 比如: 产品需求池列中需求的预处理结果和不同产品线的需求累积流图接下来, 我们介绍下已规划到项目中的需求管理方式, 该类需求来源于客户服务需求反馈 / 同步看板, 经过产品同学设计后, 以功能粒度在各事业部的产品需求看板中以 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), 技术任务的类型包括前端后端数据 AndroidiOS 小程序开发自测用例编写和用例执行等
至此, 我们形成了需求拆分的三层模型, 即: 史诗 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 模块影响版本和解决版本这样, 我们将 StoryFeature 和 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+3 模型管理产品需求条目化和研发过程;
使用线上问题和故障流程管理需求发布后的线上运营质量;
使用日常需求看板快速迭代商家反馈的功能优化建议
但是, 我们仍存在很多需要改进的地方:
从需求收集完到产品开始设计之间缺乏市场需求分析(输出: MRD 文档), 前期对需求的价值评估不够;
需求发布前对市场客满和服务同学的信息同步或培训不够, 降低了服务响应水平;
需求发布后的线上运营数据分析不够, 无法有效评估需求的 ROI;
有赞的业务敏捷性仍有提升空间, 目前 1 个月内发布的需求占比仅 40% 左右
此外, JIRA 无法满足整个公司对项目集或项目的运营诉求, 在使用 JIRA 和 Confluence 系统的同时, 我们还在自主研发有赞效率平台, 目前对需求月度规划会和项目制管理方式有很好的支撑
该平台的愿景是: 赋能团队, 通过助力团队协作来管理产品全生命周期, 提升公司生产效率 2018 年有赞将需求生命周期提高到公司战略高度, 我所在的研发效率团队目前还需要更多优秀的小伙伴加入
来源: http://www.tuicool.com/articles/Yfy2Ibi