系统实施客户沟通环节经验评估报告(doc10)-销售管理(编辑修改稿)

系统实施客户沟通环节经验评估报告(doc10)-销售管理(编辑修改稿)内容摘要：

到 关键用户人员 ，要明确需求的层次，决策层的需求是最重要的，但是也 不能忽视底层的需求。 在用户需求挖掘的时候，要 注意用户隐藏需求的挖掘 开发过程中 非功能性需求往往被忽略 ，但是这类需求有决定性作用，要求在需求获取的过程中注意这类需求的收集和确认；不同的项目这类需求会不一样，和事业部的具体方案特性有关 在调研的时候，如子 系统较多，需要考虑整体性和相关的接口需求。 在需求分析时， 用户方参与会较好 ，另外 在需求调研时， 事业部直接介入 能引 导用户取出核心需求，成功率更高。 客户需求在收集回来之后，一定需要和开发组达成共识，目前事业部制之后，该问题已基本解决，大部分情况都是事业部内咨询工程师与开发工程师结合共同进行需求获取，取得 了较好的效果。 需求范围控制 从商务的角度出发，我们也需要尽量去 控制需求的范围 ；如果在早期这样做有难度，则必须 对于主流业务进行确认 ； 挖掘用户的真正需求 ，给用户想象的空间，并考虑用户使用系统时候的感受，同时考虑现有系统实现的平衡，控制需求，和商务活动相联系，这里面有一些技巧是：谈的时候可以什么都谈，但 记录的时候要进行需求 过滤。 将我们做不到的或者不容易实现对客户又不太重要的需求过滤掉。 而且 对于不能做的需求，不能直接回绝用户的，要采用一些技巧来处理。 如：和用户沟通，给用户一个印象，软件制作是费时的， 引导用户在功能和工期上做平衡 ，取消要求的需求。 前期调研期间需要和客户形成一个对于系统的认识方面的共识。 在项目前期需求调研的时候， 对用户进行计算机和软件工程方面的知识培训 ，有利于和客户沟通，让客户站在我方的角度考虑问题 尽量引导用户的需求，降低用户需求与现有系统间的差异。 站在对方的角度说服用户，节约开发成本。 高层对于项目需求的范 围不要轻易表态， 把需求收集和范围确定的权力交给项目经理 需求变更控制 对于需求的 变更需要进行控制 ， 前期的商务谈判、需求获取时均需要考虑后期需求变更控制的因素。 对需求的 变更越早发现越好 ，原则是 把开发的精力投入最有价值的需求， 及早实现最重要的需求。 对于项目的核心模块是必需实现的 对于发生的 变更需要分析原因，并确定解决的方法 ，并与开发组、用户对变更的结果进行沟通。 对于变更与 客户达成共识 也是非常关键的。 其中也需要做好变更的 配置管理。 业务本身的成熟度对系统的需求稳定性有很大的影响。 调研方式： 调研的时候 争取用户 的配合 ，与用户面对面的沟通是必要的，后期再进行电话沟通会更顺利 目前采用的调研方式大部分是：了解关键客户需求，在根据客户具体情况逐个部分访谈，记录整理需求，和用户确认达成共识。 总结需求调研的步骤则是： 调研计划――系统概要的介绍－－详细的部分沟通调研－－总结调研结果－－和用户确认。 需求记录与确认 用户确认的记录是非常必要的 ，并在实施的过程中一定要想办法让客户确认。 这是项目成功实施以及今后验收的基础。 这里面的原则是用户的 签字确认不是最重要的，最重要的是正确的理解用户需要 ，为了对双方均造成约束和承诺，防止随意变 更，需要用书面的形式确定下来――用户签字。 因此在调研结束后，确定备忘录时， 考虑作为合同附件的约束性，需 要慎重处理备忘录中的需求条款 ，并双方认可。 实施工程师在 现场部署过程中获取的用户要求 ，可以以邮件和文档的方式反馈回事业部的开发组， 在返回之前也需要和用户确认。 其它 目前公司项目 对于第三方产品的管控能力较弱 ，还有很多工作要加强。 在使用第三方软件的时候要慎重，要结合用户的需求进行深入的评估。 解决用户问题要有时间计划，调研人员来回的需求需与开发人员确认是否可行，然后何时解决，并给客户明确反馈。 给客户的承诺要争 取按时完成，如有变化要及时沟通。 在项目进度紧的情况下会采取极端编程的方式，提供给客户界面原型和现有系统进行试用来收集需求，文档较少，相关的沟通采用讨论会，要把用户纳入项目，这时候项目经理对需求的理解和把握成为关键瓶颈。 部署 存在问题 部署时经常碰到的问题是 软件本身的问题，软件功能不完善、软件的易用性、稳定性存在缺陷，对于培训不够重视， 现场环境复杂、客户配合度不高等等。 开发人员在现场部署时会导致 现场修改。 这对系统稳定性以及今后的维护工作造成了一定隐患，目前不提倡这样做。 部署人员、实施人员在与用户沟通的 时候 商务意识不够 ，造成系统变更、范围扩大等。 项目初始化工作是。