工程师进阶之路
2013-01-12 20:11:49   来源：张中   评论：0 点击：

做一个专业而亲切的人。

最近这本书给了我启示《12 Essential Skill for Software Architects | 软件架构师的12项修炼》。那就慢慢写下读书笔记吧。

那么怎样才能做到泥？

保持关系，而不是一味的纠正别人

工程师由于每天都在和大量的程序、机器打交道，工作的重心之一就是订正各种各样的错误，但是人不是软件更不是机器，一味的去订正别人的错误是非常有害的（而且我们当时认为的“错误”其实更多情况下是我们没有全面审视而得出的结论，随着社会压力、生活节奏加快，这点尤其突出）。在纠正别人之前，先学会问自己两个问题？

1. 这个“错误”是不是非常重要？

2. 暂时忽略这个错误会不会给公司或者组织带来重大影响？

如果答案是“NO！”，那么我们应该停止：打断别人去纠正”错误“的行为。

学会授权和委派

这一点我深有感受，不仅对于一线技术管理者来说，就是对资深的老工程师来说或多或少都有问题。面对问题，工程师天然的反应就是”我自己能否解决？”“我如何解决？”，但是正确的授权和委派不仅仅能够让项目进展更顺利，更关键的是能够建立信任，让不同层次的人都能得到成长。

生活是一面镜子

你的言行是正向、友善、积极的，那么你收到的反馈就是正向、友善、积极的。你的言行是负向、带刺、消极的，那么你就会觉得全世界都在为难你。工程师要走好他的技术道路一定要意识到这一点，这也是为什么许多工程师“跳槽”或者“换岗”之后，还是不适应，很大的一个原因就是他没有意识到改变自身行为模式的重要性。

注意语言的表达

有的时候我会收到别的同事的反馈说，为什么你们有的工程师这么“梗”，经过了解和交谈，我发现原来是很多工程师不好的口头禅造成的，比如“这个不行啊！”，“你连这个都不懂啊”，“我没有时间！（然后就没有反馈了）”。语言就像种子一样，你播种下去就会长起来的，你播种的是带刺的藩篱，那么它长大后就会把你困在其中。这个和阿里巴巴价值观里面常说的“直言有讳”是一个道理。

及时处理出现的问题

这个更多的是指“软”问题，呵呵借用了一下“软技能”。当我们工程师每天面临各种纷繁复杂的技术问题在处理的时候，不自觉的就忽略了这种软问题的处理，比如我是不是遇到了一个很“难缠”的合作伙伴，我是不是在一个多方合作的项目中感到无助和困惑，我是不是和上司间存在认识的不统一和误解，我是不是在该说“No！”的时候选择了沉默？千万别埋葬这些问题，因为很快它又会出现，直到无法收拾。我是一个内向的人，沟通不是我的强项，但是不意味着放弃沟通；我是一个“Nice”的人，但是不意味着从来不说“No！”。及时处理出现的问题，意味着我们在不停的挑战自己，在修行中成长。

提供专业的服务

怎么理解专业的服务呢？不仅仅是专业的IT技能，就像我们判断一个酒店是否专业一样，不仅是看大堂还要看它的客房，还要看它的接待，还要看它的氛围。专业是全方位的。因此我们工程师除了要会用代码服务的时候，还要学会：

● 微笑

● 合适的手势表达

● 把大家都加入到谈话中来

● 关注别人，而不是以自我为中心

● 别一心二用，身在曹营心在汉

● 随时准备给别人提供帮助

● 学会关心他人

● 学会倾听

 

原谅并忘记曾经的冒犯

这个不多说，还记得我们曾经也冒失过吗？还记得曾经也小人之心过吗？那么我们遇到的冒犯都是浮云啦！呵呵。

谈谈沟通能力——沟通的准则

如果一名工程师要成长为资深专家或者是架构师或者是技术管理者，沟通是必不可少的技能和工作的工具。

对于资深专家或者架构师，对沟通能力的要求甚至大于技术管理者，因为他们没有行政权力，但是却往往需要主导、指导、控制跨小组、跨团队乃至跨公司的项目，怎么能够把各个组织里面的人有效的驱动起来，沟通能力非常重要。

但是我们工程师在成长过程中，往往不注意或者没有收到这方面的训练，当他技而优则”升“成为专家的时候，问题就来了，尤其是他作为团队中坚，既要和一线工程师交流又要向老板汇报，真的是压力山大啊！

沟通方式和技巧往往是因人而异的，但是我们还是可以总结出一些基本准则供大家参考。

先说一下沟通的准则：

● 先听后说

古罗马哲学家Epictetus曾经说过很有意思的一句话，人之所以要少说多听，是因为我们只有一个嘴巴但有两个耳朵。

我们古人也总结了：兼听则明偏信则暗，进一步补充了耳朵各在左右两边的重要性，哈哈。

马云对还没有成为三年阿里人说的话里面，第一句就是多看少说。

当然他们更多的是从宏观的角度来论证，其实走入到具体的沟通微观例子中也是同样适用的。

我曾经一开会就立马紧张起来，为什么啊？是因为要急于表达自己的观点和成绩，深怕别人不知道，总是想见缝插针的说话，结果是别人说的、别人要表达的我全部没有听进去，失掉了很多学习乃至接受别人主动帮助的机会。

而我们工程师要成长进阶，意味着我们必须承担更多的职责、协同更多的事务，从而在我们的沟通中不仅仅是单刀直入的技术讨论，而是需要多方面的去倾听，尽可能多的收集各方面的反馈和判断，从而帮助你做出正确的决定，并且记住“正确”的决定往往不是“最好”的决定。

公司或者组织为什么要提拔你，很重要的一点就是需要你的综合判断能力，要做到综合判断的首要一点就是“先听后说”。

● 不能身在曹营心在汉

当我们慢慢成长的时候，我们别的感受不强，但是有一个感受会非常强烈，就是会议越来越多，非纯技术的小事情会越来越多的骚扰到我们，工作和生活间的干扰甚至冲突也会出现。

很快一种典型的行为模式就出现了：开会的时候漫不经心，时常溜号；工作上想着生活上的事情，生活上为工作上的困难而惴惴不安。工作和生活的界限，先不详说，也许下次再说，呵呵。

就说说会议吧，会议变多说明你变重要了，是好事情。但是总是在溜号，说明你的其它技能还不能支撑你的进步。最急需的就是时间管理和任务优先级安排，这两个话题有很多很好的书去阐述，比如《成功人士的七个好习惯》《和时间做朋友》等，我们可以去学习。

那就简单说一下防止溜号的一个小技巧吧：盯着发言的人，跟着他的思路思考，放平你的腿不要翘起来，给自己一个不是非常舒适的坐姿，呵呵，真的好用。

● 积极的看待问题

这个和上一篇说到的”生活是一面镜子“是呼应的，但是更强调你的积极的心态，对沟通结果的引导，同一件事情往往都有两个侧面：积极的和消极的。

一个很有意思的例子就是：屡战屡败 vs 屡败屡战。我们的积极心态才能在沟通中激发起对方的激情和勇气，让对方也积极的看待事情，并乐观的处理。一个全是唉声叹气的谈话，怎么让人在沟通后信心百倍的去做事情呢？

● 早冷静早道歉早更正

资深专家或者架构师最经常犯的一个错误，就是沟通中在技术方面给出了错误的指导或者判断。

如何去修行我们的技术能力尤其是技术广度，是另外一个话题暂且不表。那么当出现了这个问题，我们一定要尽早更正和道歉，尽可能让参加沟通的全体都能接受到。不要让自尊心阻碍了我们的更正和道歉，我们的这种行为反而会赢得大家的尊重。

还有一种情况就是因为我们对于技术的热情或者偏执，在沟通中会伤害到别人，比你资深的人会收起帮助你的想法，比你资浅的人会闭上表达想法的嘴巴，最后的结果就是你成了孤家寡人。所以我们一定要早冷静，一旦发现自己过激了，立即更正、道歉。这反而会让我们更可爱。

● 不要鸡蛋里面挑骨头

当我们成长起来过程中，审视或者评审别人的工作成果或者设计方案会越来越多，这个时候千万别在小缺陷点上过度追求完美。

因为我们之前肯定有被”鸡蛋里面挑骨头“的经历，往往让我们最难堪、最不可接受的不是证明了我们架构上、方向上的重大问题，而是一些在小缺陷的尖刻评论和纠缠。那么反过来，我们一定要克制自己。

那么那些缺陷怎么办呢？放置不管？不是的，我们可以客观的提出来让对方记录下来，不要纠缠。我们需要记得我们还需要在更高层面去把握事情呢！

沟通可以注意的一些小技巧就是：不要把对缺陷的更正，变成对个人的批判，一旦沟通从对事变为对人，味道就变了。别纠缠，“纠缠”那是傻瓜做的事情，呵呵。

再谈沟通的策略

什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。

哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条：

说”Yes“而不是”No“

我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。

因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动,不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。

换句话说，我们的角色要求就是”找到一条可行的道路“。但是我经常会看到一些工程师在积累了一些经验和技术深度后，还是一味的说”No“，我只能在心里为他的提升暗自担心了。

不过我们一定要记住，这是一种方法，它是基于”客观、真实“的基础的，如果需求或者项目的确是不可行，通常情况是因为”法律“、”监管“和”承诺“的原因，我们一定要说”No“。有一点要注意的就是，不要混淆”资源“上的不可行和项目上本身的不可行，“资源”上的紧张我们可以通过进一步的讨论、协调解决的。

还有一个心理上的因素，也是很重要的，我们往往需要说“Yes, I can”才能让自己挺过一个个难关，正如林书豪的成功一样。“Yes”往往意味着坚持，不放弃。

不要急于申辩

在会议或者谈话中，我们越来越多的会听到对于我们的工作不利的或者不是那么正面的描述，这是正常的，而我们往往会出现一些不正常的反应，以我为例子吧，我就会想方设法的给自己辩护或者澄清干系，目的就是这个责任不应该我负。

后来开的会也多了，听到的抱怨和指责也慢慢多了，发现自己竟然慢慢“耳顺”了，汗，但是心静下来后，却听到、学到了很多以前完全听不到的东西，给了我很多反思的机会。并且由于我没有立马站在挑战者或者防御者的角度，沟通的顺畅程度也有了提升。

后来也从同事的反馈中学到了很多经验：听到不爽的东西的时候不要抱起双手，不要背过头去，反而要和对方有视线上的交流。传达你对对方的尊重和鼓励。

当然事情有两方面的，不是完全的“逆来顺受”呵呵。如果你接收到的描述完全违背您的“价值观”或者违背了公司的“政策”，你一定要及时澄清的。

对于我们技术人员来讲，还要有“协同进步”的胸怀，因为我们会收到更多的批评也会给出更多的批评，比如在技术评审、代码Review、bug跟踪、项目评审、资源协调等等。古人的“从谏如流”我觉得是一个应该学习的好心态。

在上述场合，在各种”批评“和“被批评”满天飞的情况下，我们一定要保持好一点：对事不对人。

这点说到很容易，做到却很难，很多情况下，我们做的是：你们是对事并对我个人，我是对事不对你们个人。而且很多情况下这是一个普遍的想法，“不急于为自己申辩”我认为是一个解决的办法，不要武断的把自己搅入对事情本身的讨论中。

做起来不容易，我们共勉。

如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。

只给事实

人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。

清晰而不是事无巨细

在组织中，个人的层级越高所需的技术细节信息就越少，这时候需要的是更高层次的总结性信息。因此我们提供的信息应该是清晰和简洁的，更具体一点就是：

● 首先我们要提供必要的合适的上下文，这个是我们技术苦逼人最容易遗忘的事情，一上来就陈述和表达自己的信息，忘记了这个是给老板们听的，不是说给我们自己听的。

● 其次我们要提前归纳总结，把信息结构化，结构化的信息是最容易被理解而不会被演绎的；另一个角度出发，产出结构化的信息也会让我们更聚焦在”事实“之上。

● 还有就是更多的给出业务信息，更少的技术细节。

● 最后因为需要你给出的是持续一致的信息，所以一旦给出，就要保持，这意味着我们要谨慎作答。

经常会有这样的情况发生：在会议上，我们会被问及不清楚或者不知道的情况，也许是合作伙伴进度的，也学是团队里面一个人的细节情况的，或者是一个全新的技术领域或者业务点，我们要坦率的说明自己不知道，但要记住，同时我们要表述自己将会跟进刚才的问题，并且落实、汇报后续的跟进结果。

不要给意外

我觉得我最对不起我的老板的地方就是：我一直在给他意外（尽管现在要少了很多）总是让他处于救火的状态，谢谢他的宽容。总是在反省，总是在犯错。

老板不喜欢意外情况，尤其是那种需要他们在极短的时间内做出行动和决策的意外。我们要尝试去发现隐藏的风险，我总是对自己说我需要把技术男总是去挑刺别人的精力用到探究团队或者项目的风险上。

因为人的本性之一就是会倾向展现好的方面，扭捏的遮挡不好的方面（孔雀开屏我们看到的是美丽羽毛，焉知后面是光秃秃的屁股），在实际的工作中，我们面对比自己更高级别的人的时候，尤其会这样。

所以我们发现风险后，要及时称述出去，这是组织对我们的要求，我们要是没有这样的能力和正直感，我们对不起自己的位置。当然陈述不好听的东西的时候，肯定会让人不爽，自己或他人，但是我们需要这样的勇气。

陈述的技巧有很多，坦率的说我是非常不擅长技巧的人，所以我就给出一个原则吧：更早的提醒风险，总是比到事情最后发展到无法收拾再处理要好。