系统实施客户沟通环节经验评估报告模板.doc

项目用户沟通步骤经验调研评定汇报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 需求统计和确定用户确定统计是很必需，并在实施过程中一定要想措施让用户确定。这是项目成功实施和以后验收基础。这里面标准是用户签字确定不是最关键，最关键是正确了解用户需要，为了对双方均造成约束和承诺，预防随意变更，需要用书面形式确定下来用户签字。所以在调研结束后，确定备忘录时，考虑作为协议附件约束性，需要慎重处理备忘录中需求条款，并双方认可。实施工程师在现场布署过程中获取用户要求，能够以邮件和文档方法反馈回事业部开发组，在返回之前也需要和用户确定。2.3.8 其它现在企业项目对于第三方产品管控能力较弱，还有很多工作要加强。在使用第三方软件时候要慎重，要结适用户需求进行深入评定。处理用户问题要有时间计划，调研人员往返需求需和开发人员确定是否可行，然后何时处理，并给用户明确反馈。给用户承诺要争取按时完成，如有改变要立即沟通。在项目进度紧情况下会采取极端编程方法，提供给用户界面原型和现有系统进行试用来搜集需求，文档较少，相关沟通采取讨论会，要把用户纳入项目，这时候项目经理对需求了解和把握成为关键瓶颈。2.4 布署2.4.1 存在问题布署时常常碰到问题是软件本身问题，软件功效不完善、软件易用性、稳定性存在缺点，对于培训不够重视，现场环境复杂、用户配合度不高等等。开发人员在现场布署时会造成现场修改。这对系统稳定性和以后维护工作造成了一定隐患，现在不提倡这么做。布署人员、实施人员在和用户沟通时候商务意识不够，造成系统变更、范围扩大等。项目初始化工作是项目标难点，直接关系到系统使用，需要考虑用户原有系统，并考虑我们系统和原有系统衔接，花费工作量较大。部分布署活动无计划，布署成本增加，事前准备不够充足。部分项目较随意2.4.2 布署计划布署任务关键包含系统安装和培训，和用户关系沟通。项目布署前，向用户提供文档化布署计划会更正式（参见2.2.1.1），但需要项目标项目经理提供项目计划，便于布署工程师安排对应布署工作，避免常常出现突公布署要求，造成现场布署工作仓促进行，效果不好。在布署之前，估量可能碰到问题，和处理方法，会有利于布署2.4.3 现场步署布署前要对用户资料和数据优异行备份，确保用户资料安全。系统测试完成后，布署工程师在布署前，在内部需要自己对布署程序进行一次安装测试，并准备培训纲领、文档等相关资料。在现场布署完后，优异行测试，再交付给用户使用，层层把关以确保系统质量。布署之前和以后全部进行用户环境了解对布署工作开展全部很有好处。在项现在期帮助用户搭建和确定系统环境，有利于系统测试环境确实定。对于用户反馈缺点要进行分析。在现场布署时，因为用户环境等多种现场原因，可能会出现很多意想不到问题，这时候需要布署工程师妥善处理并统计。这要求布署工程师含有良好心理素质和经验。2.4.4 用户培训现在项目标培训工作开展时，全部没有系统化培训资料，提议对于常常反复使用用户培训资料进行固化，并进行维护，也是提升用户服务质量好方法用户系统管理员是以后用户方承接系统管理者，对于用户系统管理员培训要做到充足和细致，能够大大降低项目标维护费用。在用户培训时候能够向用户介绍系统设计思绪在培训时候提升用户爱好，改变用户原有工作方法，表现系统价值，也是很不错方法。依据对用户层次分析，不一样用户需要不一样，所以需要对不一样用户层进行不一样培训，均是针对用户需要进行。2.4.5 布署总结大部分被访谈者认为项目布署总结是很有必需，能立即进行经验积累和提升。不过现在基础没有进行总结工作，只有出差总结是不够。在布署回来后，对用户布署环境相关资料进行文档化备份，能够提升远程维护能力；同时，在现场能够帮助用户安装相关工具。2.4.6 系统测试影响大部分组员对系统测试作用认识比较到位，认为系统测试在没有经过情况下会对布署造成严重影响，直接造成满意度下降现在大部分项目存在测试不充足现象，因为进度压力，测试时间不足，这需要在签约时就进行项目估量，充足预留测试时间。处理方法可能是：1、预留测试时间；安排测试人员；2、时间紧情况下先给用户布署，并说明情况，内部加紧测试，快速提供新版本；3、正式给用户版本系统测试优先级较高，在资源分配上需要考虑。4、在进度紧时候，给用户提交版本根据需求优先级分次实现，确保经过系统测试，给用户分期布署稳定版本。2.4.7 配置管理被访谈者均认为良好配置管理是关键，版本控制意识在加强。不过现有部分项目中出现过数次布署版本不兼容、无法回溯，找不到已经有版本等情况，造成了严重影响。现在关键问题是企业级配置资源不足、项目组内配置人员能力有待提升等。对于项目组组员配置管理意识还是需要深入加强，并需要了解配置管理方法等。2.4.8 对现有布署步骤认知没有看过占多数，大部分组员根据自己经验在探索，看过并使用本步骤项目反应部分认为不错，有较强指导意义，另外部分人认为现有步骤比较繁琐。现在对于此步骤需要加强步骤优化和落实实施。2.5 验收验收时候，用户满意度是关键，反而对协议条款关注较少，只有在不满意时候，才会拿出协议条款；部分商务利益手段使用是必需。项现在期对用户承诺不能实现话，直接影响项目标验收。加强用户沟通，促进用户在系统布署后立即使用系统并反馈问题，能有利推进项目标后期验收工作。商务活动、科研结果汇报、发表论文、在行业内进行有影响宣传对于项目标最终验收有促进作用。用户没有正常验收原因：需求挖掘不到位，调研人员未将实际需求反馈给开发组，用户交互没有做好，布署时培训不到位等等。造成用户不满而不进行验收或推迟验收。较少情况是用户资金情况也会影响到验收进度。2.6 项目维护2.6.1 存在问题现在对于维护问题会越来越突出；主观原因是用户需求不停变更，项现在期工作不到位；系统问题；文档不可用；系统易用性不好，不稳定；事业部对系统升级精力不够；系统存在不可处理问题；客观原因是：用户常常换责任人，水平低；和用户信息化背景相关等等。从维护资源上来看，现在假如不是现有项目人员进行维护，维护工作极难开展，分企业渠道没有项目标维护能力，也没有激励方法，致使事业部要做好维护，就需要有大量人力物力投入，而且到用户现场维护成本极高，而对于有偿服务机制还不够完善，造成维护费用高起不下。项目售后服务工作困难较多。在第三方软件维护问题上，现在企业对于第三方产品管控能力较弱，还有很多工作要加强。在使用第三方软件时候要慎重，要结适用户需求进行评定。不然，在维护阶段这部分工作会成为难点。项目维护工作假如处理不好话，带来影响是：维护成本太大，无法支撑正常运行、无法收到项目标尾款，用户满意度大幅降低，品牌受损、被用户抛弃等严重后果。2.6.2 维护方法和布署一样，维护时碰到问题并非是这个阶段才有，而是在项目一开始时候就一直积累问题，所以降低维护成本最根本方法是改善软件生产过程，制造出满足用户需求、低缺点、高扩展性产品。在操作层面，各项目均积累了部分经验：项目进入维护期前，给用户正式发送项目完工通知单双方确定验收维护界限和相关维护工作是必需。便于维护期界定，和后期维护费用收取。在进入维护阶段时，和用户确定维护计划，确定维护周期、维护工作量，使维护成本可控。在项目进入维护时要和用户签署维护协议，渠道进行维护工作，明确维护利益。对用户系统管理员强化培训能够提升用户自我维护能力，从而降低维护成本。维护阶段需要明确分配维护资源，在项目维护方面，一定要考虑协作方法来处理，事业部人手不足，而分支机构和客服在售后服务方面有较大优势，良好利用能够降低成本，对分支机构及客服工程师加强方案项目标培训，利用分支机构地域优势、客服专业优势进行后期维护工作。维护工作能够采取部分技术人员现场蹲点指导方法，让用户立即把系统使用起来。在协议中明确指出项目标维护方法和费用等协议。尽可能采取远程维护方法周期性维护也是一个很好方法2.7 用户满意度2.7.1.1 用户满意关键是：良好能满足用户真实需求系统；系统稳定性和易用性很好；服务态度能够填补产品功效缺点，响应速度，和是否能够实现立即反馈；建立良好用户关系是必不可少正式计划能够提升满意度，立即和用户沟通项目标进展2.7.1.2 用户不满意关键原因：系统功效达不到用户要求；系统不稳定，常常出现大量bug；新增需求得不到控制，双方全部不满意；项目没有完整计划等等。在访谈过程中，因为基础上全部能够在用户要求时间内提交版本，对于项目延期不是很敏感。2.8 其它2.8.1 需要得到支持对于业务人员能力亟需加强，需要企业提供系统多方面培训：业务知识、沟通能力、计算机和网络知识等。开发人员对项目问题响应速度需要深入提升。分支机构支持：渠道要有较强业务能力，以担负前期需求确定和维护任务。QA和CM人员步骤支持，提醒和监督是必需事业部资源支持：在项目开发实施过程中，应该确保项目资源稳定。人员变动对项目会造成很大不良影响。2.8.2 交流平台和企业范围以外实施和商务经验交流；面对面方法交流会愈加好，往往不愿意用正式方法进行交流。大家愿意接收经验交流方法是：角色饰演，经验传授，内部学习、企业提供coffee time等等。2.8.3 其它改善点项目需要确定明确项目责任人，直接负责项目标需求核实和用户沟通，职责不明确会对项目标顺利进展造成重大影响项现在期，由项目经理牵头，QA辅助，明确项目标过程约定和沟通机制，有利于项目开发实施过程中沟通和问题处理。提议：在布署程序文件中总结出一个简单统计，每次和用户沟通时使用一两张，不要太烦琐。需求备忘录和实施单需要用户确实定提议：在用户需求确实定方面，一定要坚持让用户签字认可；在一些用户顾虑方面要小心谨慎处理，对于要和用户确定统计，要考虑使用时友好性，对于阶段成功确定单需要修改文档名称项目要有计划、改善用户关系、加强文档能力和技术方面能力现在做产品和做项目销售，项目款项大易完成任务，而产品回款较快。在企业政策上，对于这两项会出现问题应进行考虑。平衡分支机构人员对项目标贡献和不利影响。