跟程序员的沟通方式如何与程序员沟通，如何成为一个程序员 _睿知

程序员工作中的沟通小技巧？
程序员是互联网公司的资产，也是产品经理等冲突的主要对象。如何提高与程序员的有效沟通，请看下文：安心3354程序员拥有丰富的内心世界。经过各种需求修改和bug修复，他们与人交流的能力明显弱于与计算机交流的能力。所以，一定要安心和程序员交流。正确的态度——不要以一种尴尬和蔑视一切的态度来开展工作。再好的人，也要尊重每一个成员的工作，不能冷嘲热讽(看，你解决不了等等。)只是因为一个程序员遇到了技术难题。注意：态度是所有员工都应该具备的职业素质，不仅仅是程序员。态度决定很多事情，尤其是遇到类似问题的时候，态度更重要。因此，我们必须采取参与式的方法与程序员一起工作。现在很多公司都是这样评价一个员工的(如下图) 。希望对你有帮助。给程序员一定的时间和空间去解决问题。任何公司都希望自己新招聘的员工能够尽快胜任新的工作，但往往事与愿违。至少经过一周的磨合，工作才能顺利进行。注意沟通的效率。少一份抱怨，多一份理解。少一个批评，多一个建议。每个程序员都会是你的好助手。希望以上建议可以帮助提高你和程序员之间的沟通效率。

文章插图
程序有bug，怎么跟程序员沟通？
如果你是正式的，你应该提到测试案例，把你的整个测试过程以书面形式发给他，说明问题的严重性。当然，你要多沟通。不要一开始就说：怎么了？“又写bug了”？(手动滑稽) 。给我一个问题的口头解释。解释事情是怎么发生的，或者礼貌的问他：我做错了什么？我应该在这里做什么？一些事情。当然，如果你平时比较强势，哪里有问题直接说也是可以的。我是程，发现问题就恨不得别人告诉我，让我及时纠正，不然以后生产出问题就麻烦了。
项目负责人如何和程序员沟通？
做程序员，虽然口才好不是必要条件，但是不善于表达自己的想法，不善于和上级同事沟通，吃亏的是自己；最近做一个项目，和项目负责人发生了一些不愉快的事情。这种情况虽然和其他杂七杂八的事情有关系，但最重要的原因还是工作中缺乏沟通。比如上周他给我们C#组分配工作，每个人负责一个小模块。数据库和需求文档已经提供了，但是数据库的表字段可能会根据实现和开发的情况稍有改动，他也给我们举了一个例子，可以借鉴。虽然统一讲需求的时候听起来很清晰，但是做的时候会发现很多关节的细节没有考虑进去，而这些细节往往会影响开发速度。即使符合文件要求，也不符合负责人或客户的实际需要。因为文字类型的要求比较抽象，尤其是做用户界面，虽然有例子，但是只能借鉴，不能照搬照抄。很多时候，这样做出来的程序只是满足了程序员自己的需求；做一个可能不需要的功能花了很多时间。比如我做了一个日历控件，显示当时的排班信息，当时已经接近发货日期了。当我把它交给负责人的时候，我发现这个日历控件并不是必须的。所选时间范围在弹出窗口中，且数据未保存.这时候我发现自己做了很多无用功，不得不加班赶进度。虽然这只是一个小例子，但在过去的几个月里，类似的例子已经发生了好几次。为什么？因为表达能力差，沟通能力差。你可以使用日清管理工具来交流和写下你的想法。然后@给项目负责人。不要直接面对，效果很好。

文章插图
刚当上项目经理，如何与组内的程序员进行有效沟通？
沟通是一门学问，如何有效沟通是必修课。与人交往要注意模仿、倾听、真诚、注意肢体语言、踏实、保持情绪。由于你刚刚成为项目经理，你有很多事情要和小组成员一起工作，所以有效的沟通是必要的。我简单提供以下帮助，希望对你有用。第一，询问式谈话是指领导可以直接问一些下属，而其他人可以礼貌地问。关键是领导者必须掌握“问”的技巧。要求你的下属有交流的欲望，而不是单向的接受知识，消化和利用知识。第二，用咨询的语气说话。这种方法要求领导要心平气和，平等待人，关心和信任下属，不要把自己看得特别，“做个好老师”，也不要连珠炮似的提问，更不要中途打断下属。应该允许下属解释和谈论不同的观点，肯定什么是对的，指出什么是错的，在友好的气氛中协商解决问题。3.心胸要开阔，不要自大。连孔子这样的圣人都说：“三人行必有我师。”更何况我们都是普通人。就某个传播话题而言，不同的人从不同的角度肯定有值得肯定的地方。他们要认真听取别人的观点，创造良好的交流环境，不要千里迢迢依赖别人，更不要轻视任何人。演讲还有一些方面需要注意：1 。别说大话。不要用大帽子压人，不要盛气凌人，不要装腔作势吓唬人。2.不要说空话。不要哗众取宠许愿。能做的都会说。做不到的不会答应。3.不要胡说八道。不要官僚主义，不要华而不实，不要唱解决不了任何问题的八股。4.不要说谎。有好消息，有坏消息，有坏消息，如实反映情况，不要隐瞒自己的观点。5.别骂人了。礼貌的语言是美好的，不要在任何场合说脏话或粗话，
低级趣味的话。6、戒讲文理不通的话。说话要合乎逻辑、合乎语法，讲究修辞，积极维护祖国语言的纯洁和健康。
项目经理如何与程序员相处，做好这五点良好的沟通是最关键的，这不仅是程序员和项目经理之间，更适用于所有的关系他分配任务指标后。1.首先要明确他的意思，最好和他重复一下，看看你有没有理解错，他不会因此烦的，因为如果你的理解偏差了做出来的东西有差距，到时反而更麻烦了。2.在做的过程中，随时发现问题难以解决，或难以达到预期的目标要马上向他反映，让他明白你的难点帮助你解决或者让其他人帮助你。3.明确项目进程，及你的工作完成时间表，随时反映你的工作进程，如觉得时间有困难，要提前沟通，因为项目经理会有一个整个的统筹安排，你的一个环节的滞后可能会导致整个项目的无法进行，事先通知就可以提前修改安排，不会导致项目的停顿，而且原因可以理解他不会怪你的。希望可以帮到你，谢谢！

文章插图
产品经理怎么和程序员打交道【3】经常有人问我：“嗨，费杰你好！请问阿里巴巴的需求文档怎么写？“，但很少听到人谈：“嗨，哥们你好！请问产品经理怎么和程序员打交道？”你回去稍微琢磨了一下，心里就会得到下面三种情况：1) 很多产品经理之前就是程序员，所以非常了解程序员是什么样的一个状态；2) 很多产品经理还停留在关注自己产品规划、设计本身，缺乏对团队配合的思考；3) 很多产品经理，其实是有和程序员打交道的实践技巧、心得的，但没有重视和分享。事实上在很多产品研发体系下，产品经理和程序员因为思考方式、关注范围、职能职责的差异，导致了沟通上的困难。如何更好的与程序员建立起一座畅通的桥梁也是每位产品经理需要思考的问题。一般情况下，产品经理和程序员沟通困难大概的原因：?0?21、得到信息不对称；?0?2?0?2产品经理得到的信息一般集中在：商业需求、商业策略、战略方向、产品规划、运营数据、整体营收、目标任务等方面。产品经理往往在根据公司现阶段的情况，以及市场的竞争情况，做一些产品策略或者一些产品的方案的策划、发起、实施。所以这个过程中，产品经理扮演的角色是翻译：“市场需求、商业需求”，成为：“产品需求”，所有的信息全部围绕需求本身。为什么要做需求？怎么做需求？先做什么需求、后做什么？基于怎么样一个思路去推送产品进行实施、从一个利益平衡获得空间增长指标后达到另外一个利益平衡。程序员不一样，很多时候程序员得到的信息是：有一个需求，可能是小需求、产品需求、或大到项目需求，然后得到一系列需求列表，然后产品经理会让程序员看：“需求”哪些通过code改改就可以实现，哪些是需要开发可以实现，哪些是技术或构架或因为成本的原因不能实现。所以在这个过程中，程序员扮演的角色是翻译：“产品需求”，成为：“技术语言”的评估，所有的信息全部围绕开发需求本身。如何开发这些需求？是沟通数据库增加字段？调用接口？开发新的接口？需要开发组件？重新构架引擎？来实现满足或支撑这些需求？那这个时候问题来了，很多情况下我们只是把程序员当做一个写代码，通过编程语言来操作计算机完成需求的工具了。?0?22、沟通语言不对称；?0?2?0?2说到两者沟通的语言，这肯定是困扰产品经理本身的。产品经理的语言是：“描述“、”形容“，我也见过很多产品经理，很多人的需求文档就是漫天飞舞的文字，一整段的描述+描述，不要说程序员看不清，可能过段时间连自己都看不清楚。除了书面语言，产品经理的沟通语言也是含糊的，没有太多的逻辑去组织，很多时候总是试图去述说一个需求，被程序员的一个计算机术语而打断。程序员的语言，更偏向于技术化。很多产品经理做过技术，有技术背景，但是还有很多产品经理不懂得技术。所以在这个时候，程序员在解说或回答一个需求的时候，会把自己习以为常的变量、函数、实现方式说出来。于是很多产品经理听到：“Sdk、webshell、select、api、组件、插件、控件“等等的时候会云里雾里，那这个时候问题来了，很多情况下我们总站在自己的立场上、自己的世界里认为别人也懂自己在说什么？实际呢？大家都是听得一半一半，沟通没有彻底到位。?0?23、思考角度不对称?0?2?0?2产品经理思考的角度在于产品本身，对技术的细节、技术的性能没有太多的发言权。很多产品经理要是的实现的业务逻辑，不管程序员是采用：c++ 、java、php、Python、找开源代码改的，还是自己写的都没有关系。程序员只要在约定的时间里，把约定的业务逻辑开发出来就可以，产品经理不去会考虑目前服务器的配置、程序员手上任务的配置、技术能力的情况，要的是结果。而且很情愿的认为团队中的工程师都是世界上最好的工程师，想做什么都可以做，对因为技术原因而不能支持实现需求不能接受。程序员思考的角度有点区别，我也看到不到程序员本身对产品追求完美对需求的背景、意义去研究了解；但很多程序员还是停留在自己接单子任务一样来一个做一个的境界，做好了自己玩自己的。程序员考虑程序实现的方式同样的一个请求是get还是post，程序员考虑代码的性能，从而采取不一样的方案去实现需求，考虑请求并发量压力和安全性。但是很多情况下，程序员对技术的理解会导致有一些业务需求满足不了，不是因为不能实现，是因为实现了觉得是废代码，或者构架不完美了。那这个时候问题来了，很多情况下到底倾斜谁的立场上思考问题？我之前也会碰到很多情况程序员就程序的角度说业务需求不合理，产品经理说程序员消极罢工、霸得蛮。?0?24、考核标准不对称；?0?2?0?2谁也不尿谁，哼！你能把我怎么样。产品经理和程序员有为完全沟通或误会的时候，极端情况下，有一方会罢工。这个时候主要是2个角色的各个考核标准不一样，所以在很多情况下显得非常的无奈。产品经理很可能考核的是方案和上线的时间、产品上线后的数据；而工程师考核的是程序的性能、很多时候产品经理催的急要的急，但程序员每天的时间有限，还是得慢慢构架慢慢开发，程序员开发时间少了，未知的执行BUG没考虑过是要负责的。这个时候问题又来了，产品经理天天干着急！咋办？以上是我结合几年来的工作经验总结出来的，当然这4大因素把很多共性的因素概况进来了。当然过程中还是会因为很多产品经理或程序员本身（个性）的沟通技巧、态度、情商等因素导致的沟通不倡，影响了彼此之间的默契。其实仔细的分析一下，产品经理和程序员打交道的过程中不管是共性的因素还是个性的因素，也不是想象中那么困难。通过一些努力之后，我们总是会找到一些快速和程序员建立沟通桥梁的办法。我个观点如下：?0?21、要看到项目层面，不要只看需求本身。?0?2?0?2上面说到的几点不管是：“信息不对称“、”沟通的语言不对称“、”思考角度不对称“还是”考核的标准不对称“是我们常见的几个客观隐私。把几个因素抽取出来剖析，发现还是由于我们站问题的视角的高度不一致造成的。产品经理只是看到自己得到了商业的需求，策划了产品的需求，接下来会把很多事情抛给程序员做了，那还是站在需求方的角色中。那如果真正的是站在意识层面的项目经理的角度，这个时候看待问题的视眼会广很多。这个时候你就想着为了做这个项目这个需求，程序员是不是明白了为什么要做？是不是对这哪些需求的优先级有了重要的认识？作为产品经理我用怎么样一种表达方式程序员更明白？是不是需要把时间点等划定？目前程序员的资源和服务器情况允许他们能做的空间是多大？怎么样才能拉动他们的积极性更好的完成这个项目？适当的时候，需要帮助程序员做哪些申请或让步？对产品经理来说，同样张罗一件事情，同样会了得到一个结果，但是中间的过程很可能是完全不一样的。所以因为思考角度仅仅从做完一个需求死磨硬泡上升到，站在项目的角度去考虑各个关节的风险点、时间点，得到的效果是完全不一样的。?0?22、从理解程序员开始，换位思考会更好。?0?2?0?2一直在问一个问题：“程序员是什么一群人？“就和问自己：”产品经理是什么一群人？“一样，有点好笑、有点幼稚。从小工到专家，从CSDN到走出软件作坊，发现很多很多非常优秀的程序员的心声。程序员是什么样一群人？像切西瓜一样一刀一刀切：写php的写Java的写windows C的写liunx C的写C++的编程水平一般的编程水平还行的编程水平牛逼的编程水平大师级的构架牛的数据库牛的勤奋的懒于思考的不会JavaScript的积极的喜欢钻研的……好像都不太合适，因为你找不到解决和工程师沟通的好的办法。而且这些很多是外在的条件，随随都在改变。看到很多朋友一年之间经历几个大项目水平突然猛进，态度、一些特点也变得完全不一样。这个时候你需要的是了解和掌握程序员，作为职场的人，和我们一样的人共同需要的一些特点。如下4点：1) 是不是特别想被肯定、获得尊重；理解、肯定、尊重。这3个词或许非常的空但确确实实是一个非常好的方子。静下心来走近程序员，听听他们的心声、他们的抱怨，或许产品经理和程序员的距离将不再是那么遥远。虽然很多时候我们讲德行说尊重，但真正领悟到心里、落实到行动、表现在态度上的完全不一样的。真正，你是不是一言、一行本真理解、肯定、尊重程序员的，程序员是有感知的。2) 是不是想给产品提供自己的建议，而不是仅仅做一个编程的机器；很多程序员对产品非常热爱、对产品有独特的想法，但多数又局限于技术情节对产品的建议常常被忽视。相信很多程序员都希望参与产品，通过自己的专长改变产品，进而打磨出一款完美的产品。所以产品经理也可以适当的给程序员一点发挥的空间，特别是在技术创新、产品需要技术驱动的方面，在商业可控的层面让程序员发挥排头兵的作用。这样程序员会开足马力投入到开发实施的过程中。3) 是不是不仅仅和人任务指派，需求更多的和谐的人与人之间的沟通建立。产品经理和程序员两者之间没有一个良好的沟通，只是基于做与不做，做好做不好，什么时候做好，这样的功利性沟通肯定是不可靠的。往往两者因默契不够，或一方因沟通技巧不足、对待工作态度不够积极，造成矛盾。建立一个人与人之间的良好沟通，帮助产品经理或程序员更好的认知对方、了解对方，这样无论是在平时的沟通过程，还是在项目的合作过程中更好的促进了解、达成共致都会有一个前提保障。4)是不是需要别人的帮助，让他在非技术领域获得真知。看到很多产品经理朋友和程序员打成一片，和程序员一天聊天、抽烟、一起下班打游戏、打球，甚至有些时候产品头脑风暴的时候要去几个有产品情节的工程师参与前期的讨论，效果都不错。可能这些现象从另外一个层面来解决我们上面的一些疑惑。3、产品经理要改善心智，不断自我学习。?0?2?0?2最近突然觉得说得想的，有点像哲学。群里的一个朋友说了，其实哲学就是我们生活一些事情表现出来的道路。产品经理跟程序员打交道也好，对待生活也好，我个人认为是产品经理对哲学的认识、理解、应用。产品经理越往下走，抛开产品技能本身不谈，沉淀商业以及人脉资源，都是需要以一种良好、可靠的思维方式去支撑的，也就是所说的心智模型。很多时候产品经理改善心智可以不断的增强一些事物的判断。如：遇到程序员的拒绝的、不行的理由，这个时候你通过分析起码要判断得出来，这个是程序员隔个人的态度问题，还是流程问题，有一点微妙的。所以产品经理需要不断的学习，学习提高软技能。说到学习，回应这篇《产品经理怎么样和程序员打交道》中，程序员常用的一些技术原理、技术术语得去学习一下、研究一下。Right? OK, End ！
【跟程序员的沟通方式如何与程序员沟通，如何成为一个程序员】