共 4 篇相关文章
如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。 只给事实 人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。
再谈沟通的策略 什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。 哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条： 说”Yes“而不是”No“ 我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。 换句话说，我们的角色要求就是”找到一条可行的道路“。
谈谈沟通能力——沟通的准则 如果一名工程师要成长为资深专家或者是架构师或者是技术管理者，沟通是必不可少的技能和工作的工具。 对于资深专家或者架构师，对沟通能力的要求甚至大于技术管理者，因为他们没有行政权力，但是却往往需要主导、指导、控制跨小组、跨团队乃至跨公司的项目，怎么能够把各个组织里面的人有效的驱动起来，沟通能力非常重要。 但是我们工程师在成长过程中，往往不注意或者没有收到这方面的训练，当他技而优则”升“成为专家的时候，问题就来了，尤其是他作为团队中坚，既要和一线工程师交流又要向老板汇报，真的是压力山大啊！ 沟通方式和技巧往往是因人而异的，但是我们还是可以总结出一些基本准则供大家参考。 先说一下沟通的准则： 先听后说 古罗马哲学家Epictetus曾经说过很有意思的一句话，人之所以要少说多听，是因为我们只有一个嘴巴但有两个耳朵。
最近这本书给了我启示《12 Essential Skill for Software Architects》。那就慢慢写下读书笔记吧。 那么怎样才能做到泥？ 保持关系，而不是一味的纠正别人 工程师由于每天都在和大量的程序、机器打交道，工作的重心之一就是订正各种各样的错误，但是人不是软件更不是机器，一味的去订正别人的错误是非常有害的（而且我们当时认为的“错误”其实更多情况下是我们没有全面审视而得出的结论，随着社会压力、生活节奏加快，这点尤其突出）。在纠正别人之前，先学会问自己两个问题？ 1. 这个“错误”是不是非常重要？ 2. 暂时忽略这个错误会不会给公司或者组织带来重大影响？ 如果答案是“NO！”，那么我们应该停止：打断别人去纠正”错误“的行为。
