浅谈IT行业与客户沟通的技巧

二十一世纪是信息社会的世纪, 而IT行业作为信息社会的代表性行业, 更是充当着排头兵与先锋队的角色代表作用。在IT行业, 我从业13年, 期间曾担任过需求调研员、软件开发员、系统分析员等职务。下边我就结合自己的实际经验, 谈一下IT企业软件开发过程中需求调研阶段与客户进行各种沟通的技巧。

我们知道成功的软件产品是建立在成功的需求基础之上的, 而高质量的需求则来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决, 而开发人员开始帮助用户解决这个问题的时候, 沟通就开始了。而需求获取阶段可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识:用户知道需求是什么, 我们所要做的就是和他们交谈从他们那里得到需求, 只要把相关问题问到, 了解到什么样的软件能满足用户的需要就可以了, 但是实际上需求获取并不是想象的这样简单。

正确的需求调研之路我认为应首先要定义获取问题的范围, 即准确定位用户需要什么, 用户要通过我们的软件, 我们的系统实现什么, 最终通过输入输出获取什么样的结果, 有什么样的界线。系统的边界往往是很难明确的, 而用户往往又不了解或者不愿意了解我们具体技术实现的细节, 这样如果我们的调研人员自身再忽略相关界限问题, 就很容易造成系统目标的混淆, 从而导致最后我们的软件开发出来之后和用户想象的差别很大。

其次是对问题的理解, 目前国内很多非计算机专业用户对计算机系统的能力和限制可以说还是缺乏了解的, 很多用户只知道自己需要的系统, 而不知道系统的整体情况, 他们不知道系统作为一个整体怎么样工作效率更好, 也不太清楚哪些工作可以交给软件完成, 他们不清楚需求是什么, 或者说如何以一种精确的方式来描述需求, 他们需要开发人员的协助和指导, 但是用户与开发人员之间的交流很容易出现障碍, 忽略了那些被认为是“很明显”的信息。最终对我们的软件开发出来的成果造成致命性的打击和伤害。

最后是需求的确认, 因为需求的不稳定性, 往往随着时间的推移用户会不断产生新的变动和新的需求, 使之难以确认。在软件开发的后期, 甚至实施阶段, 随着信息化项目的应用及开展, 对用户实际业务操作产生的影响越来越深入, 用户必将不断有新的业务需求提出。开发人员常常有应接不暇的感觉。为避免此类问题的发生, 必须有组织地执行需求的获取及确认活动。

针对上述问题, 我们与客户沟通应掌握如下技巧:

1. 在与客户完全沟通前, 做好充分相关准备

软件系统的需求包括四个不同的层次:业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益, 反映了组织机构或用户对系统、产品最基本的目标要求, 它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务, 这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能, 使得用户能完成他们的任务, 从而满足了业务需求。非功能性需求是用户对系统良好运作提出的期望, 包括了易用性、反应速度、容错性、健壮性等质量属性。需求获取就是根据系统业务需求去获得系统用户需求, 然后通过需求分析得到系统的功能需求和非功能需求。我们在与客户进行沟通前, 应围绕系统的业务需求及用户需求准备相关详细的项目视图、范围文档及方案脚本。在初步的沟通中, 为用户提供明确的软件功能界限、项目功能规划。

2. 站在用户的角度设计问题、理解问题

通常用户和开发人员不自觉地都有一种“我们和他们”的想法, 产生一种对立关系, 把彼此放在对立面, 每一方都定义自己的“边界”, 只想自己的利益而忽略对方的想法。他们通过对话、谈判来沟通, 而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的, 不会给双方带来一点益处, 良好的沟通关系没有建立, 会导致误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么, 同时也知道要成功对方需要什么时, 才能建立起一种合作关系。

为了建立合作关系通常采取一种组队的方式来获取需求, 建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧, 小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流, 但交流时应注意以下原则:小组会议用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点, 但信息来源应该自由;交流目标要明确, 并告知所有的成员。记得我在一家公司时, 单位主要从事县级供电局营销及生产信息管理系统 (Mis) 的开发, 项目调研开始阶段, 因为没有对调研内容、沟通方式等进行充分准备, 项目调研人员到达现场后, 一直存在着与客户的对立局面。客户因长期从事基层手工用电营销工作, 已习惯手工计算、存储及信息交流方式, 对于计算机信息系统不太认可也不相信。部分业务操作人员甚至存在消极抵触情绪。在充分认识到沟通的必要性后, 我方现场调研人员主动深入一线与相关用户接触, 并通过windows使用技巧介绍、office操作培训等方式与用户建立了较为良好的沟通互动关系, 通过操作系统、常用办公系统软件的培训、介绍和推广, 让用户充分认识到了借助于计算机信息系统取代以往手工方式的方便性和安全性, 完全站在用户的角度最终让用户接受了该套营销管理软件的管理方式, 顺利完成了项目的调研工作。

3. 需求的检查、确认及重用

在软件开发的过程中, 常常存在着这样的问题:随着信息化系统的逐步普及, 以及客户在系统试运行及正式运行过程中, 对电脑应用知识、操作水平的提高, 必然会对原始提出的需求, 有新增或者是反复要求。还是以上面县级供电企业营销管理Mis软件为例, 现场调研结束后, 我们的团队转入开发, 当时分了三个比较大的模块, 因开发力量有限, 三个模块没有并行开始, 而是采用先后开发的顺序完成。这样在第一个模块开发及内部测试完成后, 第二个模块转入开发过程中, 第一个模块已经开始交付客户试运行。当时想着没有太大问题, 项目组的主要核心力量也都集中在公司本部进行第二模块的开发工作, 只安排了几个人员去用户现场实施。但很快, 整个情况就发生了较大的逆转:现场实施人员除了有少量系统BUG修改外, 不断有大量的用户新需求及二次开发任务反馈, 造成项目后期, 项目组的大部分人员都在疲于解决第一模块的更新替代工作, 项目的后续模块工期严重滞后, 给整个项目的实施与完成带来了较大的损失。

之后我们进行了分析, 最终得出问题的关键所在, 还是需求调研中与客户的沟通问题。项目初步启动时, 用户方受环境、业务操作习惯等客观因素影响, 对整个信息化乃至计算机处于启蒙阶段。对于希望能够借助于计算机信息系统实现的功能目标、完成状况, 由于受到对整个电脑、网络知识欠缺的制约, 需求的提出和实际的需求存在着较大的差距, 而现场调研人员未充分认识到这一情况, 在将用户的调研情况转变为信息系统的需求时存在着严重的缩水。开发出来的东西, 经过一段时间的试用及熟悉后, 用户势必会提出来更多更新的要求, 这些要求对于用户而言是无可厚非, 但最终造成了上述问题, 后期开发所有项目组人员都在疲于奔命解决这些问题, 严重影响了工期。

认识到上述问题后, 在第二阶段的需求调研过程中, 我们着重要求了现场调研人员对上述问题的重视。在与客户的沟通中, 着力加强了需求信息的统计、归总及检查确认工作。其中确认工作必须有纸质文件及调研双方人员签字认可。有效的界定了项目开发的范围, 对后期的变动进行了有效的控制。同时在项目开发、内部测试及试运行准备过程中, 仍不断与客户沟通, 随时获取最新的变化动态与资料。保证开发始终是在一条有利于双方的正轨上进行。按照上述方法, 项目第二阶段的几大模块均顺利得到了实施, 按时保质地完成了任务。

最后, 谈一下需求信息的重用, 这个重用, 不仅仅是对客户要求、软件实现功能的重用。更为重要的, 则是现场调研人员与各阶层客户、相关业务操作者、利益管理者等进行有效沟通的实践经验的重用。

参考文献

[1] 百度百科

[2] 虫师.软件的需求分析如何做?http://www.ltesting.net, 2012-1-20

[3] 如何能够读懂需求?http://www.ltesting.net, 2012-2-23

[4] Ivar Jacobson, James Rumbaugh, Grady Boochu著.《统一软件开发过程》.周伯生译.机械工业出版社, 2002.1