需求评审规范

需求评审,就是产品经理将收集、整理的需求,通过向团队成员(项目经理、研发、测试)进行阐述、说明或者演示,使团队成员对需求的理解保持一致,从而使产品达到预期效果。

一、需求评审的重要性

实际项目中,我们常见的几类与需求有关的问题:

  1. 需求开发的过程中发现有逻辑不通、逻辑遗漏,研发不知道该如何继续实现
  2. 开发前评估工作量2周,实际开发却发现越做越多,工作量远超计划
  3. 测试的过程中提交的bug有争议,测试认为是bug,开发认为需求设计如此
  4. 开发测试都很顺利,但交付后,运营不满意、客户不满意,认为没有满足自己的需求

需求评审的好处:

  1. 评审过程本身也是一个知识传递过程,评审人员与需求分析人员一起讨论用户需求,这有助与评审人员获得用户需求的前期认识,确保对需求理解的一致性
  2. 评审过程中,沟通细节,可能发现不明确的或者遗漏的需求
  3. 各方思考的角度不同,可能可以产出更合理或更有建设性的解决方案

二、如何进行需求评审

需求评审流程

需求评审流程
1、范围评审

  • 评审目标:明确需求范围,要做什么,不做什么
  • 文档准备:需求场景、需求清单、客户调研报告、竞品调研报告等
  • 参会人员:产品、需求方(业务、销售、售后、老板等)
  • 评审产出:达成一致的需求范围清单

2、低保真评审

  • 评审目标:初步明确大致的样式交互及业务逻辑方案
  • 文档准备:低保真稿(包含核心业务逻辑说明及核心页面交互)
  • 参会人员:产品、需求方、研发(前端、后端)、UI/UE
  • 评审产出:就核心业务逻辑及核心页面交互达成一致

这个流程可视团队情况、需求复杂度、需求量决定是否进行。

3、方案评审(高保真)

  • 评审目标:关注粒度更细的方案细节,需求、逻辑需覆盖全面
  • 文档准备:包含全部业务逻辑说明、页面样式交互说明,是可以直接开始研发的终稿
  • 参会人员:产品、研发(前端、测试)、UI/UE
  • 评审产出:理想状态下,就全部业务逻辑和页面交互达成一致

会议管理

会议前
明确本次会议的目的、提前确定与会人员、与会时间、会议时长、会议室预约、会议材料准备。
在评审前,需先把需求文档、原型图、流程图等材料提前邮件给会议相关方,各方查看后标注评审意见,方便会议上提出讨论,提高评审的效率。

  • 目的:让团队所有人员对需求达成一致
  • 与会人:项目经理、产品、研发、测试、UI设计、运营、需求方,尽可能召集与项目有关的所有人员,各个领域的负责人必须到场
  • 与会时间:提前协调各方合适的时间
  • 会议时长:最好控制在1个小时以内,时间太短无法把需求说清楚,时间太长容易疲劳、注意力不集中
  • 会议室预约:根据参会人数、以及演示方式预订符合自己需要的会议室
  • 会议材料:提前准备好项目概要、需求文档、原型图、流程图、项目排期计划并提前发送给相关与会人

会议中

评审流程:

需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义

澄清需求时要注意以下几点:

> 在进行需求澄清前不要忙着讲解用户操作流程,演示原型图,首先我们应该对需求的价值进行澄清,然后澄清需求的背景以及需求想要实现什么目标、解决什么问题,这样的话大家对需求的理解才能更深刻,才不会在后期质疑是否需求的必要性。
> 尽量用举例子、讲故事的方式来澄清需求。在讲解用户操作时可以结合具体的业务场景。
> 节奏把控,避免在一个问题上讨论太久,一时半会儿没有结论的问题需要记录下来,后续再专门安排时间讨论;避免讨论溢出范围的问题
> 记录会上提出的所有问题
> 与每一块的负责人确认排期时间是否有疑义
> 防止突发事件,预留一定时间

会议后
输出会议纪要,一般分为3部分:待讨论、待完善、已确认。

  • 待讨论:指会上的遗留问题
  • 待完善:指会上确认要改的问题,后续要完善在文档中
  • 已确认:指会上讨论得出要做/不做的结论的点

会议纪要需要发送给参会的所有人员,待完善的部分待补充后视具体情况再组织二次评审,待讨论问题记录待办工作,择期组织会议进行讨论。

三、需求评审关键要点

需求层面

  • 正确性
    • 是否清晰准确的描述了要实现的功能
    • 需求描述是否无二义性,例如存在模糊描述(同已有逻辑)
  • 完整性
    • 场景覆盖是否全面(正常场景、异常场景)
    • 是否存在隐藏的需求
  • 合理性
    • 是否与原功能/需求相互冲突或矛盾

业务流程

  • 是否有完整清晰的流程图
  • 流程是否能走得通,是否合理
  • 流程之间是否存在冲突/矛盾

交互体验

  • 交互设计是否完整
  • 用户体验是否合理,是否有违背用户习惯
  • 用户操作流程是否可独立完成
  • 界面是否可读、可理解
  • 界面风格是否可别用户接受

技术可行性

  • 需求中的功能是否能通过现有技术实现
  • 要接入新技术的话,投入成本有多少,是否可复用

可测试性

  • 是否每项需求均有验证的标准及方法,可通过设计测试用例或者其他验证方法来进行测试

可交付性

  • 评估是否能在规定时间内进行交付
  • 交付成本是否过高,例如部署、迁移

分配优先级

  • 是否对所有需求都进行了优先级分配;若所有需求都一样重要,那么在项目管理过程中便无法灵活管控资源及进度
  • 6
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
华为-原理图绘制评审规范-checklist是华为公司为了确保原理图绘制质量和准确性而制定的指南。以下是一份可能的评审规范-checklist: 1. 原理图符号准确性:检查原理图中的各个元件符号是否正确,包括器件、连接线、电源等。确保符号与实际元件相对应,并且没有错误或遗漏。 2. 连接线规范:检查连接线的走向是否符合设计要求,并且没有交叉、断开或不必要的交叉。确保连接线的长度合适且整齐,以提高信号传输的质量。 3. 电源规划:检查电源的布局和规划是否符合设计要求,包括电源线的位置和连接方式。确保每个器件都能得到足够的电源供应,以避免电源噪声或干扰。 4. 阻抗匹配:检查原理图中的阻抗匹配电路是否正确,并且与设计规格相符。确保各个信号路径的阻抗匹配良好,以提高信号传输的稳定性和可靠性。 5. 信号完整性:检查原理图中的信号传输路径是否正确,并且没有信号路径交叉、误接或不必要的延迟。确保信号的传输路径短、直接,并且能够保持信号的完整性和稳定性。 6. 地线和功率线分离:检查原理图中的地线和功率线是否分离,并且没有交叉或干扰。确保地线和功率线的分离可以减少干扰和噪声,提高系统的稳定性和性能。 总之,华为-原理图绘制评审规范-checklist旨在确保原理图的准确性、规范性和可靠性,以提高华为产品的质量和性能。通过逐项检查每个要素,可以及时发现和纠正潜在的问题,确保原理图符合设计规格,并满足客户的需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值