项目客户沟通经验调研报告样本.doc
《项目客户沟通经验调研报告样本.doc》由会员分享,可在线阅读,更多相关《项目客户沟通经验调研报告样本.doc(12页珍藏版)》请在咨信网上搜索。
1、项目用户沟通步骤经验调研评定汇报1. 概述:企业自从转型以来,已经经历了大约十二个月时间,在这十二个月中,我们共实施了几十个项目/产品,从中积累了大量项目经验,不过,这些经验全部是存在于和用户直接沟通项目经理、咨询工程师和实施人员头脑中,而伴随项目标增多,这些人员也很忙,极少有机会能进行系统总结。而在这企业过程体系中,却一直是一个弱项。所以我们决定做一次这方面调查,目标是将大家经验和教训全部积累起来,在组织内部共享。我们调查时关键采取访谈方法,在访谈时,为了让大家畅所欲言,事先约定对访谈内容保密,而且确定在最终评定汇报中,不会包含到任何一个项目和人员。在访谈中我们发觉,每个人员全部积累了相当丰
2、富经验,不过几乎每个人经验全部是不一样;而且发觉有一部分一样问题,会在不一样项目中出现,所以我们也强列感觉到共同总结共同提升必需性。从结果来看,基础上得到了我们需要信息,成为我们下一步改善基础。1.1 调查目标经过对于用户直接沟通步骤调查,进行经验总结、积累和共享。依据最好实践改善现有过程。1.2 调查范围阶段:关注于项目标售前和售后,关键包含:商务谈判及协议签署、需求获取、项目沟通、布署、验收、维护等步骤。人员:企业内项目经理、咨询工程师、开发经理、布署实施人员1.3 调查方法:关键采取人员访谈方法,事先准备被调查问卷及调查计划。对每一位被访谈者进行独立访谈。提取经验和教训,总结出评定汇报。
3、1.4 调查统计:现在有和用户沟通经验人员总部为:16人,实际调查人数:11人,覆盖率:69%。在实际调查人员中,项目经理/咨询工程师6人,占55%,开发经理3人,占27%,实施工程师2人,占18%。覆盖事业部:4个2. 经验总结:2.1 商务谈判及协议签署2.1.1 存在问题为了签单,随便给用户进行承诺,开空头支票,结果会影响到用户满意度降低,这种情况在商务人员中比较多。在签署协议时候,没有进行充足估量,往往对企业能力估量过强。在签署协议时候,要确定适宜项目目标,并估量企业实际能力。依据用户方进度要求来压缩项目标协议工期,而不考虑项目标实际能力,方案不成熟时候这么做风险很大,实际工期往往相差
4、很大。项目范围不明确,造成后期需求范围无限扩大,得不到控制,在被调查项目中,最求变更大达成了60%以上,变更最小也达成了1020%,项目标需求变更成了家常便饭。高级经理或渠道直接签单,和事业部沟通不足。2.1.2 签约技巧及经验:现在大家对于签约认识已经得到了显著提升,在访谈过程中,已经没有些人会认为协议签署是一个无关紧要过程了,绝大部分人员已经认识到签约关键性,对于条款严厉性也有了充足认识。在现有已签约项目中,后期协议签署就比前期好了很多,这是一个不停完善过程。因为签单时需要考虑竞争、和用户对需求不明确等原因,所以在协议签署时候风险是肯定会存在,不过应该在协议签署时候就考虑对应风险处理策略,
5、并对风险进行管理和控制,在风险较大情况下,考虑临时不签或发明条件后再签。项目范围确定是协议中一个很关键部分,签约早期,项目标需求越明确则项目风险就越小,假如需要在签单后进行调研,能够在需求调研完成后将经双方确定文档作为协议附件,而且需要将变更控制措施放到协议条款中,和用户约定把每次变更作为协议附件保留。在协议中确定验收条款也是很必需。协议条款方面,考虑对我方很不利情况,尽可能和用户沟通避免。而且在签署协议及协议附件时候,对于不宜直接表示见解,能够换一个适宜方法和用户沟通。在和用户进行商务谈判时候,需要考虑已经有系统成熟度和项目标赢利值,引导用户把需求范围靠近我们能实现程度,寻求双方折中点,确保
6、项目利润。签约时事业部项目经理、咨询工程师参与是必需,越早介入风险越低,成功率越高。是否签约和项目范围决定权最好在事业部。总部人员参与项现在期商务谈判优势是:对系统较了解;和开发员沟通较多,能反馈开发员意见;了解系统不能实现功效,从而引导用户,从用户利益上说服用户放弃技术上实现困难要求等等。2.2 项目沟通2.2.1 用户沟通2.2.1.1 准备在访谈时,有部分项目在和用户进行面对面沟通之前,往往是临时性、突发性,事前没有准备,这种情况所造成结果是千里迢迢到用户那里时,才发觉用户有其它事情,忙别去了,或是找到了用户,而用户因为事前没有准备而得不到我们想要结果。往往白跑一趟全部是有可能。用户不会
7、在意,因为反正差旅费和住宿费全部是企业掏,还需要加上伙食和出差补助。口头沟通也是常见措施,这种方法直接而有效,缺点是随意性变动性较大。用户沟通计划是必需,各个阶段沟通如有计划会加强用户认知和配合程度,这包含需求调研计划、布署计划(培训计划)和验收计划。计划应是正式,并和用户沟通确定,使用户方做好对应人员、时间、设备、资料安排;提升我方工作效率,降低成本。在准备时,仅有计划是不够,还需要准备好相关材料,这些材料依据任务不一样而不一样,材料准备能够是沟通计划一部分。另外确定沟通措施、熟悉用户使用方法和工具、系统试运行状态、准备问题和应对方法、培训演练等等,全部是准备内容之一。2.2.1.2 用户关
8、系和用户建立信任关系是很关键,这方面在项现在期能够采取让用户来参观企业、推广企业品牌著名度等方法来实现,后期则需要建立在产品和服务品质上了。在项目实施过程中,和用户建立良好伙伴关系,这是一个双赢局面,也是做用户关系较高境界,只有用户成功才是我们成功。相关用户沟通层面上,前期商务谈判时确定利益约定;对于决议层沟通一定是充足而必需,这关系到整个项目能否签署、准期完成、验收和收款等一系列关键步骤,不过同时一定不要忽略和底层也建立良好关系,当和用户要求极难统一时候,必需时需要采取非正常手段(如,请客)。在部分项目实施过程中,碰到了因为用户内部矛盾造成项目受阻情况发生,所以我们在处理用户关系时候,需要尽
9、可能避免卷入用户内部矛盾之中,这里面处理方法可能是在签约时就确定项目责任人,统一项目出口和入口,引导用户责任人了解系统,培养用户责任人了解和支持系统,进行必需风险管理和控制等。2.2.1.3 沟通人员在访谈中发觉,现在项目中有沟通人员不确定情况存在,用户沟经过程当中,参与人员较多,轻易造成项目信息沟通瓶颈和信息壁垒,这里需要有一个沟通计划。需要对目标用户进行细分,针对不一样用户采取对应方法,对成熟度低用户,进行软件开发过程培训有利于进行用户沟通和项目实施。2.2.2 和分支机构协作大部分项目认为分支机构支持力度应该加大,而且认为需要加强和分企业协作,尤其是后期协作。分企业应该更多地参与到项目实
10、施、培训和维护工作,建立良好用户伙伴关系等活动中去。分企业对于系统了解程度对系统成功开发有很大影响,应该加大对于分企业人员培训。分企业对于项目标风险规避太少,和事业部利益分享受冲突,这么在早期就引入了较大项目风险,取决于企业营销政策,企业需要在政策上进行利益分享引导,明确各方责权利。提议商务和项目相结合,建立利益共同体。2.2.3 内部协作有一个良好计划是内部协作前提,和内部项目组组员进行充足沟通是很必需。做项目计划并达成共识很关键,现在组内共识达成较为轻易,项目经理跨部门协调能力较弱。现在因为部分项目没有计划,造成实施工程师对于用户反馈问题处理和时间安排不协调,系统测试不充足影响用户满意度;
11、而开发组也需要实施人员正确提前提出用户请求,安排对应开发和测试工作。这里相关责任机制也需要明确。在内部碰到问题,能够内部进行处理,对于用户而言则是一个整体,不应将内部协作问题暴露在用户面前。开发团体内充足沟通交流很关键,团体中直接交流和沟通是最有效,需要常常立即对工作结果进行讨论。开发过程中人员稳定、组员能力和团体合作、平等交流气氛是项目成功关键原因。2.3 需求获取2.3.1 调研时间提议:前期调研需要充足,时间不应太短,时间太仓促会影响到需求获取质量和粒度,极难挖掘到用户真正需求。因为充足了解用户需求后,后期变更会对应降低,从而降低了因为返工而造成项目标拖延,在开发工期方面往往不会造成太大
12、影响。2.3.2 界面原型:界面原型是项目需求获取很好方法,业务模型分析能力有利于系统需求把握和实现。成熟度高用户需求范围较轻易早期就确定;对于成熟度低用户,需求范围前期确定较困难,有界面原型会愈加好,需要在后期加强沟通,对用户进行说服。没有界面原型对于需求获取是一个风险。2.3.3 获取用户真正需求:在需求获取过程中,进行具体用户分析,采取不一样策略。用户期望、业务实现、易用性是需要关键考虑原因。在调研时候需要找到关键用户人员,要明确需求层次,决议层需求是最关键,不过也不能忽略底层需求。在用户需求挖掘时候,要注意用户隐藏需求挖掘开发过程中非功效性需求往往被忽略,不过这类需求有决定性作用,要求
13、在需求获取过程中注意这类需求搜集和确定;不一样项目这类需求会不一样,和事业部具体方案特征相关在调研时候,如子系统较多,需要考虑整体性和相关接口需求。在需求分析时,用户方参与会很好,另外在需求调研时,事业部直接介入能引导用户取出关键需求,成功率更高。用户需求在搜集回来以后,一定需要和开发组达成共识,现在事业部制以后,该问题已基础处理,大部分情况全部是事业部内咨询工程师和开发工程师结合共同进行需求获取,取得了很好效果。2.3.4 需求范围控制从商务角度出发,我们也需要尽可能去控制需求范围;假如在早期这么做有难度,则必需对于主流业务进行确定;挖掘用户真正需求,给用户想象空间,并考虑用户使用系统时候感
14、受,同时考虑现有系统实现平衡,控制需求,和商务活动相联络,这里面有部分技巧是:谈时候能够什么全部谈,但统计时候要进行需求过滤。将我们做不到或不轻易实现对用户又不太关键需求过滤掉。而且对于不能做需求,不能直接拒绝用户,要采取部分技巧来处理。如:和用户沟通,给用户一个印象,软件制作是费时,引导用户在功效和工期上做平衡,取消要求需求。前期调研期间需要和用户形成一个对于系统认识方面共识。在项现在期需求调研时候,对用户进行计算机和软件工程方面知识培训,有利于和用户沟通,让用户站在我方角度考虑问题尽可能引导用户需求,降低用户需求和现有系统间差异。站在对方角度说服用户,节省开发成本。高层对于项目需求范围不要
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 客户 沟通 经验 调研 报告 样本
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【人****来】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【人****来】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。