做管理不懂技术怎么顺利跟工程师们交流

　　有管理者问我：我不懂那些技术。每次跟工程师们交流时，都感觉他们会因为我不懂技术而暗自鄙视我，我应该怎么做？
　　很多管理者（特别是产品经理），在和工程师谈需求时，都费尽唇舌的想要解释清楚自己的想法，却总是被工程师以这个实现不了为理由拒绝。如果再尝试沟通，一个乱改需求的帽子就扣到了头上。如果管理者再不依不饶的话，最后就变成真人PK了。
　　我们平时接触最多的工程师群体莫过于程序员了。你看见过的程序员往往是：
　　聪明，知识面广。
　　迷之自信，甚至自负。
　　对于技术异常执着。
　　难以沟通，沉浸在自己的小世界中。
　　（不会穿衣搭配）
　　现在，让我站在一个（曾经的）程序员的角度上，来谈一谈工程师的个人喜好：
　　热爱解决问题
　　强大的逻辑性
　　注重理论知识
　　1、热爱解决问题
　　工程师最开心的时候，莫过于解决了一个实际问题所带来的成就感。
　　工程师希望能够从看的见，摸得着的事物中获得成就感，比如一台电机，一个软件，一组生产线。让工程师来测试发电机运行是否良好，他们肯定会很开心。而让工程师来做空一个股票，他们一定不乐意。
　　为什么？
　　因为测试发电机运行是否良好只需要严格遵照手册规则，一步一步做下去，就一定能测试成功。而做空一个股票，可以有很多种方式，同时还可能有很多突发事件。而这种不确定性，就是工程师最讨厌的部分。
　　当然，常年累月的解决问题，也带给了工程师另外一个特点，强大的逻辑性。
　　2、强大的逻辑性
　　有个关于程序员的笑话：
　　一天，妻子跟程序员丈夫说你去菜场买两斤苹果，如果你看见了烧饼，就买一个回来。
　　丈夫带着一个苹果回来了。
　　工程师的逻辑性强，是大家的一个共识。这是很多工程师的优点，也是他们一个很大的阻碍。
　　你如果和工程师辩论，他们的逻辑都自成一体。你这个项目做不出来，因为以下几个原因。里面混着数个专业术语，带着自信，不容你一丝反驳。
　　工程师平时的工作，又强化了他们对于事物逻辑性的追求：我们很难想象，一个随机分布的程序，或者一个随意装配的机械，会如何的运作。而工程师为了保持这些事物的稳定，不得不学会按照机器的方式思考，也就是依靠逻辑来判断事物的正误。而逻辑性强的前提，就是需要有丰富的理论知识。
　　3、注重理论知识
　　一枚硬币抛了100次，都是正面，那么下一次是反面的几率有多大？
　　如果是工程师，他会说：50，因为硬币的正反和之前的结果是互相独立的。
　　如果是个商人，他会说：0，因为100次正面，已经证明这个硬币被动过手脚了。
　　对于科学知识的信任，是所有工程师的共性。想要成为一个出色的工程师，就必须对技术和科学有着近乎狂热的信仰。
　　工程师对技术的信仰，有时会成为偏执的原因。因为工程师的逻辑是依靠自身强大的理论知识所建立起来的。而这样也带来了社会心理学所说的知识的诅咒：专家以术语和他人交谈，失去了与非专业人士沟通的能力。
　　既然我们分析了工程师的特点，那么，如果我们想让工程师满足需求，我们该怎么做？
　　给工程师发嗲，撒娇，卖萌？
　　给他们买超好的电脑，配上超大的屏幕？
　　做他们的出气筒，当受气包？
　　当你只管理一两个工程师的时候，这样可能会有效，可能会留住那些优秀的工程师。但是，我们需要的是组建一个优秀的工程师团队，仅仅依靠人情，会浪费大部分精力在办公室社交上。那么，我们需要做到以下几点：
　　多听少说
　　提出问题
　　自我学习
　　证明自己
　　亲自交流
　　1、多听少说
　　作为一个合格的管理者，我们需要做到和上级汇报，和客户解释，和供应商沟通只有一个能说会道的管理者，才是一个优秀的管理者。
　　这样也导致我们在跟工程师沟通时，总是在和工程师长篇大论，谈及各种设想，创意，需求。而工程师却不得不坐在那，耐着性子，听着对他们毫无意义的空话。我们知道工程师最喜欢的事情是：用尽可能简单的方式，去解决一个新奇的，有趣的，复杂的，实际的问题，并且因此而挣钱。而我们也知道，一个问题的长度，是远小于答案的长度的。
　　所以，作为问题的提出者，我们需要更多的鼓励工程师占据谈话的主导权。他们作为天生的问题解决者，一定能提出更加精彩的点子。
　　没错呀，我们都是让工程师去解决一个实际问题啊，比如做个类似百度的搜索引擎。为什么他们一口回绝了呢？
　　这是由于我们创造了错误的问题，并且尝试让工程师去解决。这些错误的问题，站在我们的角度上，感觉并不是很难。而站在工程师角度上，这种问题是在故意刁难他们。那么，我们如何才能问出合适的问题呢？
　　2、提出问题
　　很多管理者问的最多的问题是：这个项目什么时候能做完？
　　试想一下，我们在看一个人弹钢琴。即使你不会弹钢琴，你也知道《小星星》比贝多芬的《命运》容易的多。这是因为我们在判断它的时候，我们依靠的是它的速度来进行判断的。而小《小星星》的速度比《命运》慢的多。
　　作为不懂的钢琴技术我们，只能利用锚定效应来估计复杂度：为不熟悉的事物做估计时，我们会以熟悉的事物来作为锚点，而估计出来的结果和锚点往往相近。当然，这样的判断大多数情况是正确的。然而，你是不是经常听见工程师说：
　　这个问题解决不了。
　　这个需求没办法做。
　　这个流程很复杂。
　　你会想：这有什么难的，不就是要你做个小程序来排个序放大窗口批量删除嘛。
　　我们提出的问题一般都是难度低，重复性高。这类问题大多数人都可以轻易解决，只是想利用机器减少人工的消耗。而我们的锚点就是人可以轻易解决的问题，自然而然的将问题看得很简单。
　　所以，我们对于问题难度错误的估计，加上预算的紧逼，让工程师很难将注意力集中于提升产品质量上，反而去关心一些无关紧要的事情：
　　如何让管理人员不再来烦我？
　　如何向这些外行证明我才是对的？
　　如何让别人来接手这个烂摊子？
　　那么，我们如何避免被工程师认为是外行呢？我们需要自我提升。
　　3、自我学习
　　我给大家讲个笑话：手持两把锟斤拷，口中疾呼烫烫烫。
　　是不是完全无法理解这个笑话的笑点？
　　正如这样，如果我们不深入理解需求中存在的技术问题，而让工程师头疼于那些非技术原因产生的问题，很容易让最终产品延期又低质。（至于那个笑话，是一个程序编译时常见的乱码错误）
　　因此，我们作为管理者，首先就需要将一些初级的，非技术的问题消灭掉，从而减少工程师的工作量。
　　如果我会的话，我自己做就好了，那就不需要请工程师了。问题是我学不会啊！
　　我们不需要去懂得如何去实现，而是将基础原理适当的进行了解。至少做到能够理解工程师口中的专业词汇，就能大大减少我们交流沟通时的障碍。
　　那么，如果我们真的完全搞不懂那些技术，我们该如何从其他方面下手呢？
　　4、证明自己
　　不少工程师对于管理学的态度是：这有什么难的？不就是做个PPT，写个报告，汇报一下就好了？
　　有些管理者则默认了这种想法的正确性。平时把自己的姿态放低，给工程师端茶送水，揉肩捶背。而有些管理者对这种想法嗤之以鼻，与工程师处于道不同，不相为谋的冷淡关系。
　　没错，科学技术是第一生产力。而且，如果我们每个人都能良好的理解他人的想法，并且按照步骤按时完成，其实我们根本不需要任何管理者。然而，人与人思考模式有着巨大的鸿沟，管理者则是搭建这些桥梁的关键人物。
　　明茨伯格的管理者角色理论中提出，管理者需要处理三个方面的问题：人际关系，信息传递，以及决策制定。由于人际关系依托于个人性格的展现，而决策制定很难直观的表述出来。那么，我们可以向工程师展现出自己的信息传递的能力。
　　解决办法是，我们可以进行一下角色互换。让工程师来监督我们的PPT制作过程，报告的撰写流程，等等。让工程师能够感受到管理者为项目所作出的努力，感受到管理者作为沟通的桥梁所展现出的技能与技术，增加工程师对于管理者的谅解。
　　如果工程师觉得这是浪费时间，拒绝角色互换，怎么办？我们只能拿出杀手锏了：让工程师和客户交流。
　　5、亲自交流
　　对于工程师来说，管理者是辅助他们与客户交流的桥梁。但如果工程师不听从管理者的建议，那么，让工程师直接去体验客户的需求，是解决需求纷争的最佳方案。
　　我们有三种办法，让工程师直面用户的需求：
　　1。让工程师使用自己的产品
　　这样的方式最为简便，但是也最不直观，因为工程师往往不是产品的主要受众。这样的方法可以让工程师很容易发现一些常见问题，但是很难去深入了解客户的特殊需求。例如，我们为烘培坊开发了一套自动化生产线，但是工程师自己很难依靠这个生产线分析出烘焙坊的真实需求。
　　2。让工程师接受用户反馈
　　大多数用户反馈都是传递到了售后部门，然后由售后部门整理后集中发给技术部门。由于用户和售后部门对于技术的不了解，有些技术上的问题，可能因为被归类为非技术问题而忽略了。让工程师直面反馈，他们也能逐渐发现问题的规律，可以防止下一次开发犯同样的错误。然而，客户的反馈往往都是负面的，这样也容易造成工程师对于产品产生一定偏见。
　　3。让工程师观察用户如何使用
　　这是最复杂的方法，但是也是最有效的方法。让工程师直接观察用户的使用方式与使用习惯。通过这种方法，工程师可以了解到，用户如何实际使用产品的，也能够为工程师改进产品提供更多的灵感。然而，这样的方式会占用大量的开发时间，而且大多数工程师，会对这个方式有如同本能般的抵触因为这相当于让工程师自己承认，自己的产品有缺陷。
　　作为杀手锏，这三个方式都可以酌情使用，然而会占用双方大量的时间和精力，造成项目的停工。相对于说服工程师，更难的可能是说服整个项目组花费时间来做这些无用功。
　　最后，总结一下管理者和工程师沟通的五个要点：
　　让工程师成为解决问题的主导者
　　选择正确的方向进行沟通
　　提升管理者的专业知识
　　展现管理者的非专业技术
　　促进工程师和客户的直接交流