获取客户需求的十大沟通技巧_项目管理文章库

用户名密码

联盟服务关于我们联系方式收藏本站

PgMP认证，美国项目管理协会高端项目管理认证！大型项目与项目群管理Program Management全球权威认证

服
务
区

网站登录：会员企业专家服务商
企业服务：PMP培训内训课公开课
工具箱：发表文章提问题发案例

首页：动态 | 文库 | 下载 | 书架 | 访谈 | 专栏 | 专题 | 人才 | 培训 | 软件 | PMC

互动：活动 | 案例 | 问答 | 论坛 | 博客 | 圈子

应用：基础┊工程┊软件┊制造┊活动┊研发认证：PMP┊NPDP┊ACP┊PgMP┊IPMP┊P2┊ISPMP┊IMCP┊建造师┊MPM 特色：热点┊奖项

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

当前位置：文库首页 >> 文章内容

获取客户需求的十大沟通技巧

作者：佚名提交人：项目管理者联盟[佚名] 属性：提交人转载发布时间：2007/12/13 点击：6379 【收藏本文】

　　成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。 bbs.mypm.net
www.mypm.net
　　需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。项目管理者联盟
项目管理培训
　　其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是很明确的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。项目管理者联盟
项目管理者联盟
　　需求获取活动建议要完成的11个任务或者说步骤分别是确定需求过程、编写项目视图和范围文档、用户群分类、选择用户代表、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用。当然应该根据组织和项目的具体情况进行适当的裁减，比如根据项目和用户情况把需求获取会议改成问卷调查或者座谈等等。 bbs.mypm.net
pmp.mypm.net
　　1、编写项目视图和范围文档

　　系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益，反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。项目管理者联盟
项目管理者联盟
　　非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性，所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识，整个项目组都应该把注意力集中在项目目标和范围上。
club.mypm.net
　　2、用户群分类项目管理者联盟
项目管理者联盟
　　系统用户在很多方面存在着差异，例如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等。根据这些差异，你可以把这些不同的用户分成不同的用户类。与UML中Usecase的Actor概念一样，用户类不一定都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。项目管理者联盟
项目管理者联盟
　　3、选择用户代表项目管理者联盟
项目管理者联盟
　　不可能对所有的用户都进行需求获取，这样做时间不允许效果也不一定好，所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。每类用户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策，用户代表往往是本类用户中三类人：对项目有决定权的领导、熟悉业务流程的专家、系统最终用户。项目管理培训

　　每一个用户代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口，用户代表从他们所代表的用户类中收集需求信息，同时每个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。项目管理者联盟
项目管理者联盟
　　4、建立核心队伍项目经理圈子
bbs.mypm.net
　　通常用户和开发人员不自觉的都有一种我们和他们的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的边界，只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点益处，良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功对方需要什么时，才能建立起一种合作关系。项目管理者联盟

　　为了建立合作关系通常采取一种组队的方式来获取需求，建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意以下原则：小组会议应该由中立方来组织和主持，用户和开发人员都要参加；交流预先要确定准备和参与的规则；议题要明确并覆盖所有关键点，但信息来源应该自由；交流目标要明确，并告知所有的成员。项目管理者联盟
项目管理者联盟
　　5、确定使用实例 talent.mypm.net
项目管理者联盟
　　从用户代表处收集他们将使用系统完成所需任务的描述，讨论用户与系统间的交互方式和对话要求，这就是使用实例，一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点，比起使用以功能为中心和以开发者为中心的方法，使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述，尽量使用主动语态，系统或者用户作为主语，比如用户提交用户密码，系统验证用户密码是否正确，还有一点在描述中不要设计界面细节，比如用户从下拉框中选择产品类型。使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材。项目管理者联盟
项目经理博客
　　6、召开联合会议项目管理者联盟
talent.mypm.net
　　最常见的需求获取方法是召开会议或者面谈，联合会议是范围广的、简便的讨论会，也是核心队伍成员之间一种很好的沟通方法，该会议通过紧密而集中的讨论得以将用户代表与开发人员间的合作伙伴关系付诸于实践并能由此拟出需求文档的底稿。联合会议的第一个议题就是系统的必要性和合理性，必须所有成员都同意系统是必要的而且合理的。接下来就可以讨论使用实例清单，清单可以打印成大纸挂在墙上、写在黑板上或做成演示材料。对每个清单合并去掉重复项，加上补充内容就可以得到一份总的清单，注意避免采用负面的太差不可行去否定用户的想法，这些想法都应该保留下来作为被评议的清单项，这样保护了小组成员开放的思维。最后对清单进行讨论，会议成员必须检查每一个使用实例，在把它们纳入需求之前决定其是否在项目所定义的范围内，形成最终的需求报告。项目管理者联盟
项目管理者联盟
　　在进行讨论时，也应该避免受不成熟的细节的影响，在对系统需求取得共识之前，用户能很容易地在一个报表或对话框中列出某些精确设计，如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制，应确保用户参与者将注意力集中在与所讨论的话题适合的抽象层上，重点就是讨论做什么而不是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完成需求。在讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正，因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候，会议就算成功完成了。但是要清楚需求过程本身就是一个迭代的过程，在以后的过程活动中不可避免的将要修改和完善这份报告。项目管理者联盟
PgMp.mypm.net
　　7、分析用户工作流程项目管理者联盟

　　分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号，为每个用例分配一个唯一的编号，为需求的追溯提供了方便；参与者，与这个用例交互的actor；前置条件，开始用例前所必须具备的系统状态；后置条件，用例完成后系统达到的状态；基本路径，用例完成的关键路径，也是用户期望的路径；扩展点，基本路径的分枝，表示意外情况；字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用；设计约束，实现用例的非功能约束。写基本路径时应该使用主动语句；句子以actor或者系统作为主语；一句表示一个actor动作，一句表示系统动作，交叉表现交互；不要涉及界面细节，比如用户在文本框输入名称，下拉框选择类型。项目管理者联盟
项目管理者联盟
　　8、确定质量属性项目管理者联盟
club.mypm.net
　　在功能需求之外再考虑一下非功能的质量特点，以及确定由于特殊的商业应用环境对系统提出的功能或性能上的约束，这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义，并且要将质量属性分配到每个用例的设计约束中去。 www.mypm.net
training.mypm.net
　　9、检查问题报告 training.mypm.net
项目管理培训

<<上一页 1 2 下一页>>

[发表评论]

本站热点

栏目说明

《文库》栏目为项目管理者联盟网站核心栏目，收录了十大行业项目管理文章5000余篇，囊括了项目管理五个阶段、九个知识领域的相关文章，是广大项目管理爱好者学习的知识库，欢迎大家发表原创文章、转贴文章，或直接发给编辑。须联盟会员且登陆后才能发表文章。

项目管理活动

活动QQ群：531390275
免费积累PDU,仅500人
2022年项目管理活动计划
2021活动精彩回顾

原创排行榜

项目管理评论杂志	311	高扬	106
乔东	100	项目管理	84
高国伟	61	人月神话	60
张为	59	郭致星	52
蒋昕炜	46	肖杨	38
曾伟强	37	潘德有	36

搜索文章

关键词：

行业：

团队成本风险进度
沟通采购质量合同

更多>> 专题集锦

企业项目化管理

PMO实践与应用

如何处理项目客户关系

经理访谈

个人专栏

王树文

赵春明

高国伟

项目管理者联盟特刊

	联盟特刊是对网站会员发行的内部刊物，刊物内容包括：案例及分析等，得到了会员好评。
电子期刊：
特刊下载：
2017合刊 2016合刊 2015合刊 2014合刊 2010合刊 2009合刊 2008合刊 2004合刊 2005合刊 2006合刊 2007合刊

施工企业管理

	《施工企业管理》创刊于1986年1月，中国施工企业管理协会主办，是反映施工企业管理杂志。
浏览往期：

建造师杂志

	《建造师》杂志由清华国际工程项目管理研究院主办，是中国面向建设企业管理人的高端杂志。
浏览往期：

如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者

PMI,Project Management Professional, OPM3, PMBOK, PMP，PgMP，PfMP，PMI-ACP，PMI-PBA
and the PMI Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc.