6 倾听用户的心声

客户参与交付卓越的软件必不可少，就必须保证业务分析师和项目经理从一开始就尽其所能把合适的客户代表拉入项目、软件需求，甚至软件开发的成功取决于开发人员能否听到用户的声音。为了听到用户的心声，可以采取以下三个步骤：

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

客户参与最能够避免期望落差（客户对产品的期望与开发人员提供的产品功能不匹配），只向个别用户或其经理问几次他们有何具体需求就开始编码，是远远不够的。如果开发人员严格遵照客户最初的需求开发软件，可能需要重新再开发一次，因为客户通常并不知道自己想要什么。此外，也可能业务分析师没有找到正确的人了解情况或没能提出正确的问题。
用户声称他们需要的特性并不等同于他们使用新系统完成任务时需要的功能。为了更精确地捕获用户需要，业务分析师必须广泛收集用户的输入，分析和澄清这些信息，明确提出需要实现什么功能才能帮助用户完成他们的工作。业务分析师对记录新系统所需的能力和特性并将这些信息传达给其他干系人负有主要责任。这是个迭代的过程，并且很耗时。如果不花时间达成这样的共识（对在建产品的共同愿景）。如果自然是返工、延期、超支以及客户的不满。

6.1用户类别

人们常常谈到软件系统的“用户”，好像所有的用户都是同一类人，有着相同的个性和需要。事实上，绝大多数的产品，不论规模大小，都希望迎合具有不同期望和目标的各种用户。不要再将“用户”想成一个单一的个体，花一些时间识别出各类用户及其在产品中的角色和权限。

用户分类

项目可能包含很多种干系人。用户类别是产品用户的一个子集，产品用户是产品客户的一个子集，而产品客户又是干系人的子集。某个个人可以属于多种用户。例如，管理员可以像普通用户那样使用系统。产品的用户可能在以下方面（或者其他方面）有差别，基于下面这些差别，可以将用户分为以下几类独立的用户群：

• 他们的访问权限或安全级别（例如：普通用户、来宾、管理员）
• 他们在业务操作中执行的任务
• 他们使用的特性
• 他们使用产品的频率
• 他们在应用领域和计算机专业技能经验
• 他们使用的平台（台式机、笔记本、平板、智能手机和定制设备）
• 他们的母语
• 他们是直接还是间接与系统交互

按地理位置或服务公司对用户进行分类是很有诱惑力的。一个为银行开发软件的公司就考虑过将用户按照工作在大型商业银行、小型商业银行、储蓄借贷机构或信用合作社来划分。这个分类的确能够体现不同的细分市场，但并不是用户类别的分类方式。
更好的用户类别的方法是考虑各种用户使用系统完成哪些不同的任务。所有类型的金融机构都有柜员、处理贷款申请的职员或业务经理等。无论在那个金融机构，完成这些活动（不管是否有专属的职务名称）的个人，对系统都有相似的功能需求。所有柜员需要做的事基本都相同，业务经理做的工作也都相似，诸如此类。因此更合理的用户类别应当包含柜员、贷款专员、业务经理以及分行经理。通过思考用例、用户故事、操作流程以及操作人员，也许可以发现更多的用户类别。

对特定的项目来说，某些用户类别可能比其他用户类别重要得多。受优待的用户类别就是其满意度决定着项目是否达到业务目标的用户类别。在解决不同用户类别的需求冲突或是考虑优先级时，受优待的用户类别应当加以照顾。并不是说一定要优待为系统付款的客户（他们可能根本就不是用户）或最有政治影响力的人。要看是否有利于达成业务目标。
不受欢迎的用户类别是指出于法律、保密或安全因素的考虑而不应使用此产品的用户。你也许需要特意设计某些特性使不受欢迎的用户很难使用他们不该使用的功能。例如加入访问权限控制、用户级别限制、反恶意软件特性（对付非人类用户）和使用日志。在第四次登录失败后锁定用户账户以防不受欢迎的用户冒仿正常用户登录系统，但也会给记性不好的合法用户带来不便。
也可以选择忽略其他的用户类别。当然，他们也会使用产品，但你不需要特意迎合他们。如果还有其他类型的用户类别，既不是受优待的用户，也不是不受欢迎的用户和被忽略不计的用户，在定义产品需求时也要加以重视。
每一类用户类别的成员为了完成任务都对系统有一些特定的需求。不同类别的用户需要可能一些重叠。不同的用户类别对系统也可能具有不同的质量预期，例如易用性，这影响到用户界面设计决策。新用户或偶尔使用的用户很关心系统是否好用。随着系统经验的增加，他们开始更关心效率。更喜欢快捷键、定制选项、工具栏和脚本工具。
用户类别不一定是人，它们可能是替人类用户提供某些服务的代理软件，例如机器人。
用户只是客户的一个子集，而后者又是干系人的自己。需要更广泛地考虑需求的潜在来源而不能只局限于直接用户和间接用户。

识别用户类别

在项目早期识别并划分用户类别，以便从各个重要的用户类别代表那里获取需求。这里有一个有效的技术，即艾伦·哥特斯蒂纳尔发明的“发散后收拢”协作模式。首先问项目出资人希望谁使用系统。然后通过头脑风暴想出尽可能多的用户类别。重要的是不遗漏用户类别，以免后期引起麻烦。
进行干系人与用户分析时，需要从组织结构图中找到以下信息：

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

分析组织结构图可以降低遗漏组织内重要用户群的可能性。它可以指引你找到特定用户群的代表，还能帮你确定谁可能是核心的需求决策人。在一个部门中你可能会发现拥有不同需求的多个用户群。与之相反，在多个部门中识别出相同的用户群可以简化需求发现过程。研究组织结构图可以帮助确定和多少个用户代表一同工作才能确保你完全理解广泛用户群体的需要。还要尝试着理解基于他们在公司中的角色及其所在部门的视角，每个用户可以提供哪些类型的信息。
将用户群及其特点、责任与物理位置记录在项目的需求规范说明（SRS）或需求计划中。把这些信息和你从愿景和范围文档中已经获得的干系人信息进行对比，以防出现冲突或重复。记录你所知道的每个用户群的所有相关信息，例如它的相对或绝对规模及哪个用户群更受重视。这将有助于团队后期为变更请求设定优先级和评估影响。对系统交易量及交易类型的估计可以帮助测试人员提出一个系统使用概况模型，从而帮助他们规划测试验证活动。
考虑建立一个能够用于多个应用上的用户群。如果在项目的SRS中包含用户群的描述，可以引用可重用的用户群列表中的条目，再加入此应用的特殊用户群描述。

6.2用户画像

为了让用户群鲜活，可以为每个用户群创建一个画像，用户群代表成员描述。角色是一个假想的普通用户，把他当作一组具有相同特点和需求用户的替身。可以使用用户画像帮助理解需求并设计出最能满足特定用户群体需要的用户体验。
当系统分析师手上没有合适的真实用户代表时，用户画像可以作为一个替代。商业型客户的用户画像可以很详细，包括个人社会背景和行为、爱好、厌恶及类似的信息。基于市场、人口统计和人类学研究，确保创造的用户画像真的可以代表用户群。

6.3与用户代表取得联系

任何类型的项目——企业信息系统、商业应用、嵌入式系统、网站、合同软件——都需要有合适的代表替用户说话。这些用户应当全程参与开发，而不只是参与项目开始时独立的需求阶段。每个用户群都需要有一个人为他们代言。
在自己公司开发部署应用时，最容易接触到真实用户。如果开发的是商业软件，可以组织参加beta测试或早期发布站点的用户在开发早期阶段提供需求信息。考虑将产品或竞争对手产品现在的用户组成一个焦点小组。不要猜用户想要什么，直接问。
确保焦点小组所代表的用户需求可以指引产品开发。同时包含专家和经验缺乏的客户。如果焦点小组只代表早期采纳者或空想家，最终获得的将是一些非常复杂和充满技术难度的需求，很少人认为这些需求真的有用。
下图为用户与开发人员之间一些可能的沟通渠道。

用户与开发人员之间插入的中间层越多，信息传递的错误率与传输延迟就越大。不过有些中间层是能够增加价值的，例如当有经验的业务分析师和用户或其他参与者一起收集、评估、细化以及组织输入信息的时候。在使用市场人员、产品经理、主题专家或其他人员作为真实的用户代言人时，要认识到自己所承担的风险。虽然优化用户的表述很有难度且成本高，但是如果跟你沟通的人无法提供最优信息，产品和客户就会吃苦头。

6.4产品代言人

每个产品代言人都是某个用户群与项目业务分析师之间的主要接口。在理想情况下，代言人应该是个真实用户，而不是某种代理人，例如资助者、营销人员、用户经理或把自己想象成用户的软件开发人员。产品代言人从用户群其他成员那里收集需求并且消除冲突。因此需求开发活动是业务分析师与这些挑选出的用户的共同责任，当然业务分析师要负责写需求文档。

外部产品代言人

在开发商业产品时，从公司外部寻找产品代言人是十分困难的。开发商业产品的公司有时会让内部专家或是外部顾问充当真实用户的代理人，真实用户可能很难找到或难以参与。如果与一些主要的公司客户有紧密的合作关系，他们可能会乐意参与需求引导活动。可以为外部产品代言人的参与提供经济奖励。可以考虑给他们折扣价购买产品或者为他们参与需求活动所花费的时间付钱。但你需警惕，避免听信代理人对需求的一面之词而忽视其他干系人的需要。如果有大量不同的客户群，首先要识别出所有客户共有的核心需求。然后再定义适合于特定公司客户、细分市场或用户群的附加需求。
另一个可选的方案是雇佣一个有合适背景的产品代言人。
当产品代言人是前用户或虚拟用户时要小心，因为代言人的想法可能与目前真实用户的想法存在断层。

产品代言人的期望

为了帮助产品代言人取得成功，用文档记下你对代言人的期望。这些记录下来的期望可以帮助你建立一个具体实例，帮助特定的个人充当这个至关重要的角色。下表记录了产品代言人要完成的一些活动，并不是每个代言人都要做下列所有事。

多个产品代言人

一个人很难，描绘出一个应用所有用户的需要。

推广产品代言人理念

当你提出需要产品代言人参加项目的想法时，要做好被反对的心理准备。“用户都太忙了”“管理层希望能掌握决定权”“他们会拖累进度”“我们没那么多钱”“他们会很疯狂，项目范围会爆炸的”“我不知道作为产品代言人要做些什么”一些用户可能不愿意加入项目，因为项目可能会改变他们的工作方式甚至威胁到他们的工作机会。管理层有时候也不愿意将需求工作授权给普通用户。
将业务需求与用户需求区分开，有助于缓解以上部分问题。作为一名真实用户，产品代言人在业务需求所决定的范围内做出用户需求级别的决策。管理者和出资人仍然有权做出影响产品愿景、范围、业务相关的优先级、日程安排或预算方面的决策。将每个产品代言人的角色和责任写下来并和候选的代言人协商，让他们对要做的事有心理准备。提醒管理层，让他们意识到产品代言人是能够帮助项目达到业务目标的关键因素。

产品代言人要避免的陷阱

产品代言人模式在很多情况下都取得了成功。但必须满足以下要求，产品代言人必须理解其职责并做出承诺，必须有权在用户需求级别做出决策，必须有时间投入这项工作。警惕以下潜在问题。

• 管理层推翻合格的被授权产品代言人所做的决定。
• 产品代言人如果忘记自己代表的其他客户，而只是提出自己的需求，就说明他不尽责。
• 如果对新系统缺乏一个清晰的愿景，产品代言人可能会将决策权推给系统分析师。
• 资深用户可能会提名一个不太有经验的用户作为代言人，因为资深用户本身可能没有时间亲自完成这项工作。

6.5敏捷项目的用户表达方式

项目团队成员与合适的客户之间频繁交谈是解决需求问题和充实需求规范说明最有效的方式。文档无论写得多么详细，也只是持续沟通的一种不完整的替代品。最早的一种敏捷开发方法即极限编程中有一个基本原则，就是要求有一个全职的驻场客户参与这些讨论。
有一些敏捷开发方法包含一个称为“项目负责人”的干系人代表，负责向团队传达客户的声音。产品负责人传达客户的声音。产品负责人定义产品愿景，负责开发产品Backlog列表并且对其中的事项排定优先级以及它们在未来的迭代中是如何规划的。迭代在敏捷开发方法Scrum中被称为Sprint。因而，产品负责人横跨需求的三个级别：业务、用户和功能。他实际上同时履行产品代言人和业务分析师的职责，代表客户定义产品特性，排定优先级等。最终一定要有一个人做出决策，交付产品到底要具有什么能力以及什么时候交付。在Scrum中，这些都是产品负责人的职责。
产品负责人和产品代言人不是互斥的。如果产品负责人承担业务分析师的角色，而不是作为干系人代表他自己，就可以组织由一个或多个产品代言人组成的体系作为最合适的信息输入源。或者，产品负责人也可以与一个或多个业务分析师协作，由后者与干系人一同工作理解他们的需求。因此，产品负责人充当的就是最终决策人的角色。

6.6处理需求冲突

一定要有人解决不同用户群之间的需求冲突、协调不一致并对出现的范围问题作出仲裁。产品代言人或产品负责人可以处理这种问题的一些，但不是全部。要在项目前期确定谁是需求问题的决策人。如果由谁负责作出这些决定不清晰或者被授权人放弃履行他们的职责，决策工作自然会落到开发人员或分析师身上。然而他们中大多数不具备必要的知识和视野来做出最理想的商业决策。分析师有时就只好听从声音最大的人或职位最高的人的意见。这虽然情有可原，但并不是最佳策略。应由组织层级中离基层最近且可以近距离接触问题的消息灵通人士来做决定。
下表展示了项目过程中可能出现的冲突和建议的解决方法。项目领导人需要知道出现类似情况时应当有谁来决定做什么，如果不能达成一致又应当通知谁以及在必要时重要问题必须上报给谁。