从客户视角观察_客户满意度是相对的还是绝对的

从产品的使用者那里直接挖掘需求依然无可替代的，一些敏捷开发方法就建议有一个驻场的客户代表（产品负责人）与开发团队一起紧密合作。
本章讲述的客户-开发人员关系是软件项目成功的关键要素。软件客户拥有权力清单，同时也有对应的义务清单。这些清单重点强调客户（特别是终端用户）参与需求开发的重要性。

2.1期望落差

如果没有足够的客户参与，当项目结束时一个无法避免的结果就是期望落差，用户的真实需求和开发人员根据项目之初听到的需求开发出的产品之间的巨大鸿沟。下图中的虚线标示了这个鸿沟。
缩小期望落差的最好方法是与合适的客户代表频繁沟通。这些沟通可以是正式访谈、对话、需求评审、用户界面设计走查、原型评估以及敏捷开发中在可执行软件每个小的增量功能上收集的用户反馈。每次沟通都是一个缩小预期差距的机会，让开发人员所开发的软件能够更贴近用户所需。

2.2谁是客户

先讨论一下干系人这个角色，干系人是指积极参与项目的某个人、群体或组织，他们可能会受项目过程和结果的影响或影响项目的过程和结果。干系人可以在项目团队和开发组织的内部或外部。下图标示了许多类型的潜在干系人。

干系人分析是需求开发的一个重要部分。为一个项目寻找潜在干系人的时候，应当广撒网以免忽略一些重要群体。然后将干系人列表缩小为核心人选，这些人能够带给你所需的核心信息，确保你理解所有项目的需求和约束，使团队能够交付正确的解决方案。
客户是干系人的一个子集。客户是能够直接或间接从产品中获益的个人或组织。
软件客户可能提出需求、出钱、选择、说明、使用或者接收软件产品的输出。
一些干系人不是客户，如法务人员、设计人员、供应商、承包商、风投。
用户需求应该来自于直接或间接使用产品的人，这些用户（通常称为“终端用户”）是客户的子集。直接用户会动手使用产品。间接用户虽然不动手使用，但也会收到系统的输出，例如仓库主管会收到自动发送的每日库存活动报告邮件。用户通常能够描述他们需要产品执行的具体任务、他们需要的输出以及希望产品到达的质量标准。
提供业务需求的客户有时会试图替实际用户说话，然而这些内容常常和真实用户的需求相去甚远。对于企业信息系统，合同制定或者定制应用开发，业务需求应该来自于最终的产品业务价值负责人。用户需求则应该来自于按下按键、点击屏幕或是接收输出的人。如果为项目买单和最终用户之间有严重的脱节，将会出大问题。
商业软件开发有时与此不同，客户和用户是同一个人。客户经理（例如营销人员或是产品经理）常试图决定客户想要什么。但即使是开发这类软件，也应该尽力让终端用户加入用户需求开发过程，可避免一些缺陷出现在评审报告里。
项目干系人之间可能会存在矛盾。业务需求有时会反映用户不可见的组织战略或预算约束。通过管理手段强制他们使用新的信息系统会使他们感到痛苦，他们常不愿意和开发人员进行合作。为了管理这些潜在冲突，可以尝试基于项目目标和约束的沟通策略，创造更多的接纳，消除争论与埋怨。

2.3客户-开发的合作关系

卓越的软件产品来自于基于卓越需求的卓越设计。
卓越的需求则根植于开发人员与客户（特别是终端用户）高效协作的土壤中。
协同合作要想取得成果，需要所有干系人都清楚自己的需要且理解并尊重其他合作者的需求。
当项目压力上升时，很容易忘记所有干系人共同的目标：构建一个既实现业务价值又可以使所有干系人受益的产品。
通常需要业务分析师建立这种合作关系。下表中列出了十项用户的权利，在需求工程阶段，用户可以在业务分析师和开发人员的互动中享有这些权利。每项权利对应着业务分析师和开发人员的义务。清单中的“你”表示客户。


在开发公司内部系统、合同型项目或者为已知的重要客户定制系统时，上述权利和义务比较适用于实际客户。对于大众市场的产品开发，这个权利和义务更适用于产品经理这样的客户代表。
作为项目计划的一部分。关键用户和开发干系人应该讨论这两个列表并且达成一致意见。确保需求开发过程中的参与者理解并且接受他们的责任。这种理解能够减少冲突和摩擦。
陷阱：不要假设项目参与者本能地知道如何在需求开发上开展协作。应该花一些时间讨论相关角色如何高效合作。最好将解决和管理项目需求问题的预案写下来。这将在整个项目中成为一个很有价值的沟通工具。

2.4软件客户的需求权利法案

下面详细介绍出现需求问题时客户可以享有的十项权利。

1. 权利1：期望业务分析师使用自己的语言
   需求讨论应该以你的业务需要和任务为中心，使用业务术语。可使用术语表的方式把业务术语介绍给业务分析师。交流时不要听到晦涩难懂的技术术语。
2. 权利2：期望业务分析师了解自己的业务和目标
   邀请业务分析师和开发人员来观察你和你的同事的做事方式，如果基于老的系统开发，业务分析师应该像你一样使用当前系统。这么做可以使其知道系统如何融入工作流以及哪里可以进行改进。不要假设业务分析师已经了解你们所有的业务操作方式和业务术语。
3. 权利3：希望业务分析师用适合的形式记录需求
   业务分析师会整理所有干系人提供的信息，之后通过各种问题来区分用户需求、业务规划、功能需求、质量目标和其他需要。分析阶段的交付物是以合适形式存储的优化需求集合，比如一个软件需求规范文档或是记录在一个需求管理工具中。这个需求集合构成了干系人对功能、质量和产品约束的一致意见。
4. 权利4：收到需求实践和交付物的相关解释
   很多实践都能让需求开发和管理变得高效，需求相关的知识也能够用多种形式呈现。业务分析师应该解释他所推荐的实践以及每个交付物都包含哪些信息。
5. 权利5：变更需求
   随着业务的发展，团队接收到干系人提供的信息不断增多，或自身深入地考虑了自己的需要，就有权利变更之前提出的需求。但变更是有代价的。有时增加一个新功能就必须在其他功能或项目整体计划和预算之间进行艰难取舍。业务分析师的一个重要责任是评估、管理和沟通变更所带来的影响。可以在项目中和业务分析师一起摸索，确定一个简单有效的需求变更处理流程。
6. 权利6：期望有一个彼此尊重的环境
   客户和开发人员之间的关系有时会变得很对立。如果参与者不理解对方，需求讨论的结果就不好。一起工作可以让每个参与者看到他人所面对的问题。参与需求开发的客户和开发团队应当彼此尊重，同舟共济。
7. 权利7：聆听关于需求以及解决方案的建议和替代方案
   让业务分析师了解现有系统不适合当前业务流程的地方，避免新系统一错再错。业务分析师通常会对业务流程提出不少改进建议。有创造力的业务分析师甚至会提出客户未曾想到的可能性。
8. 权利8：描述能提高产品易用性的特性
   业务分析师应该询问软件功能需求之外的特性。这些特性或质量属性能够确保软件更易用或更好用，使得用户能够更高效地完成其本职工作。用户有时要求产品更友好或者更健壮，但这样描述太主观，对开发没有什么帮助。所以，分析人员应该询问哪些具体特性是对“用户友好”或“健壮”的。
9. 权利9：了解调整哪些需求可以实现复用，加速产品开发
   需求通常较为灵活。业务分析师也许知道当前软件组件或需求哪些与你描述的需求接近。这种情况下，业务分析师应该提出需求的修改方案以减少不必要的定制，让开发人员能够复用这些组件。
10. 权利10：收到满足自己功能需求和质量期望的系统
    这是最根本的用户权利，但要实现这一点需要清晰地表达开发正确产品所需要的所有信息，需要开发人员不断和你沟通备选方案与约束，还需要当事各方能够达成一致。项目团队中，验证共识与提出新的想法同样重要。

2.5软件客户的需求责任法案

权利对应的是责任，以下十项责任是客户代表在为项目定义和管理需求时需要履行的。

1. 责任1：向业务分析师和开发人员传授自己的业务知识
   开发团队需要你向他们传授业务概念和业务术语。这样做能帮助他们理解你的问题和目标。业务分析师通常并不掌握你和你同事任务理所当然的知识。
2. 责任2：准备足够的时间来澄清需求
   相比于一次讨论一点且历时数周的讨论，集中几个小时的讨论更有效。
3. 责任3：提供具体而准确的需求描述
   为需要进一步探讨的需求临时打上“待确定” 的标签，尝试描述每个需求的潜在目的，使业务分析师能够把它准确呈现出来。
4. 责任4：被问到有关需求的问题时及时作出决策
   业务分析师通常很善于引导客户做决定，所以当你难以抉择的时候可以向他们寻求帮助。
5. 责任5：尊重开发人员对需求可行性和成本的估算
   有时可以重写需求使其变得可行或成本可接受。
6. 责任6：和开发人员协作设置符合实际的需求优先级
   很少有项目能够有足够的时间和充足的资源实现用户想要的一切。所以，决定哪些功能是核心的，哪些是有用的，哪些需求对用户不是最重要的，这是需求分析的重要的几点。设置务实的优先级就是帮助开发人员用最低的成本在最合适的时间交付最大化的价值。协作确定优先级是敏捷项目的核心，使开发人员能以最快的速度交付最有价值的软件产品。
7. 责任7：评审需求和评估模型
   同行评审是保障软件质量的最有效方法之一。
   让客户参与评审是评估软件在需求方面是否满足完整性、正确性和必要性的关键方法。
   评审也是客户代表评估业务分析师工作是否满足项目需要的一个重要时机。
   业务分析师应该在需求引导的过程中经常向你提供适量需求进行评审，不要在需求“完成”以后才将一大本需求手册放到你的桌子上。
   仅仅依靠写好需求很难“脑补”出软件如何工作的画面。为了更好地理解你的想法并探索最佳的实现方式，业务分析师或开发人员有时会构建一个目标产品的原型。针对这个原型进行反馈，可以为开发人员提供非常有价值的信息。
8. 责任8：设定验收条件
   验收条件包括验收测试，用于评估用户执行业务操作时产品是否能够正确执行，其他验收条件还可以针对可能存在的缺陷、特定操作下的表现或是能够满足外部系统的验证需求等。
   敏捷项目使用验收条件来充实用户故事细节，而不使用书面记录的需求。测试人员虽然能够判断某个需求是否正确实现，但他们并不见得了解你能够接受什么样的产出。
9. 责任9：及时沟通需求变更
   虽然变更难以避免，而且通常也有望增加价值，但是越晚引入变更，造成的冲击越大。应该在发现需求需要改变时尽早通知业务分析师。
   为了把影响降到最低，要遵从项目定义是需求变更流程，以确保所有提出的变更不会丢失，每个变更影响都要考虑到。
10. 责任10：尊重需求开发流程
    引导和制定需求是软件开发中最有挑战的活动之一。可以询问业务分析师他们为什么要获取某些信息，为什么要你加入某些需求开发实践。相互理解并尊重他人的做事方法和需要，有利于建立一个有效而愉快的合作关系。

2.6建立尊重需求的企业文化

开发人员也是项目干系人，参与需求评审，让他们知道接下来会发生什么并且指出哪些地方需要进一步澄清。用户看不到的内部质量属性通常需要由开发人员提供。
质量保障人员和测试人员也是优秀需求的贡献者。不要等到项目后期再让他们加入，让这些“眼尖”的人尽早加入迭代的需求评审。他们善于发现歧义与冲突，非常关心如何基于开发测试用例和场景。测试人员也能够提出可验证的质量属性方面的需求。

今天的文章从客户视角观察_客户满意度是相对的还是绝对的分享到此就结束了，感谢您的阅读。