寻找客户的需求.doc_咨信网zixin.com.cn

资源描述

寻找客户的需求如果你赞成客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就会努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。在第 6章讨论了一种类型的客户—项目主持者( s p o n s o r )、项目的幻想者( v i s i o n a r y )或市场部门—他们提供了项目的商业需求。本章将集中介绍需求的第二级—用户需求。为了征求客户的意见，必须采取以下几步： . 明确项目用户需求的来源。 . 明确使用该产品的不同类型的用户。 . 与产品不同用户类的代表进行沟通。 . 遵从项目的最终决策者的意见。客户参与是避免期望差异 (expectation gap)的唯一途径，这一期望差异表现在客户期望得到的产品与开发者所设计的产品之间不相符。然而，在项目的开始阶段仅仅简单地问一两个客户的需求，然后就开始编码，这样做是不够的。如果开发者仅仅为了客户的最初需求去开发软件，那么，他们可能要重新进行开发，因为，客户常常不知道他们的真正需要，而开发者也不知道。用户提出“需要”的特性并不总是与用户利用新产品来处理他们的任务 ( t a s k )时所需的功能相等价。因此，当你收集到用户的意见后，必须分析、整理这些需求意见，直到你理解它为止，并把你的理解写成文档，然后与用户一起探讨，这是一个反复的过程，并且需要花费时间。如果你不在这一方面花时间，对预期产品一致的看法未达成共识—最终的后果可能是返工，并且产品不尽人意。 7.1 需求的来源软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需从不同用户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。下面是几个软件需求的典型来源。 1. 访问并与有潜力的用户探讨为找出新软件产品的用户需求，最直截了当的方法是询问他们。本章讨论如何寻找合适的用户代表，而在第8章讲述从这些代表中获取需求的技巧。 2. 把对目前的或竞争产品的描述写成文档文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。 3. 系统需求规格说明一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（ Nelsen 1990）。附加的详细软件功能需求将从有关软件的系统需求里获得。 4. 对当前系统的问题报告和增强要求第7章寻找客户的需求53 下载下载指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。 5. 市场调查和用户问卷调查调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。 6. 观察正在工作的用户对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。 7. 用户任务的内容分析通常通过开发具体的情节（ s c e n a r i o）或活动顺序（有时称作“情节”），可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。这是使用实例方法的精髓（参看第 8章）。 7.2 用户类产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。比起其他用户，其中某些用户类的需求可能对你更为重要（ Gause and Lawrence 1999）。每一个用户类都将有自己的一系列功能和非功能要求。比如：一个没有经验或偶尔使用电脑的用户关心系统是否简单易用，因此，菜单、提示符和向导是很重要的。然而，对于那些一天使用几小时产品的用户，他们更关心产品的易用性和高效性，所以他们喜欢使用快捷键、宏以及脚本功能(scripting facility)。有一些受产品影响的人并不一定是产品的直接使用者，而是通过报表或其它应用程序访问你产品的数据和服务。这些非直接的或次级 ( s e c o n d a r y )的用户也有他们的需求，于是他们组成了附加的用户类。就像我的同事 K a t h y所说的：“只要一日是你的用户，则终身都是你的用户。” 用户类不一定都指人，你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。在项目中，要尽早为产品确定并描述出不同的用户类，这样，就能从每一个重要的用户类代表中获取不同的需求。我听说过一个给 6 5个团体用户开发一个专门的业务产品的公司，当他们意识到可以把用户分成 6个截然不同的用户类时，这些用户对未来发行的产品的需求就被简化了。在软件需求规格说明中，把这些用户类和他们的特征编写成文档。现举一例，在前面所讨论的“化学制品跟踪系统”中，项目的管理者所确定的用户类和他们的特征如表 7 - 1 54第二部分软件需求工程下载下载所示。表7-1 “化学制品跟踪系统”的用户类药剂师药剂师将使用系统请求来自供应商和仓库的化学制品。药剂师每天多次使用系统，主要用于跟踪进出实验室的化学制品容器。药剂师需要在供应商目录中查找指定化学制品采购者采购者在采购部门处理其他用户所提交的化学制品请求，他们与外部的供应商建立联系，制定并发出订单。采购者对化学制品几乎不了解，因此将需要简单的查询机制来查找供应商目录。采购者不使用系统中容器跟踪这一特性。每个采购者平均每天使用系统 1 0次化学制品仓库人员化学制品仓库人员包括三个技师，管理着多达 500 000种化学制品容器。他们将处理来自药剂师的请求并提供可用的容器，向供应商请求新的化学制品以及跟踪进出仓库的所有容器的流向，他们是货存清单和化学制品使用报告特性的唯一使用者。由于交易量大，化学制品仓库人员所使用的系统功能必须是自动化并且高效卫生和安全人员卫生和安全人员使用系统是为了生成符合官方关于化学制品使用和处理规则的季度报表。这些报表必须提前定义，并不需要特别查询能力，当官方的规则改变时，卫生和安全管理人员可能每年多次要求变化报表中的内容。报表变更优先级最高 7.3 寻找用户代表每种类型项目—包括企业信息系统、商业应用程序、集成系统、软件嵌入式产品、 We b 开发程序和签约合同的软件—在获取（e l i c i t a t i o n）用户需求时需要挑选合适的用户代表来反映各类用户的需求。用户代表必须参加整个软件开发生存周期，而不仅仅是只参加开始的需求阶段。虽然你必须把重点放在最重要的用户代表身上，但是你还是需要广泛的用户参与者来代表不同的用户类和不同的专业层次。当公司开发应用程序时，最容易接近真正的用户。然而，如果你正在开发商业软件，可能要在开发过程的早期阶段，从目前的 b e t a测试版或先前版本产品的使用者中收集需求意见。建立现存的长期客户关系或组成一个核心用户组，它是由目前产品的用户组或竞争产品的用户组组成的。如果建立起一个用户组，必须明确，这些参与者是否真正代表了各个方面的用户，而这些用户的需求是否可以促进产品的开发。核心用户组必须包含各种用户类型，不仅包括知识渊博的用户，还应包括缺乏经验的用户。如果核心用户组仅代表早期的需求提供者或空想家，那么将会遇到一系列复杂和技术上困难的需求，这些需求与目标市场没有太大的关系。图7 - 1描述了用户的需求和开发者之间的一些典型的信息关联。当开发者能直接与有关的用户对话时，就产生了最直接的交流；非直接联系一般是无效的（ Kiel and carmel 1995）。就象孩子们“打电话”的游戏一样，在用户和开发者之间插入一些中间层，会增加他们之间交流信息时产生错误的可能性。例如：如果开发者只向最终用户的管理者获取意见，那么这些需求就不太可能正确反映用户的需要。你必须确信，插入的这些层次是具有价值的，就像一个有经验的需求分析员可以与用户或其他参与者一起工作，为开发者收集、评价并组织整理需求信息。必须确信你明白你所承担的风险，这个风险就是使用市场人员或其他人员作为用户真正需求的代理人，你还要判断这些风险是否值得承担。虽然要获得最优的用户代表是困难的，且可能要花很多钱，然而，第7章寻找客户的需求55 下载下载如果你不与能提供最佳信息的人交流，那么你的产品和用户将蒙受损失。产品代表需求分用户采购者市场人员析者开发人员用户管理者系统设计者帮助桌面图7-1 用户和开发者之间的可能通讯路径 7.4 产品的代表者许多年前，我曾经是一个软件开发小组的成员，这个开发小组支持着一个大公司的科学研究活动。当我们组建开发组时，决定我们的每一个工程项目都包括为数不多的核心参与者，这些参与者来自相关的用户团体，并提供客户的需求。我们称这些人为产品的代表者（project champion）或项目的代表者，（Wedgers 1996a）。通过产品代表者这一途径，可以提供一个有效的方法来使客户—开发者之间的伙伴关系结构化和形式化。每一个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。产品代表者必须是真正的用户，而并不是用户的代理人，如主办者、产品客户、市场人员或者软件组成员充当用户。产品代表者从他们所代表的用户类中收集需求信息。每个产品代表者都负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。目的就是由每个产品代表者与分析员合作，为那个用户类整理出统一的需求意见。虽然分析员通常起草需求文档，但需求的收集与整理是分析员和一些核心客户的共同责任。一个优秀的产品代表者对新系统有明确的认识并有极大的热情，因为他们知道新产品将使他们以及他们的伙伴受益。产品代表者必须是有力的交流者，且是同组成员的代表者。他们必须对应用领域有彻底的了解，并在软件方面具有足够的经验，他们知道在当前技术背景下，什么是可行的；在运行环境中，什么是可实现的。通常，许多产品代表者在工作中又去承担其它的任务，因此，你必须有令人信服的观点，阐明一些特殊个人的参与对项目的成功具有重要意义。如果产品代表者有足够的权利为他们所代表的用户作出共同的决定，那么他们将会很好地发挥作用。如果产品代表者的决策总是受到管理者或软件开发小组的否决，那么他们所花的时间和心思 ( g o o d w i l l )就白白浪费了。然而，产品代表者必须牢记，他们不是唯一的用户。我曾经见过产品代表者工作失误，因为充当核心联络角色的产品代理者没有与他们的同行进 56第二部分软件需求工程下载下载行充分的交流，而仅仅代表了他们自己的需求和对产品的概念。 7.4.1 寻求产品代表者如果你正在开发业务软件而不是内部软件，就很难在你的公司之外寻找可以充当产品代表者的人。但是，如果你与一些大公司的用户有着紧密的工作伙伴关系，那么他们会很乐意或（要求）参与用户需求获取。此时，你将面临着一个挑战：如何避免片面地听取某些产品代表者的需求而忽视了其他代表者的需求。如果有一个广泛的客户基础，那么你就有可能先确定代表所有客户的核心需求，而后确定对于特定个体客户和用户类的附加需求。只有在产品代表者通过商业展示会或其它专业上的交流相互联系之后，他们才可能与其它公司的产品代表者相互交流。不过，这样存在着风险，因为这种讨论交流可能泄漏内部业务过程的细节，潜在地影响了每个公司的竞争力。如果一个知道本公司未来产品计划的产品代表者把这一内部信息告诉那些不应该知道这一信息的人，应该怎么办？双方签署不泄密协定有助于解决这一问题，但这种协定对私人秘密没有保证。另一种可能性是产品代表者所在的公司可能决定不购买早期版本的产品，因为他们知道更好的版本即将发行。此时，可能需要给你的外部产品代表者一些经济上的鼓励以获得他们的贡献，例如提供产品打折或者聘请他们与你一起进行用户需求的讨论工作。另一种方法是真正聘请一个具有丰富阅历的合适的产品代表者。一个为某一特殊产业开发零售销售点（point-of-sale POS）和后台办公系统（ b a c k - o ff i c e）的公司曾经聘请了三位零售店的经理来充当全天候的产品代表者的角色。还有一个例子，我的长期家庭医生 A r t，放弃了他的行医生涯，现在在一个医学软件公司工作，作为一个产品代理者为公司提供医生对产品的需求。A r t的老板清楚地认识到，聘请一个医生来帮助他们开发软件是值得的，因为这个软件最终将被其他医生欣然接受。另一个公司从大多数客户中聘请了许多以前的雇员，这些雇员可以提供有价值的关于本部门的专门知识，还可以提供对客户组织中策略的认识。 7.4.2 产品代表者的期望把产品代表者的期望编写成文档，这样有助于通过产品代表者这一途径获得成功。当然，并不是每一个产品代表者都能提供你所喜爱的服务，此时，你可用书写期望建立实例的方法，让特定的用户来填写这一关键的任务，并作为探讨每个产品代表者确定责任的起点。表 7 - 2确定了产品代表者的活动。并不是在每种情况下都要有这些活动，但是在不同的项目中，产品代表者执行其中不同的活动。表7-2 产品代表者的可能活动分类活动计划（p l a n n i n g） . 转化产品的适用范围和局限性 . 定义与其它系统的外部接口 . 定义从目前用户应用程序过渡到新系统的过渡途径需求（r e q u i r e m e n t） . 访问其它用户，收集他们的需求描述 . 提出使用脚本和使用实例 . 解决所建议的需求之间的冲突 . 定义实现优先级 . 确定质量属性和其它非功能需求 . 评估用户接口原型第7章寻找客户的需求57 下载下载（续）分类活动验证和确认 . 审查需求文档（verification and validation） . 确定用户接受标准 . 根据使用脚本编写测试用例 . 进行b e t a测试 . 提供测试数据集用户帮助 . 编写用户手册和在线帮助 (user aid) . 准备教学用的培训材料 . 为同行者提供产品演示变更管理 . 对缺陷的改正进行评估并设置其优先级（change management） . 对增强（e n h a n c e m e n t）的请求进行评估和设置其优先级 . 评估需求变更给用户带来的影响 . 参加变更控制委员会并参与变更决策 7.4.3 多个产品代表者 “化学制品跟踪系统”有四个用户类，因此在 Contoso Pharmaceutical需要从内部用户群中选择多个产品代表者。图 7 - 2描述了项目总经理如何建立产品代表者小组以从各个渠道收集有效的需求。这些产品代表者并不是全职，但他们每个星期都要花数个小时在项目研究上。三个分析员与四个产品代表者一起协作进行需求获取、分析，并把它们的需求编写成文档（采购人员和卫生与安全用户类很小，他们的需求也不多）。然后由一名分析员综合这些信息，并编写到软件需求规格说明中。分析员1 药剂师产品药剂师预药剂师代表者备组采购员产品购买者代表者项目总经理分析员2 卫生与安全产健康和安品代表者全人员化学制品仓库药品仓库分析员3 产品代表者人员图7-2 “化学制品跟踪系统”中的产品代表者模型指望由一个人来提供一个大型用户类的所有需求是不现实的，这样的用户类正如在 Contoso Pharmaceutical中由几百名药剂师组成。因此，代表药剂师用户类的产品代表者组织了一个由五个药剂师组成的预备组，这五个药剂师分别来自公司的不同部门。五个药剂师从他们各自部门的同行中收集信息，分析他们对“化学制品跟踪系统”所提出的问题，并为他们的同行提供项目状况的修改。这种分层方法增加了获取需求的用户数，但避免了大量的开销，这些开销主要用于整理和协调大量收集需求的专题讨论会或者长时间连续个人访问。化 58第二部分软件需求工程下载下载学药剂师产品代表者总是力求达成一致意见，但是当他们意见不一致时，他们总是乐于作出必要的决策，因此，项目总能向前推进，而不是陷入僵局。 7.5 谁作出决策我曾经在卫星发射中心见到一位在大型开发公司工作的项目经理。当我问他为谁工作时，他给我四个名字：当地的开发经理、总部的开发经理、还有两个来自其他客户群的业务单位经理。这个项目经理感到十分沮丧，因为他总是收到令人迷惑的信息，总是被四个领导的不一致决策甚至相反的决策所误导。当需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在每个项目的早期阶段，你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策，或者授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。这是一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用产品代表者这一手段，必须解决来自不同用户类的相冲突的需求。通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切相关，并能得到关于这些问题的广泛信息。我倾向在大家一致决策之上参与决策。达成一致意见固然是理想的，但在风险承担者对每个问题作出决策的同时，你不能停止项目的进展。下面是一些在项目中可能发生的决策问题，并带有建议性的解决方案。项目中的领导者需要决定：当这些问题发生时，谁可以决策该如何做，并且在不能达成一致意见时，由谁来协调这一冲突。 . 如果个别用户不能在需求方面达成一致的意见，那么必须由产品代表者作出决策。产品代表者这种方法的实质是授权给产品代表者，由其解决他们所代表的需求冲突问题。 . 如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于你决定哪一个用户类所占份额最大。 . 不同公司的客户可能都要求产品按照他们各自的喜好来设计。还是老办法，运用项目的业务目标来决定那些是你最关心的客户。一个核心的客户有助于主要特性的开发，然而，其它你认为获利较少的客户需求可能要拖延到下一个版本中去。 . 有时，客户经理所提出的需求与他所在部门的真正用户提出的需求相冲突。用户需求必须与业务需求一致，因此，那些没有亲自使用过产品的经理必须服从代表他们用户的产品代表者提出的详细的用户需求和功能性规格说明。应避免强迫开发人员对客户不同意的需求作出公断，因为这是一个十分失策的观点。 . 当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。然而，不要陷到 “客户总是对的”的陷阱中去，对他们百依百顺。现实中，客户并不总是对的。客户总是持有自己的观点，开发者必须理解并尊重这一观点。 . 如果市场部门所提出的需求与开发者所想要开发的系统发生冲突时，类似的情况就发生了。作为客户的代理人，市场需求具有更重的分量。但是，我常见的情况是：市场总是迁就客户需求，而不管这些需求的合理性和费用如何。我还见过其它的情况：市场提供第7章寻找客户的需求59 下载下载极少的信息，而必须由开发者去定义产品并且由他们自己编写需求文档。没有简单的正确答案。在遇到这些问题之前，你决定谁将对项目需求作出决策，以免由于优柔寡断和对先前决策的回溯导致你的项目停工。下一步： . 在你所处的环境中，把听取客户需求的方法与图 7 - 1联系起来。在你当前的交流联系中是否遇到一些问题？确定最短的并且最有效的交流途径，在将来可根据这一途径收集用户需求。 . 为项目确定不同的用户类型并决定谁将成为每个用户类的产品代表者。利用表 7 - 2 作为一个起点来定义你希望产品代表者所具备的功能。与产品代表者和他们的经理商讨，有助于你的项目开发。 . 决定谁是项目中需求问题和冲突解决方案的决策者。你目前的决策者业绩如何？失误在什么地方？这些人适合作决策者吗？如果回答是否定的，那么在开发者必须亲自解决这些问题之前，决定谁将参与需求决策工作，并提出协调建议。

展开阅读全文