项目客户沟通环节经验调研评估报告1. 概述：公司自从转型以来，已经经历了大约一年的时间，在这一年中，我们共实施了几十个项目/产品，从中积累了大量的项目经验，不过，这些经验都是存在于和客户直接沟通的项目经理、咨询工程师以及实施人员的头脑中，而随着项目的增多，这些人员也非常忙，很少有机会能进行系统的总结。而在这公司过程体系中，却一直是一个弱项。因此我们决定做一次这方面的调查，目的是将大家的经验和教训都积累起来，在组织内部共享。我们调查时主要采用访谈的方式，在访谈时，为了让大家畅所欲言，事先约定对访谈的内容保密，并且确定在最终的评估报告中，不会涉及到任何一个项目以及人员。在访谈中我们发现，每个人员都积累了相当丰富的经验，但是几乎每个人的经验都是不一样的；而且发现有一部分同样的问题，会在不同的项目中出现，因此我们也强列感觉到共同总结共同提高的必要性。从结果来看，基本上得到了我们需要的信息，成为我们下一步改进的基础。1.1 调查目的通过对于客户直接沟通环节的调查，进行经验总结、积累和共享。根据最佳实践改善现有过程。1.2 调查范围阶段：关注于项目的售前和售后，主要包括：商务谈判及合同签订、需求获取、项目沟通、部署、验收、维护等环节。人员：公司内项目经理、咨询工程师、开发经理、部署实施人员1.3 调查方法：主要采用人员访谈的方式，事先准备被调查问卷及调查计划。对每一位被访谈者进行独立访谈。提取经验和教训，总结出评估报告。1.4 调查统计：目前有与客户沟通经验的人员总部为：16人，实际调查人数：11人，覆盖率：69%。在实际调查人员中，项目经理/咨询工程师6人，占55%，开发经理3人，占27%，实施工程师2人，占18%。覆盖事业部：4个2. 经验总结：2.1 商务谈判及合同签订2.1.1 存在问题为了签单，随便给客户进行承诺，开空头支票，结果会影响到客户的满意度降低，这种情况在商务人员中比较多。在签订合同的时候，没有进行充分的估计，往往对公司的能力估计过强。在签订合同的时候，要确定合适的项目目标，并估计公司的实际能力。根据用户方的进度要求来压缩项目的合同工期，而不考虑项目的实际能力，方案不成熟的时候这样做风险很大，实际的工期往往相差很大。项目范围不明确，导致后期需求的范围无限扩大，得不到控制，在被调查的项目中，最求变更大的达到了60%以上，变更最小的也达到了1020%，项目的需求变更成了家常便饭。高级经理或者渠道直接签单，与事业部沟通不足。2.1.2 签约技巧及经验：目前大家对于签约的认识已经得到了显著的提高，在访谈的过程中，已经没有人会认为合同签订是一个无关紧要的过程了，绝大部分人员已经认识到签约的重要性，对于条款的严肃性也有了充分的认识。在现有已签约项目中，后期合同的签订就比前期好了很多，这是一个不断完善的过程。由于签单时需要考虑竞争、以及用户对需求的不明确等因素，所以在合同签订的时候风险是必然会存在的，但是应该在合同签订的时候就考虑相应的风险处理策略，并对风险进行管理和控制，在风险较大的情况下，考虑暂时不签或创造条件后再签。项目范围确定是合同中一个非常重要的部分，签约早期，项目的需求越明确则项目风险就越小，如果需要在签单后的进行调研，可以在需求调研完成后将经双方确认的文档作为合同的附件，并且需要将变更控制办法放到合同条款中，和用户约定把每次变更作为合同附件保留。在合同中确定验收的条款也是非常必要的。合同条款方面，考虑对我方很不利的情况，尽可能与用户沟通避免。并且在签订合同及合同附件的时候，对于不宜直接表达的观点，可以换一种合适的方式与用户沟通。在和用户进行商务谈判的时候，需要考虑已有系统的成熟度和项目的赢利值，引导用户把需求范围靠近我们能实现的程度，寻找双方折中点，保证项目利润。签约时事业部项目经理、咨询工程师的参与是必须的，越早介入风险越低，成功率越高。是否签约以及项目范围的决定权最好在事业部。总部人员参与项目前期商务谈判的优势是：对系统较了解；与开发员沟通较多，能反馈开发员的意见；了解系统不能实现的功能，从而引导用户，从用户的利益上说服用户放弃技术上实现困难的要求等等。2.2 项目沟通2.2.1 客户沟通2.2.1.1 准备在访谈时，有部分项目在与客户进行面对面沟通之前，往往是临时性、突发性的，事前没有准备，这种情况所造成的结果是千里迢迢到客户那里时，才发现客户有其它的事情，忙别的去了，或者是找到了客户，而客户由于事前没有准备而得不到我们想要的结果。往往白跑一趟都是有可能的。客户不会在乎，因为反正差旅费和住宿费都是公司掏，还需要加上伙食和出差补助。口头的沟通也是常用的办法，这种方法直接而有效，缺点是随意性变动性较大。客户的沟通计划是必要的，各个阶段的沟通如有计划会加强客户的认知以及配合程度，这包括需求调研计划、部署计划（培训计划）以及验收计划。计划应是正式的，并与客户沟通确认，使客户方做好相应的人员、时间、设备、资料的安排；提高我方的工作效率，降低成本。在准备时，仅有计划是不够的，还需要准备好相关的材料，这些材料根据任务的不同而不同，材料准备可以是沟通计划的一部分。另外确定沟通的办法、熟悉客户使用的方法和工具、系统的试运行状态、准备问题以及应对措施、培训演练等等，都是准备的内容之一。2.2.1.2 客户关系与客户建立信任的关系是非常重要的，这方面在项目前期可以采用让客户来参观公司、推广公司品牌的知名度等措施来实现，后期则需要建立在产品以及服务的品质上了。在项目实施过程中，与用户建立良好的伙伴关系，这是一个双赢的局面，也是做客户关系的较高境界，只有客户的成功才是我们的成功。有关客户沟通的层面上，前期商务谈判时确定利益约定；对于决策层的沟通一定是充分而必要的，这关系到整个项目能否签订、如期完成、验收以及收款等一系列关键步骤，但是同时一定不要忽视与底层也建立良好的关系，当与用户要求很难统一的时候，必要时需要采取非正常手段（如，请客）。在部分项目实施过程中，遇到了由于客户内部矛盾导致项目受阻的情况发生，因此我们在处理客户关系的时候，需要尽量避免卷入客户内部的矛盾之中，这里面的解决方法可能是在签约时就确定项目负责人，统一项目出口和入口，引导用户负责人理解系统，培养用户负责人理解和支持系统，进行必要的风险管理和控制等。2.2.1.3 沟通人员在访谈中发现，目前项目中有沟通人员不确定的情况存在，用户沟通过程当中，参与的人员较多，容易造成项目信息沟通瓶颈以及信息壁垒，这里需要有一个沟通的规划。需要对目标客户进行细分，针对不同客户采取相应措施，对成熟度低的客户，进行软件开发过程的培训有助于进行客户沟通和项目实施。2.2.2 与分支机构的协作大部分项目认为分支机构的支持力度应该加大，并且认为需要加强与分公司的协作，特别是后期的协作。分公司应该更多地参与到项目实施、培训和维护工作，建立良好的客户伙伴关系等活动中去。分公司对于系统的了解程度对系统成功开发有很大影响，应该加大对于分公司人员的培训。分公司对于项目的风险规避太少，与事业部的利益分享有冲突，这样在早期就引入了较大的项目风险，取决于公司的营销政策，公司需要在政策上进行利益分享的引导，明确各方的责权利。建议商务与项目相结合，建立利益共同体。2.2.3 内部协作有一个良好的计划是内部协作的前提，与内部项目组成员进行充分沟通是非常必要的。做项目计划并达成共识非常重要，目前组内共识的达成较为容易，项目经理跨部门协调能力较弱。目前由于部分项目没有计划，导致实施工程师对于用户反馈的问题的解决和时间安排不协调，系统测试不充分影响用户满意度；而开发组也需要实施人员准确的提前提出用户请求，安排相应的开发和测试工作。这里有关责任机制也需要明确。在内部遇到问题，可以内部进行解决，对于客户而言则是一个整体，不应将内部的协作问题暴露在客户面前。开发团队内的充分沟通交流非常重要，团队中直接交流和沟通是最有效的，需要经常及时对工作成果进行讨论。开发过程中人员的稳定、成员的能力和团队的合作、平等交流的气氛是项目成功的重要因素。2.3 需求获取2.3.1 调研时间建议：前期调研需要充分，时间不应太短，时间太仓促会影响到需求获取的质量和粒度，很难挖掘到客户真正的需求。由于充分了解客户需求后，后期的变更会相应降低，从而减少了由于返工而造成项目的拖延，在开发工期方面往往不会造成太大的影响。2.3.2 界面原型：界面原型是项目需求获取的较好的方式，业务模型的分析能力有助于系统的需求把握和实现。成熟度高的客户需求范围较容易早期就确定；对于成熟度低的客户，需求范围的前期确定较困难，有界面原型会更好，需要在后期加强沟通，对用户进行说服。没有界面原型对于需求获取是一个风险。2.3.3 获取客户真正的需求：在需求获取的过程中，进行具体客户分析，采取不同的策略。用户期望、业务实现、易用性是需要主要考虑的因素。在调研的时候需要找到关键用户人员，要明确需求的层次，决策层的需求是最重要的，但是也不能忽视底层的需求。在用户需求挖掘的时候，要注意用户隐藏需求的挖掘开发过程中非功能性需求往往被忽略，但是这类需求有决定性作用，要求在需求获取的过程中注意这类需求的收集和确认；不同的项目这类需求会不一样，和事业部的具体方案特性有关在调研的时候，如子系统较多，需要考虑整体性和相关的接口需求。在需求分析时，用户方参与会较好，另外在需求调研时，事业部直接介入能引导用户取出核心需求，成功率更高。客户需求在收集回来之后，一定需要和开发组达成共识，目前事业部制之后，该问题已基本解决，大部分情况都是事业部内咨询工程师与开发工程师结合共同进行需求获取，取得了较好的效果。2.3.4 需求范围控制从商务的角度出发，我们也需要尽量去控制需求的范围；如果在早期这样做有难度，则必须对于主流业务进行确认；挖掘用户的真正需求，给用户想象的空间，并考虑用户使用系统时候的感受，同时考虑现有系统实现的平衡，控制需求，和商务活动相联系，这里面有一些技巧是：谈的时候可以什么都谈，但记录的时候要进行需求过滤。将我们做不到的或者不容易实现对客户又不太重要的需求过滤掉。而且对于不能做的需求，不能直接回绝用户的，要采用一些技巧来处理。如：和用户沟通，给用户一个印象，软件制作是费时的，引导用户在功能和工期上做平衡，取消要求的需求。前期调研期间需要和客户形成一个对于系统的认识方面的共识。在项目前期需求调研的时候，对用户进行计算机和软件工程方面的知识培训，有利于和客户沟通，让客户站在我方的角度考虑问题尽量引导用户的需求，降低用户需求与现有系统间的差异。站在对方的角度说服用户，节约开发成本。高层对于项目需求的范围不要轻易表态，把需求收集和范围确定的权力交给项目经理2.3.5 需求变更控制对于需求的变更需要进行控制，前期的商务谈判、需求获取时均需要考虑后期需求变更控制的因素。对需求的变更越早发现越好，原则是把开发的精力投入最有价值的需求，及早实现最重要的需求。对于项目的核心模块是必需实现的对于发生的变更需要分析原因，并确定解决的方法，并与开发组、用户对变更的结果进行沟通。对于变更与客户达成共识也是非常关键的。其中也需要做好变更的配置管理。业务本身的成熟度对系统的需求稳定性有很大的影响。2.3.6 调研方式：调研的时候争取用户的配合，与用户面对面的沟通是必要的，后期再进行电话沟通会更顺利目前采用的调研方式大部分是：了解关键客户需求，在根据客户具体情况逐个部分访谈，记录整理需求，和用户确认达成共识。总结需求调研的步骤则是：调研计划系统概要的介绍详细的部分沟通调研总结调研结果和用户确认。2.3.7 需求记录与确认用户确认的记录是非常必要的，并在实施的过程中一定要想办法让客户