第六章 需求工程之如何获得用户心声

如何获得用户心声

• 步骤：

  1. 识别产品的不同用户类别
  2. 挑选用户和干系人小组代表，并与他们一起工作
  3. 对谁是项目需求的决策者达成共识

• 注意事项

  1. 用户声称他们需要的[[0第一章 软件需求的本质#特性|特性]]并不等于他们使用新系统完成任务时需要的功能。
  2. 业务分析师必须广泛收集用户的收入，分析和澄清这些信息，明确提出需要实现什么的功能才能帮助用户完成他们的工作
  3. 业务分析师对记录新系统所需要的能力和[[0第一章 软件需求的本质#特性|特性]]并将这些信息传达给其他干系人负主要责任。
  4. 这是个迭代的过程，并且很耗时。
  5. 如果不花时间达成这样的共识（对在建产品的共同愿景），后果自然是返工、延期、超支以及客户的不满。

用户类别

• 绝大多数产品都希望迎合具有不同期望和目标的各种用户
• 花时间识别出各类用户及其在产品中的角色和权限。
  

用户的分类

• 用户类别是产品用户的个子集
• 产品用户是产品客户的一个子集
• 产品客户又是干系人的子集

独立用户群类型

• 他们的访问权限或安全级别（如普通用户、来宾、管理员）
• 他们在业务操作中执行的任务
• 他们使用的[[0第一章 软件需求的本质#特性|特性]]
• 他们使用产品的频率
• 他们在应用领域和计算机专业技能经验
• 他们使用的平台（台式机、笔记本、平板等）
• 他们的母语
• 他们是直接还是间接与系统交互。

用户类别划分方法

• 通过思考用例、用户故事、操作流程以及操作人员可以发现更多的用户类别
• 考虑各种用户使用系统完成哪些不同的任务（职责与权利）
• 不同的用户类别对系统也可能有不同的质量预期
• 随着使用系统经验的增加，他们开始关心效率
• 更喜欢制定快捷键、定制选项、工具和脚本工具
• 用户类别未必是人，可能是替代人类用户提供某些服务的代理软件。
• 需要更广泛地考虑需求的潜在来源而不能只局限于直接用户和间接用户。
• 在尝试找出能够提供必要需求信息的干系人时，一定要在明显的终端用户之外看看。
• 暂时无法在飞书文档外展示此内容

受优待的用户类别

• 该类用户的满意度决定着项目是否达到业务目标的用户类别
• 在解决不同用户类别的需求冲突或是考虑优先级时，该类用户应当加以照顾

不受优待的用户类别

• 出于法律、保密、或安全的考虑因素而不应该使用此产品的用户。
• 也许需要特意设计某些[[0第一章 软件需求的本质#特性|特性]]，使不受欢迎的用户很难使用他们应该使用的功能
• 如加入访问权限控制机制、用户级别限制、反恶意软件[[0第一章 软件需求的本质#特性|特性]]和使用日志
• 登录次数超限后，限制登录，但会影响忘记密码的正常用户

忽略不计的用户类别

• 他们会使用产品，但不需要特意迎合他们

其他用户类别

• 在定义产品需求时也要加以重视

识别用户类别

• 在项目早期阶段识别并划分出用户类别，以便从各个重要的用户类别代表那里获取需求

• 艾伦·戈特斯迪纳尔“发散后收拢”协作模式

  • 首先问项目出资人希望谁使用系统
  • 通过头脑风暴想出更多的用户类别
  • 识别有相同需求的小组，归为一类或当做一个主要用户类别
  • 将用户压缩至15个不同的用户类别
  • 在内外关系图中处于系统之外的外部实体都是用户群的号候选。

• 公司组织结构图同样可以帮助发现潜在用户和其他干系人

  • 找出参与业务过程的部门
  • 找出受业务过程影响的部门
  • 可能找到的直接用户或间接用户的部门或角色名称
  • 横跨多个部门的用户群
  • 与公司外部的干系人有接口的部门

• 分析组织结构图可以降低遗漏组织内重要用户群的可能性

• 组织结构图可以指引你找到特定用户群的代表

• 组织结构图还能帮你确定谁可能是核心的需求决策人

• 研究组织结构图可以帮助确定和多少个用户代表一同工作才能确保你完全理解广泛用户群体的需要

• 还要试着理解基于他们在公司中的角色及其所在部门的视角，每个用户可以提供哪些类型的信息。

• 将用户群及其特点、责任与物力位置记录在项目的需求规范说明（SRS）或需求计划中。把这些信息和你从愿景和范围文档中已经获得的干系人信息进行对比，以防出现冲突或重复。

• 记录你所知道的每个用户群的所有相关信息，如他们的相对或绝对规模及哪个用户群更受重视。

与用户代表取得联系

• 任何类型的项目，都需要有合适的用户代表说话。
• 这些用户代表应当全程参与开发，不只是需求阶段
• 每一个用户群都要有一个人为他们代表
• 开发商业软件，可以组织参加beta测试或早期发布站点的用户在开发阶段提供需求信息。
• 考虑将产品或竞品的当前用户组成一个焦点小组
• 不要猜用户要什么，直接问。
• 确保确保焦点小组所代表的用户需求可以指引产品开发。同时包含专家和经验缺乏的客户。
• 一项研究指出，建立更多类型的沟通渠道和开发人员与用户直接沟通会使项目更成功。
• 最直接的沟通就是开发人员直接与合适的用户对话。
• 用户和开发人员中间的层数越多，信息传递的错误率和延时率就越大
  

产品代言人

• 每个产品代言人都是某个用户群与项目业务分析师之间的主要接口
• 产品代言人从用户群其他成员那里收集需求并消除冲突
• 需求开发活动是业务分析师与这些挑选的用户的共同责任，业务分析师负责写需求文档。
• 最好的产品代言人对系统有个清晰的愿景，并对此充满热情，他们明白系统会给同事们带来诸多好处
• 产品代言人应当是受同事尊敬的，并且有高效沟通能力的人。
• 产品代言人他们必须对应用领域与解决方案的运行环境有全面的认识。
• 当每个代言人拥有充分的授权足以替其代言的用户群做出有约束力的决策时，产品代言人这种方式才能发挥最大功效。

外部产品代言人

• 在开发商业产品时，从公司外部寻找产品代言人是十分困难的
• 如果与一些主要的公司客户有紧密的合作关系，他们可能很会乐意有机会会参加需求引导活动
• 可以为外部产品代言人提供经济奖励
• 仍需警惕，避免听信代言人对需求的一面之词而忽视其他干系人的需要
• 如果有大量不同的客户群，首先要识别处所有客户共有的核心需求。
• 然后再定义适合特定公司客户、细分市场或用户群的附加需求
• 可以雇佣一个有合适背景的产品代言人。
• 根本的问题是，无论产品代言人的背景或现任职务是什么，他们是否能够准确代表如今真实的用户需求。

产品代言人的期望

• 为了帮助产品代言人取得成功，用文档记下你对代言人的期望，帮助你建立一个具体的实例，帮助特定的个人充当这个至关重要的角色。

分类	活动
制定计划	细化产品范围和约束条件 识别需要与之交互的其他系统 评估新系统对业务操作的影响 定义一个由现有应用或手工操作迁移到新系统的路线图 识别相关标准和人证需求
需求	从其他用户那里收集需求 开发使用场景、用例以及用户之间的冲突 解决用户群内部需求提案之间的冲突 定义实现的优先级 对性能和其他质量方面的需求提供输入信息 评估原型 与其他决策者一起解决不同干系人之间的需求冲突 提供特有的算法
确认和验证	评审需求规范书 定义验收条件 根据使用场景开发用户验收测试 从业务中提供测试数据集 执行beta测试或用户验收测试
协助用户	写部分用户文档以及帮助文档 贡献培训资料或教程 向同事展示系统
变更管理	评估缺陷的修订或增强请求并排列优先级 动态调整未来的版本或迭代范围 评估变更的申请对用户和业务过程产生的影响 共同做出变更决策

多个产品代言人

• 一个人很难描述处一个应用所有用户的需
• 一个业务分析师把所有产品代言人的输入合并到一个统一的SRS中

推广产品代言的理念

• 一些用户不愿意加入项目，因为项目可能会改变他们的工作方式甚至威胁到他们的工作机会
• 管理层有时候也不愿意将需求工作授权给普通用户
• 将业务需求与用户需求区分开，有助于缓解以上部分
• 产品代言人在业务需求所决定的范围内做出用户需求级别的决策。
• 将每个产品代言人的角色和职责写下来并和候选的代言人协商，让他们对要做的事由心里准备。
• 提醒管理层，让他们意识到产品代言人是能够帮助项目达到业务目标的关键因素。
• 遇到阻力时，要指出缺乏用户参与是导致软件项目失败的首要原因，并讲解反面教材案例
• 产品代言人提供了一种及时获得所有重要客户的输入方法，形成双向闭环反馈机制。

产品代言人要避免的陷阱

• 管理层推翻合格的被授权产品代言人所做的决定，使产品代言人产生挫败感，和信任危机发生。
• 只提出自己的需求，很可能对系统不满。
• 如果对新系统缺乏一个清晰的愿景，产品代言人可能会将决策权推给系统分析师，产品代言人没起作用
• 资深用户可能会提一名不太有经验的用户作为代言人

处理需求冲突

• 一定要有人来处理不同用户群体之间的需求冲突、协调不一致并对出现的范围问题做出仲裁。
• 在项目前期就决定好决策人。
• 如果没有决策人，分析师通常只能听从声音最大或职位最高的人的意见。、
• 应当由组织中离基层最近、且可以近距离接触问题的消息灵通的人来做决定。

争论方	如何解决
单独用户之间	产品代言人或产品负责人决定
用户群之间	优先满足受优待的用户群
细分市场之间	对业务成功影响最大的细分市场优先
企业客户之间	由经营目标决定方向
用户和用户经理之间	产品负责人或产品经理为用户群做决定
开发人员和顾客之间	优待客户，不过要保证符合业务目标
开发人员与销售人员之间	受优待的销售人员

敏捷项目的用户表达方式

• 项目团队成员与合适的客户之间频繁的交谈是解决问题和充实需求规范说明最有效的方式。
• 文档无论写的多么详细，也只是持续沟通的一种不完整的替代品