技术人员怎样与客户沟通

我说说互联网和软件行业，我们按照通俗的人货场理论来拆分一下，把所有工作岗位拆分为：

1、销售、市场等以人为工作对象的岗位。 他们核心与人打交道，可能是甲方、乙方等客户，也可能是产品的用户，即普通消费者。比如，软件公司负责与客户公司招标团队建立连接的销售人员，与互联网广告平台接洽投放广告推广人员等。核心是与人打交道时，女性有着很大的优势，这是另外一个大话题，但不是这里的重心，不再细说。

2、运营等综合来看人、货、场为工作对象的岗位。 最典型的，比如，抖音、淘宝、京东、拼多多、快手、美团等平台运营，他们运营的可能是小视频、商品、外卖服务、餐馆等，主要工作内容就是通过对流量的安排来做消费者和服务内容的匹配。还有软件产品的运营，比如在云计算公司中，ECS虚拟机、飞书、钉钉等软件产品也会有运营，他们的核心工作是让客户公司的研发采购决策人、软件产品使用者对自己的软件产品有一个更好的心智，最终还是为软件产品的销售提供帮助。 以上销售、市场、运营等岗位的妹子很多，统计上的具体数据我这里没有，毛估的话一半以上吧。

3、产品经理、开发工程师、测试工程师、解决方案架构师、运维工程师、技术支持工程师等以货为工作对象的岗位。 这些岗位目标就是一个，做出消费者喜欢用，或者客户喜欢买的软件产品来，比如，抖音App，以及App内的视频推荐系统；支付宝App，以及里面的理财、保险、支付等系统；微信的红包、QQ的音乐等产品功能；金蝶的财务管理系统；淘宝的商品推荐、购物车、交易系统等。 这些岗位中，产品经理中妹子也很多，不过没有销售、运营团队中那么多，但即使没有一半也比较接近了。其它几个岗位中妹子的一般占比排序基本跟岗位日常工作内容中的技术含量成反比，我列一下就是：测试工程师、技术支持工程师/运维工程师/解决方案架构师、开发工程师。

以上，我从大方向上列了一下互联网和软件行业工作岗位中妹子的占比情况。专注在技术领域再提一下。

1、测试工程师。测试工程师黑盒占了绝大多数，技术含量比较低，又经常跟那些难搞的开发工程师打交道，提一些他们最不喜欢的Bug，所以很多测试团队会尽量招妹子，我合作过的测试团队基本都是妹子占比超过一半以上。

2、技术支持工程师。这个岗位一般是在商品、服务完成销售之后，做一些答疑、解惑的工作，搞不定的就甩给身后的产品经理和开发工程师团队。这个岗位与人打交道比较多，又是一些常规问题处理，所以妹子占比也很多。我认识一个大厂负责核心中间件技术支持工作的工程师，整个集团所有后端系统都少不了那个中间件，因此所有后端开发都知道这个人，她就是个妹子。

3、运维工程师。相比其它岗位来讲，运维工程师应该算是最专注在“货”身上的岗位了。不管是开发工程师、测试工程师，在工作的时候都不可避免地考虑一下用户体验，需求是否合理，而运维工程师只是问题驱动，哪里机器挂了，去解决；哪里网络不稳定，去解决；哪个系统崩了，去解决。正因为这个岗位一心专注在“货”上面，所以妹子最少。

4、解决方案架构师。这个岗位是最特殊的，严格来说他属于带技术、销售双属性的岗位，我以前写过一篇详细分析云计算公司各岗位的文章中提到过，大家可以看一看： 因为相当一部分是码农转型过来，那这一部分人肯定妹子比例比较少了，另外一部分来源于非技术岗的，比如产品经理等，妹子比例就会高一些。但无论如何，这个岗位不太适合刚入行的人，我在文章中也有提到过。

5、开发工程师。码农的工作知名度最高，但实际上还是有很多细节的，我再扒一扒。比如，所有开发团队中，前端、数据两个团队是妹子比例最高的，当然，这里的高仅限于开发团队内部对比。由于数据团队规模太小，且一般中小公司甚至都没有专门配置，本身也存在很大的职业发展瓶颈，所以我们专注在前端团队中就可以了。 其它的像服务器Java开发、App开发、算法开发、终端系统开发等，妹子比例很低，而且越是大厂、工作强度越大、业务越卷，那妹子比例越低。

要知道，同时软件开发，toC的消费互联网和toB的软件研发完全不是同一个概念。比如，一个互联网公司负责营销活动开发的团队，天天被各种活动逼着往前跑，每个项目都有DeadLine，妹子基本都撑不下来。但对于toB软件开发，比如做金蝶财务系统的，最重要的是对客户、市场的深度洞察，无需研发拿命填去试错，产品的迭代节奏很稳，当然不需要996了。

以上从妹子占比的视角讲了一下互联网和软件两个领域的岗位特点，如果你是妹子，其它条件相差不大的时候，建议还是选择妹子占比多的岗位，大家都这么选自然有她们的理由，毕竟群众的眼光是雪亮的。 但如果你是特别有追求的妹子，我建议你追随自己的内心，IT行业最不缺的就是创造奇迹，最看重的是个人实力，只要肯努力，还不存在没饭吃的情况。

项目开始前，要对开发人员进行调研，了解开发人员的 *** 作及对尺寸的要求，每个开发人员大都有自己的 *** 作习惯，要了解开发人员所用的语言的尺寸要求，制定设计尺寸标准，这样项目开始才不会出现开发人员写出的页面与效果图出现偏差，从而导致项目延误和开发人员的耗时耗力，合作起来才会更加舒服流畅。 来自职Q用户：崔女士

质量由产品经理把控，项目组评审通过后，交给前端开发，进行后续开发工作。 来自职Q用户：夏先生

沟通是门技术，是门扯淡的技术！

1、客户不配合 啥都白搭

2、客户顽固，啥都白搭

3、可以通过相关技巧慢慢的打开客户心扉，使之配合。但这需要时间，不是说简单的寒暄几句就ok，而且也不是每个人都是交流大师，而培训能做的仅仅是规范对待客户的态度表现。

4、在解决技术性问题的基础上，一般来讲，时间都是紧迫的，如果双方上级没有直接下达配合指令，仅靠下面的人在那YY，真的是扯淡。如果是没有上级的终端客户，难度+1

5、说句实在话，为了解决一个简单的问题而增加了大量的沟通成本，这TM还有效率吗？

6、信任问题。这个东西应该是在售前建立的！而售前在做什么？简单来说“一股脑的卖产品”，想尽办法让客户买就行了。那么当产品出现问题，技术支持，尤其是售后、一线工程师，将会直接面临第一个问题：客户凭什么相信你说的？！如果售后队伍不强大，真的是想回去打打拳击。

7、针对第6项，有个前提：客户非专业人士。技术人员的存在不仅仅是去做那些技术性的事情，更多的是因为他们“懂得”技术，这才是最重要的，所以，对于非专业人士，更需要用更加通俗易懂的语言去解释当前的情况。然后这个解释是要有信任前提的，客户不是研究这个的，所以对这个的基础知识大多是空白的。举个例子：卖给诗人李白的手机WIFI满格但是无法上网，你怎么让李白相信“这不一定是手机的问题”？。。我TM自己肯定知道不一定是手机的问题罗！ 信任从哪里来？

8、道理其实大家都懂，望闻问切 实地摸索。只要是个合格的技术人员，思维方式、逻辑能力肯定还是有的，所以在处理问题的时候也会有一定的逻辑顺序。所以在这又有了另一个问题：摆设型技术人员。比如一线技术支持，至少我认为：大多技术不合格。而且，一线技术支持恰巧又是和客户直接面对面、需要沟通的。而二线技术则可能回归办公室，技术技能却又相对较高，这不是扯淡吗？

当然，也会有实力干将型一线技术，技术技能掌控也很高超，本身就自带光环。但这取决于个人职业规划、个人生活变迁、以及公司薪资福利。

9、短时间内寻找最便捷的方案，因为这对于客户来讲最方便，也可能更省时间，但前提是要知道“自己要干嘛”，然后执行方案即可。看似简单，这需要良好的记忆力、更加合适的像向客户提问以便获取有用信息的能力。如果是在处理故障，最重要的是要让故障重现。从而最终，最快的拿出最便捷的应对解决方案并执行。 这样做的好处是：定位快、有节奏、重要信息流失慢、相对提高信任度。当然也会异常情况：最便捷的方案需要执行的步骤多，但是只有这个最便捷，那么就需要通俗易懂的给客户讲你在干什么，大概多久。

10、客户和技术沟通，在客户边一般就这几种情况：这是什么？这能干什么？这个怎么了？这个怎么可以怎么？我能想要怎么。即客户和技术沟通实质上也是在解决自己先关需求。所以作为技术，也要明确客户的最终需求是什么，知道需求了，那就好办多了，但是很多时候，客户自己都是摸不着头脑的，客户脑子里面最多就是一个终极场景，大可让客户描述下最终的场景即可，而不是“客户问一句，你答一句”或者直接问“你要多大的盘？你要多长的？”这种傻屌做法。

通过客户描述的场景，作为技术 是可以大概知道客户的整体需求的，然后在精确到场景中的各个环节（子需求/或者隐藏需求）

第10点很明确：别老把客户当做懂行的，真正懂行的都懒得问你或者找你沟通，都自己去研究捣鼓了，最多找你技术要份产品说明材料。

11、提升自己，技术OK的情况下 ，在和客户沟通的时候可以秒回-->通俗易懂的秒回-->和交流技巧相融合后的通俗易懂的秒回！

12、和客户的交流技巧？百度一大把好吗？把和客户换成人，“与人的交流技巧”

作为第三方服务的提供商，我们的服务就是作为客户的外脑为客户提供帮助，从专业的角度告诉客户现场的实际情况，识别出现场的风险，风险依据，并提供出专业的意见，如果能更进一步为客户提供出简单有效、经济方便的方案就是我们捆绑著客户的最大利器。

但是我们做了那么多，客户领情么？

我们做了那么多，客户知道么？

我们做了那么多，为什么客户仍然会认为我们的服务不到位？

我们做了那么多，我们最对了么？

我们做了那么多，我们做到了极致了么？

相信，当我们很多项目结束后在与客户沟通的时候，听到客户的反馈的时候，我们或多或少的都会涉及到以上的四个问题。尤其是，当有客户提出不满意的时候，我们是不是很冤枉，很委屈？

那如何才能改变这种情况呢？就是让客户知道我们做了什么，让客户感受到他们的需求是被重视了的，大家是不是觉得很难？不要怕，不要慌，下面就为大家准备了制胜利器，帮助大家实现上述目标。

沟通并没有大家想想的那么难，试想我们沟通的对象都是人，人的特点是什么：见面三分情，抬手不打笑脸人。还有就是，感情是处出来的。

一说起花时间，可能很多人都会有个困惑：我聊什么？总不能大眼瞪小眼吧。

其实每个项目的执行都离不开三个部分：

1 kick-off 启动阶段

2 执行阶段

3 收尾阶段

所以，在每个阶段都有每个阶段可以沟通的内容与目标。

在项目的启动阶段，我们需要注意沟通的是确认客户的需求，和期望，培养感情，建立直接对接人/负责人对项目/服务执行团队的信任。

执行团队到项目上都拿到了对应的方案和要求，以及执行方法，大部分的情况工程师都没有参与服务范围和方案的谈判，这些内容是是存在与纸面上的，所以在项目启动阶段，需要跟客户进行再次确认和澄清。

沟通的内容如下：

先自我介绍，把我们到现场的人员进行初步介绍，每个人的职责介绍清楚，让客户也介绍一下他们的参与人员。方面我们在执行过程中，知道什么样的问题找什么样的人，发现的风险对哪些人有影响。

1 我们本此来执行项目是针对您们对的需求，主要的内容如下：

blablabla 

对于这些内容，您们有没有疑问？

2 对于本次服务你们的期望是什么？希望实现的目标是 么？还有没有什么特殊的要求

3 我们执行的方式是：blablabla，希望你们的配合是： blablabla，你们有什么问题么

4 我们的执行计划是：时间段安排的事情。对于这个计划，你们有什么问题么？需要我们执行时候注意什么事项么？

5 现场配合的人员的对接人是么？

6 我们会在每天的结束，会有个简短的反馈，主要是对当天发生的问题做个总结以及配合中需要的支持做一下反馈。非常大家对我们的信任，也希望在执行中，大家有什么要求或是疑问，可以随时与我们的团队做沟通，我们也会尽我们最大的努力给大家提供最好的服务。

以上是我简列出的在项目启动阶段会涉及的问题，如果有其他更多需要确认的信息，可以自行添加。在这个沟通过程中，主要实现的目的，是对客户现场团队的熟悉，并让对方的执行人员对我们接下来要做的事情有个整体的认识，并且产生初步的信任感，在客户面前树立权威专业的印象。

项目执行阶段是体现我们专业度的阶段，在这个阶段我们要通过我们专业知识识别现场风险，在这个过程中，如果有客户的随同人员，大家可以借此机会了解他们日常运营的习惯和管理方法，管理问题，和管理困难。并通过执行过程中发现的问题，给客户培训出对我们的信赖感。

所使用的问题可以参考如下：

1 你们平时是如何进行的 *** 作的

2 管理制度是如何设置的？

3 你们认为在日常管理和 *** 作中遇到的问题都是哪些？哪些会影响比较大？

4 你们希望在哪些地方急需改善？

等等，在这个过程中，可以分享自己的工作经验，以及在过去的案例中我们提供的方案是什么，帮他们加深理解我们即将要给出的解决方案，让他们对我们的方案有预期，并且理解我们未来提交的方案。并且，在沟通过程中，看看他们对我们方案的反馈，是否真的能够实现，实现的困难在哪里，我们是否能够调整，给出更优的方案或是替代方法？

这个过程是建立客户对我们满意度的最重要的环节，也是让客户理解我们的工作方法和解决方案最好的时机。因为所有给出的方案都是针对当时当地的场景的，客户理解起来会相对容易。

收尾阶段又有三种层次，1 当天工作的收尾；2阶段工作的收尾；3整个任务的收尾

在每个收尾阶段，都可以跟客户做个小的回顾和总结。

1 对于当天的收尾工作 ，任务结束后，跟客户的负责人或主要人员花个5-10分钟做个简短的沟通，将当天的发现，与初步可能建议的方案，做个沟通，让客户可以及时思考反馈。有利于我们后续工作的重点的确认与调整。

2 对于阶段性的收尾工作， 任务结束后可以花20-30分钟，做个总结，总结可以按照以下的框架进行：

- 我们依据的标准

- 我们发现的主要问题

- 对于每个问题我们预计会提供的建议和方案

听听客户的反馈，便于我们写报告的时候阐述方式和逻辑的选择。

3 对于整个项目的收尾工作，逻辑与前面的逻辑是一样的，内容更具化，更详细，可以花30分钟到1个小时与客户进行沟通，比较大的项目，一般会花两个小时，最多不建议超过两个小时。这个汇报更会符合我们整个报告的逻辑。

鉴于以上三个收尾阶段的总结与汇报沟通，客户已经非常熟悉我们的报告的逻辑结构，我们也对客户对于预期报告方案的反馈做到了心中有数，我们服务的有效性就会得到充分体现，从客户的角度去写报告，相信客户的满意度会大大提升。

以上为我对于项目执行中的沟通给大家的简单建议，祝大家每个项目都可以得到客户的充分认可。

1,技术人员特点

        我是程序员出身，做了这么多年程序，经过长时间的积累，专业技术方面的能力有了很大的提高。由于工作特性和工作环境的关系，出现了严重偏技术，不懂人情世故不懂如何去沟通。这在基础岗位可能不会对自己产生太大的麻烦，但是当你带团队或者成为技术领导，存在跨部门之间的沟通或者和客户沟通，这时你的沟通能力就会拉低你整体能力的评分。

      技术人员必备的能力第一是专业的技术能力，毕竟自己是靠它来吃饭的。第二是专业的态度，技术人员往往特别傲慢，要认识到人外有人，天外有天。计算机技术更新特别快，今天掌握的专业技术，可能明天就会落后，所以要有不断学习和向别人学习的态度。第三就是我们现在主要讲的沟通能力。

2,沟通的几点注意事项

1,首先是联络感情，建立信任。

2,找准合适的时机进行沟通。

3,用对方喜欢的方式进行沟通，前提你要摸清对方的性格特点

4,用对方能听懂的语言。技术和技术沟通可以谈一些技术交流。但是技术和非技术人员沟通，就要用通俗易懂的事例进行沟通。

5,善于运用换位思考，充分肯定别人的能力和角色

6,一定要有所反馈，别人的问题要及时回答，哪怕不知道怎么回答也要告诉对方目前给不了答案。

2,如何改善沟通？

1,主动链接他人。沟通的第一步是开口，只要在适合沟通的环境，可以和任何人开口说话。从打招呼你好开始。

2,刻意练习，抓住机会去练习，比如开会的时候主动发言，自己争取当会议主持人。平时多和同事沟通聊天，特别是多和跨部门的人沟通。也要多和领导沟通，领导可能最懂你。沟通完之后，如果能让对方提供下你的不足就最好了。

3,自信的态度，要有自己的想法，不要随波逐流。自信提高了沟通能力会提高的很快。

4,沟通前做好充分的准备。充分了解自己的沟通对象，想好自己准备从哪几点进行沟通。沟通过程中可能会遇到的问题，对这些问题该怎么回答。

对于软件测试工程师来说，工作中很重要的一部分就是沟通，固定沟通包括跟主管、开发人员，不固定沟通包括与产品经理、项目经理、研发方负责人等。在不同类型的研发队伍中，沟通人员沟通的对象可能不同，但沟通却是永恒的。那么，如何与不同的角色沟通？如何在沟通中既展现自己负责任的态度，又不处于被动之中？如何沟通才能不只做个传话筒呢？工程师每天都需要沟通，究竟有什么可参考、可学习的沟通方法呢？

首先，沟通不是凭直觉的，沟通是有方法的，使用正确的方法，每个人都可以得到提升。

对于每一次的沟通来说，我们首先应该使用5W2H模型确定框架，明确如下问题：

WHY：为什么沟通？沟通的目的是什么？

WHAT：需要明确哪些内容？什么是重点？

WHO：沟通的对象是什么角色？

WHEN：什么时间？有没有合适或者不合适的时间？

WHERE：在哪里沟通？有没有合适或不合适的沟通地点？

HOW：应该采用什么样的沟通方式呢？强硬、委婉、还是其它方式？

HOW MUCH？沟通到什么程度合适？

使用这个模型可以在无头绪的前提下厘清思路，明确问题所在。

接下来，明确了问题以后，我们应该怎样沟通呢？

沟通是一个过程，我们对该过程使用结构对其进行拆解，主要活动包括聆听、提问、反馈三个部分，在过程中三个活动循环进行或者分阶段进行，最终完成沟通过程。但是这三项活动应该怎么具体如何执行才能达到良好的沟通效果呢？

高效沟通=积极聆听+有效提问+及时反馈

问题又来了，什么是积极聆听？它如何区别于普通聆听呢？聆听主要有三个level，分别是无意识聆听、结构化聆听、全息聆听。无意识聆听只依靠自己的兴趣/感觉聆听外界的信息，不对信息进行结构化处理，输出很凌乱；结构化聆听有所不同，信息接收者不仅在听，还会将聆听的内容进行结构化整理，最终输出结构化的内容；全息聆听更上一个层级，接收者不仅在结构化聆听对象的内容，还在感受对象的情绪等主观信息。由于人类是理性+感性的动物，如果聆听者不仅接收到理性的内容，还可以接收到感性的部分，可以全方位感受和理解沟通对象。积极聆听是教练必备的一项必不可少的技能，积极是一种态度，在态度之上的方法更是必不可少，测试工程师需要使用正确的方法训练自己的该项技能。

其次是提问，提问可以对获取的信息进行再次确认，也可以在一定程度上启发沟通对象。提问有两种方式，可以提开放式问题，也可以提封闭式问题。从大的原则上说，开放式的问题可以给沟通双方更广阔的思考空间，可以在开放问题之后明确方向再去针对一些具体的内容使用封闭式问题。这也启发我们提问的方法，以开放式问题为主，辅以封闭式问题。在对团队成员进行指导的时候，也应一开放式问题为主，启发成员思考。另外一个问题来了，提开放式问题时，如何来提，使用什么样的思维方式，因为外在的表达一定是建立在内在底层思维的基础上？答案就是使用批判性思维，进行辨证思考。现在国内关于底层思维的介绍非常多，结构性思维、系统思维、分析性思维、发散思维等等，这一切都建立在逻辑思维的基础上。批判性思维也是一样，使用批判性的方式全方位思考。我们之后找个时间专门说批判性思维。

除此之外，在AAR教练课程中也讲了一个提问方法，叫“四维提问法”中，针对一个问题，分别从上推、下切、寻因、问果四个维度提问，启发沟通。感兴趣的同学可以了解一下。

对于沟通形成的闭环，反馈也是一项重要的内容，采用什么样的方法反馈也是有技巧的。及时是第一要素，因为有效的时机有时稍纵即逝，过了那个时点之后无法达到原有的意图。除此之外，结构化自己的语言，表达的时候结论先行，也是一项重要的反馈技巧。

关于提问和反馈，我们之后开辟一篇文章再单独讨论下。

一个技术管理者需要协调好团队才能让团队有更好的发展，更高效的完成项目。做好团队的沟通协调首先需要对项目的总体目标与进度有严格的把控，然后对团队内部人员的特点以及工作状态需要有清楚的认识，另外就是需要不断的为团队人员争取利益。

对技术项目能很好的把控

一个好的技术管理者最基本的素质就是需要掌控好技术项目的进度以及整体目标。甚至更详细一点需要了解每一个技术点需要达成的目标，如果这些方面管理者不能很好的掌握，那么在和团队人员沟通的时候就会导致团队人员质疑你的专业能力。

熟悉团队人员的特点

一个团队中，每个人员都是有自己的特点。而作为技术管理者就需要充分的了解自己团队的人员特点，比如有的人比较委婉，不善于表达。那么管理者就需要主动的和这样的人进行沟通，甚至可以尝试锻炼一下他的表达能力。而有一些人比较张扬，那么在沟通的时候就需要采用另一种方式了。

尽力为团队人员争取利益

技术管理者想和团队人员有好的沟通就需要让团队人员知道自己是尽可能的为内部人员争取利益的。比如每年的年终奖，每年的涨薪，职位的晋升，这些都需要管理人员尽力为自己的队员去争取。我就遇到过管理者从不给自己管理的人争取利益，他认为这样会让老板觉得自己在没事找事。甚至公司在做薪水满意度调查的时候，员工想自己写高一点都会被劝退回去。最后这样的管理者必然会导致众叛亲离，和员工的沟通也不会通畅。

针对技术管理者如何做好团队沟通你还有什么好的方法呢？欢迎大家在底下留言评论！

以上就是关于程序员需要什么样的沟通表达能力全部的内容，包括:程序员需要什么样的沟通表达能力、#ui设计师#一般UI工作中怎样与后台技术人员沟通合作、技术人员怎样与客户沟通等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！